How does this compare with Conchango's?

Sep 30, 2008 at 5:09 PM
Here's the blurb from Conchango's web site (Link): "Scrum for Team System is a free Agile Software Development Methodology add-in for Visual Studio Team System, developed by Conchango, in collaboration with Ken Schwaber and the Microsoft Technology Centre UK."

It's free like this one. It's agile like this one. It's TFS like this one. Do we really need two?
Coordinator
Sep 30, 2008 at 6:01 PM
Edited Sep 30, 2008 at 6:02 PM

Actually, the answer is "No!"  Of course, no single team needs two process templates.  Does the world need another?

This template was designed to align with lean principles.  For example, the team can alter the process, and the template was designed to be relatively easy to alter and maintain.  The other aspect we emphasized was lean's "build quality in" and agile's "acceptance test driven":  Our workflows emphasize up-front acceptance criteria.

We have noted that teams usually need to make alterations, so we kept it simple and modifiable.  Conchango's template has parts that are, for the most part, untouchable.


Of course, we're not trying to compete with Conchango's template.  After all, the margins are really bad.  ;-)

Rob

Oct 1, 2008 at 11:13 PM
Edited Oct 1, 2008 at 11:15 PM
How do you edit your process template? Is there a good tool out there?$0Is this template rather simple, then? I mean, just some work items types with custom workflows?$0$0Are there add-on tools like the TaskBoard thing for the Conchango one or just the process template? Anything planned?$0$0I guess this isn't really a scrum implementation, right? More a mix of Lean, XP, and a little Scrum? A hybrid? (does it have a name?)$0$0Please don't misunderstand my curiocity for criticism.$0
Coordinator
Oct 2, 2008 at 8:01 PM
Edited Oct 2, 2008 at 8:05 PM
I appreciate your curiosity, and I didn't take it as criticism.  Though, we welcome criticism, too.

We used the Team Explorer add-on to VisualStudio.

The template is very simple.  We also provide simple reports.  The reports were built without code, just with the tools available (and we've heard that improvements are coming).  So far, there are no other add-ons.

The process that we encourage is indeed a mix of Lean, Scrum, and XP.  We've referred to it as Lean-Agile, or Scrum#.  We started with Scrum, so I'd like to get your take on what you see as missing?  It's possible we missed something, or we may have skipped it for a reason.

There are as many flavors of Scrum as there are teams (I co-coached SalesForce.com's Big Bang transition a while back, and each of my dozen or so teams was doing things just a little different).  The basics of Scrum should all still be doable with the template.  We see the use of the template primarily as a communication mechanism for geographically separate team members, or for very large projects where multiple teams are drawing from a single product backlog.  In these cases, we find that we have to rely on the whole team to find ways to collaborate effectively, rather than imposing artificial gates on those collaborations.  "Bigger"--perhaps counter-intuitively--requires "simpler."

The Lean aspect is at least two-fold:  (1) The team specifies the process rather than having the workflows drive the team. (2) Build quality in from the start.  And that last one is, I'd guess, where you're seeing the XP influence:  Acceptance-Test Driven.  It's not an accident that so much of what is in these minimalist workflows is an emphasis on customer (aka Product Owner aka Product Champion) acceptance.  We see the lack of explicit customer acceptance criteria and "doneness" criteria as a significant point of failure for agile teams.

The workflows don't enforce automated testing, but of course we think that's the way to go.

I see this template (and my colleague Rod Claar may want to correct my understanding) as an example that we can use to coach teams in enterprise-wide agile processes and to utilize their investment in TFS.  We're not really a product company, so our involvement in enhancing the template may be sporadic.  Thus, we opened it up to see what others would contribute.

Thank you, Jerry, for your interest!

Sincerely,

Rob Myers
Coordinator
Oct 2, 2008 at 8:24 PM

Good job!

From: xyphrnld0x [mailto:notifications@codeplex.com]
Sent: Thursday, October 02, 2008 12:01 PM
To: Rod Claar
Subject: Re: How does this compare with Conchango's? [ImplementingAgileDev:36741]

From: xyphrnld0x

I appreciate your curiosity, and I didn't take it as criticism. Though, we welcome criticism, too.

We used the Team Explorer add-on to VisualStudio.

The template is very simple. We also provide simple reports. The reports were built without code, just with the tools available (and we've heard that improvements are coming). So far, there are no other add-ons.

The process that we encourage is indeed a mix of Lean, Scrum, and XP. We've referred to it as Lean-Agile, or Scrum#. We started with Scrum, so I'd like to get your take on what you see as missing? It's possible we missed something, or we may have skipped it for a reason.

There are as many flavors of Scrum as there are teams (I co-coached SalesForce.com's Big Bang transition a while back, and each of my dozen or so teams was doing things just a little different). The basics of Scrum should all still be doable with the template. We see the use of the template primarily as a communication mechanism for geographically separate team members, or for very large projects where multiple teams are drawing from a single product backlog. In these cases, we find that we have to rely on the whole team to find ways to collaborate effectively, rather than imposing artificial gates on those collaborations. "Bigger"--perhaps counter-intuitively--requires "simpler."

The Lean aspect is at least two-fold: (1) The team specifies the process rather than having the workflows drive the team. (2) Build quality in from the start. And that last one is, I'd guess, where you're seeing the XP influence: Acceptance-Test Driven. It's not an accident that so much of what is in these minimalist workflows is an emphasis on customer (aka Product Owner aka Product Champion) acceptance. We see the lack of explicit customer acceptance criteria and "doneness" criteria as a significant point of failure for agile teams.

The workflows don't enforce automated testing, but of course we think that's the way to go.

I see this template (and my colleague Rod Claar may want to correct my understanding) as an example that we can use to coach teams in enterprise-wide agile processes and to utilize their investment in TFS. We're not really a product company, so our involvement in enhancing the template may be sporatic. Thus, we opened it up to see what others would contribute.

Thank you, Jerry, for your interest!

Sincerely,

Rob Myers

Read the full discussion online.

To add a post to this discussion, reply to this email (ImplementingAgileDev@discussions.codeplex.com)

To start a new discussion for this project, email ImplementingAgileDev@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________