Agile - A Project Manager's View
Background to an Agile Introduction
As a PRINCE2® Project Manager, the assignment to deliver a replacement system for an underground asset (pipes and sewer) viewer was quite standard. An estimate had been produced, circa. £700K, using the waterfall method, along with a high level set of requirements and an infrastructure design. The normal caveats had been given and the job was there to proceed, when a new programme director was appointed. It seems the new director had recently experienced a "conversion" to Agile.
The new director was keen to ensure his conversion would propagate within the organisation. So I found myself "volunteering" to do the first organisational Agile project.
The organisation was looking for more value from their IT projects, with the too frequently stated complaint of "IT projects are always late, cost more than agreed and seldom deliver what is needed!". Whilst this statement may sound cliche, it is unfortunately a common business perspective. Agile provided a mechanism to show IT was listening and to bring greater engagement of the business into the IT projects. Additionally, there was extensive evidence to suggest Agile did improve the return on investment in IT projects.
Having succeeded in identifying the first Agile project and securing management commitment to the approach, it was time to form the team and initiate the project.
The sponsor had a "Senior User" (PRINCE2® term) already on the project board and eager to get more involved with the development team. This senior user was an obvious candidate for the job of "Product Owner" (Agile role). Next we recruited the key development people for the project, which included developers, testers and an architect - note we did not have a business analyst (this role would be shared by all members of the team).
Something quite different with Agile from PRINCE2®, you have all your roles present from the beginning of the project (everyone starts at the beginning).
The Product Owner went through the high level requirements, providing us with more detail, which was keyed into the Product Backlog (Agile term) to create stories (Agile term). In order to help the Product Owner determine the order he wanted the stories built, the team used the "Planning Poker" (Agile term) technique to score each of the stories in the backlog. (The scores are a crude estimated combination of time and complexity, based on a score of '1' being the production of a simple web screen).
The project and team were ready to start building, our first sprint (Agile term).
The Product Backlog provided the ability for the team to define and build order and coupled with the agreed Sprint duration, in this case 2 weeks, we set what we would build in our first sprint.
It was decided that for the first sprint we would look to deliver 30 points (from the crude poker planning scoring). Picking off the first 5 stories from the Product Backlog, each story was broken down into tasks, grilling the Product Owner for more requirement detail of each story, in order to estimate the tasks in hours. A team member was assigned to each task.
As there was still no detailed requirements, only the Product Backlog, it was essential that the Product Owner was on hand to answer further detailed questions, as they arose, e.g. "What colour do you want this screen?".
It was agreed that a definition for "finished" was needed, so that project monitoring and reporting could be stated within a mutually understood reference. We agreed that "finished" meant the story was unit tested, ready for handover to the user acceptance testing environment.
On a daily basis team members would input their actual and perception of remaining time required for each story. The input facilitates the creation of a "burn-down chart" (Agile term). The burn-down chart tracks efforts remaining, reducing by the amount of effort going in from the team and overlaps this tracking alongside the baseline (a straight line graph from beginning to end). The purpose of the burn-down chart is to denote "relative" progress of the team, our "velocity" (Agile term). The burn-down is on open display and provides all team members with an ability to see their progress.
Each day would start with a 15 minute "scrum" (Agile term), where the team would stand-up and take it in turns to state what they had completed from the previous day, what they would complete today and what blockers (Agile term), if any, were getting in their way. It is the project manager's responsibility to clear the blockers.
At the end of each sprint, a demonstration of the "finished" stories is presented to the Product Owner. Any unfinished stories go back into the Product Backlog, to come out again, possibly in the next sprint, or maybe not, the Product Owner makes the call. Change management is very efficiently managed as the Product Owner decides priorities and hence how a change is managed.
Separate to the demonstration, which focuses on examining the "product" there is a brief, ideally 15 minute, "retrospective review" (Agile term). The retrospective review aims to examine the process, allowing the team to identify what went well and what not-so-well. The team can focus on ensuring what went well is repeated and the project manager focuses on how to mitigate what didn't go so well from repeating.
Each sprint repeats the pattern of plan, execute and demonstrate, working through the product backlog. Each sprint provides greater confirmation on the project's velocity and aids in setting out what efforts remain. General team productivity increased as members became more comfortable and confident, which greatly aided in ensuring reviews and meetings were brief as Agile intends. Innovation came from all members and sometimes in project areas not traditionally the domain of the individuals who initiated.
The project manager monitors the costs and keeps the Product Owner informed, particularly in terms of time and cost. In this particular project by the third sprint a significantly higher degree of credibility had been established.
It was without surprise for the business when it was reported that there was insufficient time or money to deliver everything in the Product Backlog. The Product Owner had full disclosure of the reasons and clearly understood the validity of these reasons and hence confident that the business was getting the right value from the budget. The business, Product Owner, was stating requirements, setting priorities, confirming progress and managing the project boundaries - the business felt in control.
An unexpected benefit, as stated by the Product Owner, was in how Change was managed and in particular how Change management worked for the business. The Agile approach had enabled them to operate Change in the project with minimal disruption. The Product Owner believed the project had delivered well beyond what might have been, whilst not delivering to its full original remit.
As the project's funds finished a credible system was delivered into the User Acceptance Testing environment. The system satisfied the highest valued requirements of the business, leaving the "more expensive to develop and/or less business beneficial" stories behind.
If the existing system, which was showing symptoms of failure, had met with a catastrophic failure during the project, the new system would have been able to implement and provide around 60% of the features required, after the third sprint. This is significantly different to a traditional waterfall approach, where little or no credible solution is available until the end of the project and if funds prove insufficient then no solution may be provided.
Many projects have external dependencies. If the external dependencies create delays there is a challenge in sustaining the Agile team, which will have pressures to "move on". Agile's focus on teamwork, cohesion and iterative product drops inherently reduces some of the mitigation techniques used by other project methodologies such as PRINCE2®. Documentation may be less than required to enable quick pick up by others so delays that allow members of the team to be redeployed present significant risk that needs managing.
Agile certainly brings a valuable methodology to the project managers' toolkit. Agile is not a panacea, but it is a sound and effective approach for the right projects and fits well within more established methodologies such as PRINCE2®. Agile is very much about a mindset and whilst the project attributes are important the team is equally, maybe more so, important.
Having applied the Agile approach, in particular the sprint technique to deliver a set of business analysis designs, to a tight timescale, I can confirm how Agile can be adopted within and beyond what traditionalists suppose. The Agile approach shows immediately, issues with delivery, which as a project manager is invaluable.