To make it simple, “Agile” is actually a management tool to deal with conflicts of interest during the life cycle of the project. Wayne used a case study to give us a brief introduction to.
The case was about an information system development project in a financial institute in Australia. It took 18 weeks to complete the project with a budget of 2 million Australian dollars, where 15 core team members were involved. So you can see it is sort of a small-scale IT project. To make a better planning, they spent totally 2 of the 18 weeks conceptualising the project and finalising the project plan. During the 2 weeks, 12 people were involved in 2 workshops per day (2 hours each). The workshops firstly defined high level concepts of the project, followed by a formal inception where things they needed to kick off the project delivery were determined. That included setting the direction, identifying scopes, proposing solutions and writing up the plan.
Wayne showed us a number of photos of the room where the workshops were held. Papers and sticky notes were everywhere. It is like a typical brain storming scene. One of the sticky notes was written by a line manager who stated one of his requirements for the new system, e.g., “I want to be able to…” All of these sticky notes were arranged and assembled to make a whole picture of all the possible scopes by the end of the series of workshops.
One important task to complete during the Inception Phase is to define success. First of all, they listed all the possible items which were considered as a factor of success, e.g., delivery on time, delivery on budget, scope quality, requirements, team satisfaction, stakeholder satisfaction, etc. Then they let their VIPs to rate each item’s importance. Such exercise is critical for better change management at a later stage of the project.
Wayne then moved on the Estimation Planning. I like the quotation he mentioned: Plans are nothing; planning is everything – Dwight Eisenhower.
In Agile Project Management, the planning involves four steps, namely Identify Stories, Prioritise Stories, Size Stories, and Plan Stories. The term “story” here refers to individual scenarios when the new system is in place. To facilitate these four steps, the technique of using Planning Poker should be introduced.
Planning Poker is a useful tool for estimating software development projects. The picture on the right shows a deck of planning poker. Individual stories are presented for estimation. After a period of discussion, everyone chooses from their own deck the numbered card that represents their estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed at once without identifying who an individual card belongs to. This technique helps each participant do their own estimate privately at a meeting without the influence others. The estimation coming out of the planning poker procedure tends to be less optimistic and more accurate.
In the case study, Wayne also introduced a poker chip approach to determine the scopes. After the estimation has been drafted out, their project sponsors and stakeholders were given a certain amount of poker chips and invited to “buy” the scopes they wanted on a large table where all the scopes were presented. According to the photo Wayned showed, it was just like a gambling table with squares of different sizes. In fact, the poker chips represent all the effort and resources available. Each scope has its “price” – the minimal chips needed. This scope buying process is a way to further confirm the importance of the scopes and to determine if some scopes are still necessary when the resources are limited.
When the project was formally initiated and things were starting to work according to the finalised project plan, a burn-up chart (y = story point; x = time) was used to dynamicly show the current status of the project. Agile project management breaks down the whole development process into iterations, which are individual repeated work units, producing finished parts of the final product. In other words, at the end of each iteration, there will be a finished part of the final product. This is quite different from the traditional waterfall linear style of project management where parts of the final products would usually emerge in the last stage of the development phase. Having a finished part of the final product in each iteration enables the burn-up chart to show exactly how much of the product has been done at a particular time, no matter by story points or by percentage. The trend line can also indicate if the project is currently ahead of or behind schedule (i.e., the larger the angle, the faster the project is going).
As the project is going, the need for scope change would emerge. This is inevitable, but how can we handle it properly? Remember the poker chips that the sponsors and stakeholders used? Remember the stories point determined by the planning poker? Wayne continued to introduce a technique to properly accept the request for scope changes. That is, any new stories must be traded by another stories that have not yet been developed or delivered by moving the poker chips. So what happened in the case study was that they removed some of the scopes so that the new scopes could be accepted.
Overall, the taste of agile project management initially gave me three points:
1. Physical instruments are useful, even in the information age. The sticky notes, the planning pokers, and the poker chips set the tone of “non-negotiable”, “limited resources”, “moving and trading instead of deleting and adding”, etc.
2. Open your mind to accept that change is inevitable. It is critical that you have an approach to deal with the change, and you need to prepare for that in advance.
3. Project management is dynamic. A fixed plan will never work. However, flexibility is not an excuse for project failure. There are a lot of techniques that could help balancing the changes and the “project success” defined originally.