For those project managers familiar with Gantt charts, certification, and maturity models, Agile projects may appear like disorganised chaos.
If you are unfamiliar with the Agile methodology, this is a glimpse into a world that is quite the opposite of what it seems, a world that is highly organised, with teams that have clear focus and are producing results that delight stakeholders.
The Manifesto for Agile Software Development was signed in 2001, but this had been preceded by the increasing use of various iterative and lightweight approaches to software development, such as RAD, Scrum, DSDM, and Extreme Programming.
Agile is now firmly rooted as a respectable approach to project delivery, most often contrasted with the traditional, and typically more heavyweight, Waterfall methodology.
It’s hard to dismiss something that is being widely documented as a key contributor to project success. I’m reluctant to cite too many statistics here, as project success is defined in so many ways, but the Standish Group 2011 Chaos manifesto have some figures, as does Dr Dobbs with his 2010 analysis of IT project success rates.
Is this something you can afford to ignore? If you look at the jobs currently being advertised in Australia, there are over double the number of positions on Seek calling for Agile skills than those advertising for PRINCE2. If you take professional recognition as an indication of maturity, then you’ll be interested to know that the Project Management Institute now offers an Agile Practitioner certification.
Planning an Agile project
The Agile Manifesto says to value responding to change over following a plan. Planning on Agile projects accepts that change is a normal part of a project process, and can result in the project realising greater business value.
Planning happens regularly and often, but only in detail for the immediate future, for the work that the team are about to do. Planning for the longer term is done at a more coarse-grained level. This allows us to delay committing to the detail until we have built knowledge about the product. By doing this, we can both take into account the experience we have gained, and we can cope with change more easily and with lower cost.
Planning on Agile projects is outcome based, rather than task based. This results in the measurement of project progress being based on realisation of business value rather than completion of a task on the project plan.
What is an Agile project?
People often enquire as to whether and lack of detailed planning increases the risk of scope creep. Any piece of work (or product) that’s introduced into the project should be related directly to an expected project outcome. This is true for both work initially counted as in the scope of the project, and also for any change introduced during the project lifetime.
Agile projects often use something called User Stories for requirements: these include a stated business value to be achieved as a result of implementing this requirement.
User Stories in Agile
User Stories are normally written from the perspective of the end user of the product, and so are easily understandable by all stakeholders. This leads to high visibility to all stakeholders as to the work being done, and to the work that’s been prioritised to be completed next.
There are regular and frequent opportunities to review the work that the project team has done and is being asked to do next, and to course-correct if necessary. This review isn’t done by just the project manager and project team, but by all of the project stakeholders.
If we are ask to introduce work into the project that doesn’t relate to a project outcome, this would flag up that the document that defines the project, the project charter or business case, needs to be reviewed with the project stakeholders.
User Stories have a standard format: As a user, I want to do something, so I can achieve some business value. For example: As a registered bank customer, I want to filter my bank account transactions by a date range so I can see what income and expenses I had in that period.
Completing this piece of functionality will normally require people with different skills to work together. This increases collaboration, as the team are actively exploring ways to reduce the work for the whole team, not just for themselves.
Estimating for Agile projects
Estimating on Agile projects is done collaboratively, and includes the customer as well as the development team. The practice of relative estimating, making use of a tool called Planning Poker, is very popular with Agile teams.
Since each User Story is estimated in this way, it is a highly effective way to ensure that there is a shared understanding of the customer requirement. There is a guide on Story Card estimating (Planning Poker) on Solnet Solutions > Tools.
As the customer builds up trust and confidence in the team’s ability to deliver against these estimates, these highly collaborative estimating sessions become a very effective planning tool. Priorities and trade-offs can be very readily understood; for example, a User Story of low business value and high relative effort to deliver may quickly be discarded. Agile is about minimising the amount of work done to achieve the required result.
My objective was to respond to some of the comments I’ve heard about Agile, and to answer questions I’ve been asked related to planning and estimating. I hope that I’ve piqued your interest, and that you are keen to peep further under these covers.
Powered by Facebook Comments