The Wit and Ramblings of David Giard - Agile
Demanding rigidly defined areas of doubt and uncertainty

In October, the Great Lakes Area .NET User Group (GANG) celebrated 10 years this past October with an all-day event. Here is Godfrey Nolan’s presentation on Executable Requirements or BDD in .NET.

Episode 173

Steve Bohlen on Agile Methods

Episode 171

Phil Japikse on Agile

Think big; act small; fail fast; learn rapidly.

These are some of the lessons from Tom and Mary Poppendieck’s book Lean Software Development – An Agile Toolkit.

The Poppendiecks take what they learned from Lean Manufacturing (many of which were originated with the pioneering work of Toyota Motor Company) and apply these lessons to software development.

They deliver advice in the form of 22 “tools” that can make a team or project more lean. Related tools are grouped together into chapters.

The authors recommend that organizations define, find and eliminate waste wherever it occurs in a process. Examples of waste in software development include defects, waiting, extra features or processes, and any non-essential activity. To assist finding waste, they recommend Value Stream Mapping - a technique in which one lists in sequences all the steps from customer request to delivery and estimates the time to completion of each step and the wait time between each step. This technique often makes bottlenecks obvious so that they can be reduced or eliminated.

Many of the tools in this book overlap. For example, iterations and feedback are listed as separate tools, but shorter iterations allow for more frequent feedback to the development team. Short iterations also expose design problems more quickly sot that the can be corrected early in the development cycle at a lower cost.

Much of the authors’ advice seems counter-intuitive. For example, they recommend against detailed planning at the start of a project and attempting to optimize every part of a multi-part project.

A popular approach among software project managers is to create in advance a detailed plan of every step in the design, development and deployment process and to estimate each step. To do so, you need to know a specific scope of everything you will build. This makes sense as a risk-reduction strategy, until you consider that environments, requirements, priorities and people often change while software is being developed. A rigid plan created up front often requires an aggressive change control process to alter that plan in any way. And for long-term projects, the changing landscape almost always forces changes to the design. Also, when users know they will only get one chance to request features, they tend to ask for far more, so scope tends to get bloated when projects are planned in this way. A better approach is to re-evaluate priorities periodically throughout the development process and keep focused on the top priority features that have not yet been implemented.

Complex project can and often should be split into a number of smaller phases or tasks. This helps to simplify the complexity. Many managers then strive to optimize each phase of the project, assuming that this goal will lead to overall optimization of the project. The Poppendiecks advise against this goal because optimizing some phases may cause a bottleneck in your overall project, thus slowing down the project as a whole. A buildup of code waiting to be tested, for example, represents waste that should be eliminated. It is best to look at the system as a whole when setting optimization goals. Optimizing each part ignores the interaction between these parts.

The book finishes with practical advice to get started making your team and process more lean.

Lean Software Development - An Agile Toolkit is a clearly-written, thoughtful book and anyone involved in software development projects can benefit from reading it.

Episode 54

Kirstin Juhl came to software development from a career in manufacturing, where she learned about Lean principles. Now she sees those same principles being applied to software development. In this interview, she describes Lean in both worlds and compares the two.

I am a recent convert to Agile methodologies. 

Until last year, I worked for a large consulting company that had established a solid reputation using a waterfall approach to deliver solutions.

My current employer is committed to the agile methodology SCRUM.  They have developed their own variation of SCRUM and several consultants here have even made a name for themselves delivering presentations on this methodology to customers and at conferences.

So it's only natural that I have been engrossed in SCRUM since joining.  Nine months of agile software development have sold me on its benefits. 

The biggest advantage I see to SCRUM is the short delivery schedule pushed by the sprints.  For those who don’t know, a sprint is a set of features scheduled for delivery in a short period of time (typically 1-4 weeks).  A sprint forces (or at least encourages) frequent delivery of working software and provides a great feedback loop to the development team. 

When users can actually see, touch and use functioning software, they don't just get value more quickly - they are able to evaluate it more quickly and provide valuable feedback.  That feedback might be a rethinking of original assumptions; it might be new ideas sparked by using the software; it might be a reshuffling of priorities, or it might be a clarification of some miscommunication between the users and the developers.  It will probably be several of these things. 
That miscommunication issue is one that occurs far too often on software projects.  Catching these misunderstandings early in the life of an application can save a huge amount of time and money.  We all know that the cost of making a change to software goes up exponentially the later that change is made.

By delivering something useable to the customer several times a month, we are providing value to the customer in a timely manner.  At best, this value comes in the form of software that enhances their ability to perform their job.  At worst, we provide something they didn't ask for.  But this worst-case scenario also adds value because we can use the delivery to clarify the misunderstandings and poor assumptions that leaked through the design.

I think back to the last waterfall project in which I was involved.  Our team was charged with designing and building an integration layer between an e-commerce web application (that was being designed at the same time) and dozens of backend systems (that were in a state of constant flux).  We spent months designing this integration layer.  During these months, the systems with which we planned to integrate changed dozens of times.  These changes included adding or removing fields; placing a web service in front of an existing interface; and completely redesigning and rewriting backend systems.

Each of these changes forced us to re-examine all the design work we had done and to modify all our documents to match the changed requirements.  In some cases, we had to start our design over from scratch.

An agile approach would have helped immensely.  Instead of designing everything completely before we started building anything, we could have minimized changes by designing, building, and deploying the integration service to one back-end system at a time.  By selecting a single integration point, we might have been able to quickly deliver a single piece of functionality while other backend systems to stabilize. 

I'm not going to suggest that agile is the appropriate methodology for every software project or that no other methodologies have value.  My former employer delivered countless successful projects using waterfall techniques. 

But it pays to recognize when agile will help your project and it is definitely a useful tool for any developer, architect or project manager to have in his or her toolbox.