This chapter is from the book
This chapter is from the book
This chapter is from the book
Don’t Blame Agile
In the 1969 film If It’s Tuesday, This Must Be Belgium, a tour guide leads groups of Americans on fast-paced sightseeing tours through Europe. As far as touring is concerned, this is a classic example of travelers going through the motions.
The same kind of tour can happen with agile software development. “It’s 10:00 a.m. and we’re standing. We must be doing agile.” With reference to daily standups, going through the motions turns otherwise valuable project communications into mere ceremony. Reading Scrum.org on the topic “Agile: Methodology or Framework or Philosophy” is a real eye-opener. At the time of writing, there were approximately 20 replies to this post, and about as many different answers.7 A reasonable question regarding this concern is, why should that matter?
Recently, agile software development has drawn a lot of criticism. Perhaps most of the criticism is directed toward a specific project management methodology for which mastery certifications can be obtained after a few days of training, because the two are often conflated. This is a sad state, given what agile software development should represent. Much of the industry claiming to use agile methodology or to be agile can’t really define it, as noted in the previous Scrum.org experience.
The original agile philosophy never promised to turn poor software developers into good software developers. Has agile made any promises at all? There’s a mindset to developing software in an agile way (the Agile Manifesto), and there is a history behind that [Cockburn]. As already observed, agile can’t even cause developers to embrace that mindset.
Consider one problem. The ideas of agile software development have been reduced to arguments over whether to refer to this approach as Agile, agile, or “Agile.” In fact, we could even draw fire for referring to it as an “approach.” So, from here on, we will refer to “it” no longer as “it” but as #agile. This terminology is intended to represent every possible use. However each individual chooses to spell #agile, software developers must demand to get more from #agile than #agile takes from them.
Consider a second problem. A vast complexity has become wrapped around some rather straightforward concepts. For example, the terms and steps of #agile are actually presented as subway maps. At least one high-end consultancy represents its #agile approach in the form of a map of the New York City or London subway/tube system. Although traveling anywhere on an extensive subway network is not extremely complicated, most wouldn’t choose to take every route in a large system on a daily or weekly basis just to reach a necessary destination, such as the workplace in the morning and home in the evening.
This is all very unfortunate. Many have hijacked #agile and moved it far away from its origins, or simply travel in naivety. Usage should be far simpler. Working in #agile should boil down to these four things: collaborate, deliver, reflect, and improve [Cockburn-Forgiveness].
Before accepting any extraneous and elaborate routes, teams should learn how to get to work and back home in these four basic steps:
Identify goals. Goals are larger than individual work tasks. They require collaboration to find the impacts that your software must make on the consumer. These kinds of impacts change the consumers’ behaviors in positive ways. They are recognized by consumers as what they need, but before they even realized their need.
Define short iterations and implement. An iteration is a procedure in which repetition of a sequence of operations yields results successively closer to a desired result. A team collaborates to identify these. Given project pressures, unavoidable interruptions, and other distractions, including the end of day and week, teams should limit work items to a number that can be readily remembered and grasped.
Deploy increments when legitimate value is achieved. An increment is the action or process of increasing, especially in quantity or value; something gained or added; or the amount or degree by which something changes. If delivery of value is not possible by means of one day’s work, then at least an increment toward value can be reached. Teams should be able to string together one or two additional days of iterations and reach value delivery.
Review the outcome, record debt, go to 1. Now reflect on what was accomplished (or not), with the intention of improving. Has the increment achieved an intended and vital impact? If not, the team may shift toward another set of iterations with increments of different value. If so, note what the team sees as reasons for success. Even when reaching delivery of some critical value, it is normal that an incremental result doesn’t leave the team feeling entirely successful. Implementation leads to increased learning and a clearer understanding of the problem space. The iteration is time boxed and doesn’t leave enough time to immediately remodel or refactor current results. Record it as debt. The debt can be addressed in the next iterations, leading to an increment of improved value that gets delivered.
Planning too far ahead will lead to conflicts in goals and execution. Going too far too fast can lead to purposely overlooking debt or forgetting to record it. When under heavy pressure, the team might fail to care for debt sooner than later.
The few steps identified in this brief overview of essential #agile can take teams a long way forward. This is the mindset that experimentation affords, and what #agile should primarily be about. It’s possible to get more out of #agile than #agile takes.