Watching Agile Grow Up

  1. Posted on March 3, 2009 2:24:PM by Earl Beede to Practicing Earl
  2. Methods & Processes, Technique, Agile, humor, iteration

Is Agile, which was baby a few years ago, growing up to be just another moody development adolescent on the way to becoming a ho-hum mainstream adult? One of the fascinating (or darn scary) aspects of having children is watching them grow up. As they take on more and more decision making on their own, they begin to do things that, frankly, can make you cringe.

I bet that is true for the Agile thought leaders as well. How well are things like empowerment and high bandwidth communication maturing in global enterprises. Are companies turning Agile into something a true zealot would dislike? Have you ever wished your child didn’t mention they were related to you?

What started me thinking about this was a common implementation trick I see in Agile teams, the iteration zero.

In Agile, one of base “rules” is to deliver value (as defined by the value definer) every iteration. That is, every two weeks (or however long your iteration length is) you must deliver something the customer (whoever that may be) can use to meet their objectives (whatever those may be) in some, possibly partial, way.

The thought is that an architecture, while useful for the development team and an enabler of other activities, generally is NOT useful to the customer. The typical value delivery item is some amount of the end functionality actually working in executable code. One can also deliver a document that is required like a training manual but code is strongly preferred.

To pull this off from the very first iteration requires some slight of hand. A common strategy of by-the-book Agile implementations is to develop that executable code in a environment that is not the target environment—say an Excel macro. This will be done with only a small amount of the available capacity of the team while the rest of the team’s capacity is used to build the target environment.

While true to Agile’s values, I don’t see this strategy very often. More likely than not, the Agile team that needs to do some grunt work before they start delivering value will invoke an iteration zero.

In an iteration zero, the team builds the target environment, sets up the regression testing/build tools and, increasingly, does some requirements and design work all while delivering no value to the customer. Hence the zero.

Iteration zero is also often a different length than the follow-on iterations. While a common iteration length is somewhere from 2-4 weeks, an iteration zero can be a couple of months long. It takes time to get ready to deliver value.

Upfront work; what are those Agile thought leaders thinking? Doing requirements (some at least) and design (again some at least) before writing any code. Locking in architectures (mostly). Just like the old school development methods. Are they cringing?

Now, I have watched the Agile thought leaders spin this as this is what they intended all along. I don’t think it is what they intended. You can look at things like co-location going distributed and test-first returning to test-please. Not part of the original plan.

Agile is out of their hands. The child is making its own calls. Agile, as now touted by the thought leaders, is different. Maybe the thought leaders are getting wiser as well.

Maccherone » Visibility -> Retrospection said:

March 6, 2009 1:18:PM

Pingback from  Maccherone » Visibility -> Retrospection -> Adaptation

Post a Comment:

 
 

Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).

 

Contact Earl