Magic Milestones

I was discussing Agile at XP Day last November with a small group of people who were interested in how the methodology is evolving. While we evangelistically debated ‘What is an Agile project?’ it became clear to me that there are a couple of key Agile principles that lead to successful project delivery and that without them you may have a team working with agility but the environment is fundamentally not Agile (big ‘A’ versus little ‘a’). When I say Agile principles I don’t necessary mean an item from the Agile manifesto and, although the two are intrinsically related, in this case I mean a key principle that makes projects succesful. As the debate went on it emerged that there are usually two distinct environments where this sort of conversation becomes important

1) ‘Blue sky’ development environments where software teams are coming up with new, innovative solutions or inventions.

2) Environments where software teams are developing applications that support existing business processes.

These two environments have different needs and different areas for emphasis (I think of it as the difference between being a genius and being useful! Don’t get excited – they’re not mutually exclusive). I envisage that projects in the first environment do not start with a commissioned piece of work from an end user. They may indeed meet a business need but I see them as proactive initiatives where the second environment is reactive to business need and usually a commissioned piece of work. (A combination of the two environments does sound like an ideal workplace but I’ve never had the good fortune to work in such a Nirvana!) For example, developing a payment processing system for an online retailer would fall into category two. Creating Facebook would fall into category one.

I work in organisations where the projects are in the latter environment and exist to support or improve the core business process. On my current project we are extremely lucky to be working in teams that have full time, 100% committed business representatives as part of the team. I feel that this one of the most important success factors of an Agile team – having the customer or business user as part of the development team. The absence of this team member leads to the situation of ‘throwing the pig over the wall’ which is prevalent in waterfall style projects. The development team build something and hand it over to a business user for approval – they throw the pig over the wall. We all know the pitfalls of this approach and I won’t go into them in this post but I’d like to sing the praises of the opposite situation – having the customer as part of your team.

Rarely are we fortunate enough to have the customer as a 100% committed team member on projects but on my current project we do. We no longer have an approval process or sign off as the customer is working with the designer and developer every day and is involved in the decisions about what the product is going to look like and act like when it is launched. This saves time as there are no delays while we wait for feedback or approval or changes. On my current project I am managing the delivery of 3 web sites which are each being developed by cross functional teams containing one designer, one client-side developer, a producer (this business is in broadcasting and media) and a business representative. When the up-front costs of a project are estimated this can look like a scary financial commitment to a customer as the business representative is no longer doing their ‘day job’ and may need to be backfilled but it is wise to balance this cost against delays and reduced customer satisfaction from not having ongoing customer collaboration. Customers who are involved in the project and who are fully engaged also understand the pitfalls and setbacks that can arise and are therefore more understanding when it comes to de-scoping or modifying requirements when need be. Responding to change becomes part of life rather than an exception report or bad news.

My enjoyment of being a Scrummaster in a team that is the full complement is only one benefit to this team structure. Other topics that arose at XP Day become less fraught if you have the customer fully collaborating on your project. For example, at XP Day 2008 there was a lot of confab about ‘user requirements’ and how to ask the right questions to elicit requirements. If the customer is part of your team this becomes less important as the requirements elicitation is no longer a traditional business analysis task – it becomes about talking and listening and ongoing collaboration and communication. The emphasis is no longer on getting the questions right up front because you can adapt and change every day as you collaborate. You don’t need to become an expert in Socratic Method (as was suggested) if the refinement of user stories is an on-going conversation. There is a lot of benefit to asking the right questions every day when you are trying to learn, this is true in life in general as well as on development projects, but adapting to change by listening and having a conversation as opposed to interviewing customers leads to successful projects.

From talking to other attendees at XP Day I learned that a lot of organisations have employed a half-Agile approach (they don’t call it that, they say they are Agile in their development method). In these situations the technical teams follow some Agile principles (usually by getting minimising documentation) but the customer is not involved in the teams and there is a culture of ‘deliver to’ and ‘gather requirements’ rather than collaboration.

I feel that this is a common trap and one that I’ve seen in a lot of organisations. I appreciate that not all organisations have the luxury of providing a full time user to become part of the project team. The questions that then form in my mind are about what constitutes ‘success’ but that is the subject of another blog post… I think I’ll call it ‘throwing the baby out with the bathwater’. Stay tuned.

Oink oink