Agile and just-in-time approaches to development are not new. Methodologies that favor providing the customer what they need, when they need it work quite well. However, there are numerous ways in which agile development can fail. I would argue that it’s easier for most organizations to fail at agile than it is for them to succeed at agile. But what is it about agile methodologies that make them difficult to implement? This discussion examines a few of the symptoms that an agile process may be doomed.
Just-in-time (JIT) manufacturing theory calls for elements to be delivered only when they’re needed and not before; don’t build out parts or inventory if it’s not needed at that moment. When applied to development, the theory often means building only those pieces that can be accomplished in a release and releasing early and often.
However, there’s a key difference between JIT in manufacturing and JIT in software development. In manufacturing the final product and indeed the parts that make up the final product have gone through an architecture and design process. By the time anyone gets to actually making the parts, the boundaries within which the part will operate are well defined.
Too often, software development with JIT principles means doing design and assembly simultaneously. The design-while-assembling approach leads to systems that don’t interoperate and an end product that’s not architected for reuse and support.
An organization might have a team of superstar developers who can seemingly take on any task before them. The plan to implement agile processes begins by taking those developers and having them attempt to work a project through agile iterations. However, none of the other teams are agile and none of the prerequisites (cross-functional team, product owner, and so on) are in place on the newly christened agile team.
An agile process needs to be followed by IT as a whole. Without it, certain teams like quality assurance or backend database administrators will become bottlenecks for getting software released in a timely manner. Cross-functional teams that include QA, a product owner, and developers should be empowered to make decisions and work independently of any other project processes.
At times the in-process release includes late-found bugs and features that were more difficult than estimated. Rather than hold up the release, those items or pieces of those items are moved to the backlog and the release goes out on time. The team is happy because the release went out on time. However, the end users aren’t happy because the promised features aren’t ready, there are visible bugs, and features that worked previously are missing or broken because the new feature was supposed to replace them.
Too often, the backlog is used as a way to ensure that dates are hit rather than as a means by which priority can be given to features. The backlog should be used for prioritization and coordination and not as a means to bury failure. Moving a release by a day is better than releasing faulty software.
Succeeding with agile processes means using the methodologies for their intended purpose and not trying to use them as if they’re magic. Design and architecture need to be in place so that the actual development takes place within the bounds of the design. Creating an environment where agile teams are fully supported is difficult but necessary in order to be agile and software should never be released unless it’s ready. Not correcting those three simple issues will prevent success with agile.