The second day of the GOTO Amsterdam 2013 conference stared with a keynote by Martin Fowler on software development in the 21st century. He explored the reasons why agile was started in the 90s to discuss how teams can become fluent in agile, and reach for the stars.
Agile started as an answer on projects that were late, delivering buggy software to unhappy users, and had developers that were demotivated by this. Plan driven methods were used at that time to develop software, and Martin compared them to agile. Agile differs as it uses adaptive planning where plan driven uses predictive planning. Where agile focuses on the people, plan driven methods are mostly about processes. In plan driven methods there are separated steps to plan your work, and work your plan, and success is defined as “according to plan”. Since the plans depended on requirements stability, plan driven methods wanted to stabilize requirements, where agile wants to break the dependency between plans and stable requirements by embracing change.
As Martin mentioned earlier, agile also differs with plan driven on how it views processes and people. He showed how agile has a shift in mindset to “people first” in stead of “processes first”. Software development processes in plan driven methods are viewed as consisting of steps and links between steps, involving people who will follow the process. Agile takes a different approach, by starting with assembling good people into a team, and then let the team decides on a suitable process. Martin stated that it is “wrong to command a team to become agile”. Team will chose themselves to do things agile or not, and that’s ok.
This brings up the question when teams should agile, and when not, and how fluent they want to be in agile. Diana Larsen and James Shore wrote about Agile Fluency, and Martin published their article in your path through agile fluency. Diana and James defined fluency as:
Fluency is how a team develops software when it’s under pressure. Anyone can follow a set of practices when given time to focus in a classroom; true fluency is a skillful, routine practice that persists when your mind is distracted with other things.
Martin presented how teams can increase their agile fluency, from a first star level up to four stars. At the first star level, teams divide the work up in individual chunks to deliver business value. You need to invest in team development and process design to reach this level, it typically takes 2-6 months for a team to reach it. Teams at the two star level “ship on the market cadence”; realizing more value by delivering as often as their markets can handle. An investment is needed in technical skills and practices like XP, TDD and pair programming to increase software craftsmanship and get a productive team which delivers software with less defects. It typically takes teams 3-24 months to get on this level.
Teams on the third star level are optimizing their business value using metrics, and teams on the fourth star also contribute to enterprise wide success. Martin mentioned that he doesn’t see many teams on star level three and four. He suggest for teams to think about which level that they would want to reach, and if they are able and willing to do the investment.