On Thursday I went to the following sessions
- Stages of Practice : the Agile tech tree by Arlo Belshee and James Shore
- The Agile Scaling Model (ASM) : Be Agile as you need to be by Scott Ambler
- Telling better stories with User Story Mapping by Jeff Patton
- Slackers and Debtors : Meet commitments, reduce debt and improve performance by James Shore
On the fourth day of Agile2011, my subconscious brain seemed to have decided that I needed a little fun, because I did a lot of sessions about games and workshops.
It started with the morning session where Arlo Belshee tried to have us create a Civilization like tech tree for Agile. For those who don’t know the game, in Civilization, the tech tree represent a tree of different technologies that you acquire with experience. Technologies are organized in different branches (Sea, Religion, …) and to discover a new technology, it is first necessary to discover the prerequisite technologies (for example, democracy can only be discovered after the printing press). You also have Wonders of the World and many other things that make your civilization more advanced and more powerful. To summarize, that’s what leads your civilization from obscurantism to space travel.
The goal was simple. In small teams of around 5 to 8 people, try to build a tech tree for Agile. At my table, we were five, among which Laurent Bossavit. The session was divided in 4 timeboxed periods where we could introduce ourselves, start discussing about how to represent such a tree for Agile, identify the key notions and eventually build the thing. At the end of each period, on person of each group could come in front of everyone and for one minute sharp, explain what the group had in mind or give some insights.
And here is the result we got at the end of the workshop (all tech trees were displayed in the corridor of the Grand America Hotel, and believe me they did quite a sensation)
I know this doesn’t look like much, but believe me or not, the exercise is not easy. As Laurent Bossavit mentioned, maybe the most interesting is not to analyze the past and how it brought us there, but to imagine the future, what it could bring and how to get there.
The second session was the only talk of my day. No workshop, no games. It was by Scott Ambler, who as he lies to say himself works for a small startup which builds computers to play Chess and Jeopardy. I let you guess. His subject was scaling Agile. Yes, once more, a session about scaling. I think you got it now, this subject was one of my focuses for this conference.
Scott Ambler having a lot of experience in the great corporate world, but also in Agile, his session was somehow presented like a reality check. Let’s face it, we don’t live in a perfect world where all projects can be developed by one small co-located team that has a total freedom to self-organize and doesn’t depend on the kind of organization it works for. Yes Agile is great and works well, but we cannot always turn down projects which require more “documentation”, “governance”, “regulation compliance” and other curse words as Scott called them.
Scott Ambler, like Dean Leffingwell and Damon Poole did, identifies that what makes Agile more scalable is not necessarily a change in the development practices, but more a change in the way we deliver software. At scale, you need what Scott calls Disciplined Agile Delivery.
He identifies 8 Agile scaling factors for Disciplined Agile Delivery
- Team size : under 10 devs <> 1000s of devs
- Geographical distribution : co-located <> Global
- Enterprise discipline : Project focus <> Enterprise focus
- Organizational complexity : Flexible <> Rigid
- Compliance requirement : Low risk <> Critical, audited
- Domain complexity : Straight-forward <> Intricate, emerging
- Organizational distribution (outsourcing, partnerships) : Collaborative <> Contractual
- Technical complexity : Homogeneous <> Heterogeneous, legacy
In the following part of his presentation, Scott went on explaining how to scale some key aspects of Agile software development according to these factors
- Scaling release planning
- Scaling self organization
- Scaling product backlogs
I will not go into details here because it would take far too long. Let’s just say that analyzing things according to these 8 factors really helps figuring things out.
Scott also went on with some recommendations. For example, he recommended to adopt some of the lean principles like
- Eliminate waste
- Build quality in
- Defer commitment
- Deliver fast
- Focus on learning
- Respect people
- Optimize the whole
Same as Leffingwell, Ambler said that at scale, you need to guarantee that you don’t loose sight of the big picture and you keep some key aspects under control. This is done with practices such as : requirements envisioning, architecture envisioning, enterprise awareness, Agile database techniques, independent parallel testing, lean development governance practices, etc.
Scott Ambler’s conclusion was that, at scale, you have to be more disciplined. And to acquire this discipline, you need to address the “5 Ps” of IT
in that specific order of importance.