July 30, 2015
As you have probably noticed by now, I am a huge fan of Agile approaches and ways of working. This post is about some of the key aspects of Agile projects that I really like.
These 12 characteristics really highlight the key benefits of Agile project management, and how they relate to some of the areas of concern I had when leading traditional projects. I hope that you will find them useful as well.
Is anything more important than project success? Multiple studies have shown that Agile and Scrum projects are more successful than traditional ones, and fail less frequently. I’ve written about Agile project success rates in my blog, Agile Projects are More Successful than Traditional Projects.
Most of us would agree that communication is an important, if not the critical part of successful projects. Traditional projects tend to focus on communications that provide a document trail, or protect us in case something goes wrong. Traditional project managers send emails to confirm conversations and they record decisions and changes for the primary purpose of knowing who to blame later if things go wrong.
By contrast, I like the less formal and more intimate forms of communications that Agile teams use. I like the frequent and focused daily team communications that occur during the short daily meetings that Scrum teams use.
I also like the concept of pairing (2 people working together) from XP; it helps share knowledge and build stronger teams. Finally, I have a strong preference for using the most intimate communication mode available (i.e. face to face meetings) rather than email.
Organizations benefit from teams that are clear about their progress. A recent study of PMO leaders showed that 58% didn’t believe that project managers provided accurate status reports; the PMs were misrepresenting the true status of the projects they managed.
You probably have seen this for yourself. There are those projects that are green right up until the due date and then they are red when they miss their go-live date. There are also watermelon projects – those that are green on the outside but red on the inside. It doesn’t need to be this way!
Improved project visibility has been a key benefit highlighted by those who use Agile in VersionOne’s Annual State of Agile Report. In the most recent study, it was identified as the second most important benefit with 66% of respondents reporting that they experienced it.
Agile team status and progress is typically posted in a public place, displaying clear progress against plan, with nothing hidden and no surprises. Updates are often daily, but at least weekly or at the end of the sprint. And the PM is no longer responsible for acting as the agent between the team and the customer or management.
On Agile teams, the people working on the tasks are responsible to provide clear and transparent progress reporting at the person-task level, rather than the project manager running around and collecting the information.
Agile tasks are intended to be granular enough that they get done by one person in about a day or less. Task reporting is tracked to one of three states: “not started”, in progress or done. Teams don’t waste time trying to guess “what is the % complete” for a task, deliverable, or project.
Another subtle point about progress reporting is that Agile teams only report task status to their own team members, there is no one else who needs or uses the information. External progress reporting is done at the working software level.
I’ve worked on a lot of traditional projects and it was rarely possible to predict with any certainty when things would be completed. I’ve seen too many projects where it was on time right up until the date for launch or go live, and only then was it late.
Those are unwelcome surprises! If you don’t have accurate forecasts, it’s not working! Technology projects are complex and unpredictable. By contrast, Agile teams have fast and effective ways of estimating the work remaining and when the overall project will be completed.
The teams use the actual delivery of working software (i.e. velocity) as a predictor and they track it on a weekly or bi-weekly basis.
I’ve been on large scale projects and programs that spanned multiple years. These long time frames led to a number of issues; lack of focus or sense of urgency, snow-plowing work to future phases, and unpredictable timeframes and costs.
Agile teams break work down into short iterations of 1 to 4 weeks. Each short cycle produces something of value to the end user or customer.
In Agile projects, those short cycles allow for constant feedback and short feedback loops. Used correctly, the team gets feedback right away about the product they are building and whether it meets customer needs.
The main tool for learning on traditional projects was the post-mortem at the end. Lessons learned at the end of the project are usually a big waste of time, as I wrote in my previous post.
Who reads those or acts on the lessons learned from the end of a project? By contrast, Agile teams incorporate feedback on a regular basis. Each day there is often a point of reflection, and a regular team retrospective (structured lessons learned) occurs at least every 2-4 weeks.
There is an old project management saying that we “plan the work and work the plan.” There is an assumption that if we can plan it, we can deliver it. The truth for many types of projects is that they are just too complex to be able to plan the work up front and deliver against the plan.
Some of the best teams I have been on have adopted rolling wave planning to deal with this challenge. With rolling wave planning, teams plan in detail only the work that is immediately in front of them, and they spend less time planning work that is in the distant future. Agile teams leverage rolling wave planning to defer planning in detail until the last responsible moment. And they continually replan throughout the project, based on the latest learnings and insights.
One of the main reasons that companies are adopting Agile today is because of the pace of change. It is a highly competitive landscape and most companies are under pressure to deliver faster and faster and to be able to pivot and change direction in response to customer needs or competitive pressure.
With Agile approaches, Agile is expected and even welcomed. This is one of the 12 Agile Principles:
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Agile teams are able to leverage change so that it is not disruptive; in fact, it is welcomed by the team and incorporated into the regular work routine. Agile teams also expect that they are able to incorporate what they are learning and leverage that to change. (Note that responding to change was the #1 benefit cited by organizations that moved to Agile in the Annual State of Agile Report.)
For all but the smallest of efforts, it is impossible to state with accuracy the requirements up front. It may actually be counter-productive to specify them in detail, based on the previous point about change and learning that occurs during execution. Our methods need to flex, to recognize this fact.
And if the requirements cannot be known well in advance, we should not spend a lot of time on developing detailed budgets and schedules to complete those requirements. Let’s stop pretending we can accurately schedule things that are unknown and unpredictable.
The project manager has been thought of as the ‘single throat to choke‘, or ‘the first one to take a bullet when the team fails’. The reality is that it takes an entire team (oh my, I almost said “it takes a village”).
The team, not the PM, can either deliver a successful project or not. To that end, we need mechanisms to shift the accountability and commitment to the team members.
It is more efficient for the team to figure out what needs to be done, and execute it, than for a project manager to tell the team what to do. It is also more humane, and more satisfying for the team members. A key Agile principle is that the best solutions come from self-organizing teams.
One of the 12 Agile Principles is about simplicity and maximizing work not done. Agile provides a framework that helps make unnecessary work visible, allowing teams to make decisions about reducing or eliminating it.
Continuous and close engagement with the customer, eliminating multi-tasking or context switching and reducing documentation deliverables are just a few examples of steps that can be taken to reduce unnecessary work.
I hope you find these 12 aspects of Agile projects helpful. What are your thoughts – do you agree? Are there more you would add? I welcome your comments below!
Also check out this related post, 10 Questions that PMOs should ask their Agile Teams.
For those of you wanting to learn more about Agile, I recommend that you review our Agile Training Courses. Some of our most popular courses are listed below: