Agile Case Study: Living the Dream...

Implementing Agile

Given my revelation about how Agile should be run without compromises and in a Lean and lightweight manner, I'm trying to run my current project in this way and seeing what gets in the way. I'm expecting the organisation, its culture or its people to put lots of blockers in the way, so I'm going to document how it goes in this article. But lets not start off with a negative attitude.

Kick-off

I'm kicking off the project with a Story-writing Workshop. I'm getting everyone who has a say in the project into one room and getting them to identify the customers of the system, and what their Role is. Then I'm going to get them to write all the stories they can think of from each Role's perspective. I'm not going to reject anything during the session, and I'm trying to keep the session quick and lightweight.

The Session

Got everyone to introduce themselves, and immediately I've got the advantage that everyone knows everyone involved in the project and their role. I got a load of pens and post-its and quickly introduced the concept of a Role as customers of the system. I asked everyone to write down the Roles they thought were relevant to this system.

I then introduced the concept of a Story as "As a [role] I want [a capability] to [deliver an outcome]. The Who, the What and the Why. I gave a couple of examples, then everyone got on with writing stories. After they had finished, I collected up all the post-its, said what the next stages were, and ended the meeting.

Processing the Information

During the session, I stuck all the Roles on a board and grouped them by role area. I included the duplicates to create hot spots that highlighted the most common roles. I noted them all down in Visio and binned the post-its.

I then took all the stories and put them in Word, and each time a Role was used, put a mark by that Role. This helped to identify the Roles that had the most relevance to the system. After consolidating the stories and organising them by Role, I colour coded the Roles Visio diagram with red for the most used Roles down through orange, yellow to blue for those roles that didn't have any stories put forward for them.

Clarifying Stories

I went through the stories, consolidated them and ordered them by role. This made it easier to identify the real roles that were important to the system, and I tweaked the roles in the stories so that they were consistent with each other. I put the roles at the top of my story document and described each role. We now have a fairly sensible set of stories, and we are fairly clear on the roles.

Release Plan

As part of the workshop, one interesting piece of information that I uncovered was that we need something in live in three weeks. This puts us under extreme pressure to deliver straight away, which is not really what is needed when you're trying to guide everyone through a process that is new to them.

We need to put high level estimates by each story to allow us to do the initial prioritisation and release planning. This is where things start to get tough. Various stories involve lots of existing products and processes that need to work together in new ways, or have the new system integrate with the current processes. To make a sensible estimate, even at a high level, we need to understand these other systems and processes. We need to talk to about three or four different technical areas within the organisation, but these people aren't available. We need to get our Truth, or Customer to clarify their stories, but they aren't available for a few days either. We need a Project Manager to pull things together, and a Dev Lead to arrange the technical meetings. None of them are available. We can't finalize the stories, we can't estimate or prioritise them and therefore we can't start work.

The Deadline

The business are extremely focused on getting something out by the end of the month, and will be annoyed if they can't have it because of the time-sensitive nature of the business case. We are losing days trying to get the information that we need to start the project. It is already July 7th. We will need a week to progress through the test environments and into live. Allowing a couple of days for system testing before we progress into the pre-live environments, this leaves us with 8 working days to develop the whole system.

Given the number of elements required just to fulfill the most basic system, we obviously can't hit this deadline. However, I find that promises were made to the business by various people in Development during the Propositions process, assuring them that something could be live by the end of the month. Various solutions had already been initiated prematurely without clear requirements or a release plan. I can feel that people are getting impatient, and the perception is that the process is delaying things.

The End

By the time I get in on Monday morning, the Business have demanded that Development keep their promise of hitting the end of the month deadline. Things go on over my head, and the conclusion is that the the project must continue using the JFDI methodology. I step aside, disappointed but not at all surprised. The company has rejected Agile and XP, and that's a real shame. However, its better to have this confirmed than labour under a misconception.