AGILE IN ACTION: Comfortable with 'emergence'

Sunday, May 28, 2006

Comfortable with 'emergence'

When employing Agile software development it's vital that everyone is comfortable with the reality that, over time, the requirements, the system and the team order will all emerge. Understandably, this makes a lot of people uncomfortable because they're trained to believe that the essence of a project is structured and largely predictable. They want to control the project using a plan that attempts to predict future events based on assumptions made up-front about the stability of the requirements, business landscape, team and estimates, and the accuracy of the information available.

By letting things emerge you're accepting the inherent uncertainty and instability in a project given the inadequacy of information available. By planning adaptively, you steer the project in response to new information that emerges through feedback, rather than controlling it based on predictions made in an up-front plan. The driving force is to deliver what is needed today based on what is known, and not to plan what you think is needed tomorrow based on what you think will happen in the future.

New and modified requirements emerge from feedback on earlier implementations, shifting business priorities and modified user needs. Using iterative and incremental development the final system emerges from progressive working increments that have been adapted to accommodate these changing requirements. Through self-organisation rather than hierarchical command and control, a team organisation and working order emerges based on common values, principles and practices, a shared vision, and intense collaboration with the customer. The team is empowered to decide how best to utilise resources, skills and technologies to best meet the requirements, deliver business value and maximise return on investment for the customer.

Trying to limit and control changes results in the delivery of a solution that is compromised by cost and does not meet the real needs of the customer exactly. Through feedback mechanisms, Agile software development is geared to respond to change ensuring that what is delivered is actually needed by the customer and not just what they thought they needed at the start of the project.

Tags: agile, adaptive planning

2 Comments:

At permalink, Anonymous said...: Very well said. Do you see anywhere in software development where the use of an up-front plan would be appropriate? Or, are all software development projects better suited to an emergent model?
At permalink, sjb140470 said...: Thanks for your questions. (I wish you'd signed your comment :-).

It's really up front planning in detail that I consider wasteful. There has to be a little bit of up-front planning to do no more than set the direction forward. The challenge is to do the right amount of planning and at the right level of detail to achieve this. All projects should be suited to emergence. Certainly in all the situations I've encountered, the feedback obtained from writing code is more real and accurate than any predictions made during up-front detailed planning. I also believe that working software is the best measure of progress. The guys at 37signals race to running software because it gets everyone closer to true understanding and agreement. (I strongly recommend reading Getting Real.) Working software is tangible and meaningful and it quickly reveals issues, risks and ideas that don't work. So start writing code quickly and make it run, make it right, then make it fast. Producing working software is the best way to build momentum in the project.

However, it's important to provide a flexible frame for this work otherwise it may go around in circles and end up going nowhere fast. I ask the team and customer to work together to complete 2 simple planning activities up front. The first activity is to define and publish a vision that captures the purpose of the project and guides the team's decisions going forward. I have them do this as part of a chartering session. The second activity is to construct a roadmap comprising only realease goals or themes. I have them do this in a facilitated workshop. The beauty of goals or themes is that they carry meaning but are also inherently ambiguous. This ambiguity makes them more resilient to change, keeping them relevant and stable over a longer time, and provides the team with latitude to maneuver in response to change.

Emergence is coped with more effectively by disciplined Agile teams that collaborate intensely with proactive customers operating as an integral part of that team. Employing all the practices of Extreme Programming provide the team with the skills and safety nets to harness change.