With the use of Agile project methodologies (SCRUM, XP,…) gaining momentum, and their advantages being widely proclaimed, many project managers and their teams are wondering whether they should embrace them, and if so, how.
Back in 2001, the writers of the Agile manifesto agreed on 12 principles, which further defines how to run an Agile project:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximising the amount of work not done — is essential.
- The best architectures, requirements, and designs emerge from self-organising teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Before going all the way through a major re-organisation and corresponding change in mindset that Agile entails, we have identified four Agile practices that can be put into place at once, and guarantee to have a positive impact on any project.
Our four principles have been chosen in order of ease of implementation rather than the degree of impact. They are all within the sphere of influence of the project manager and the team, so do not require any involvement or contribution from senior management.
- Retrospective (12).
- Define results of activities so you can measure progress (3).
- Simplify (10).
- Customer centric, (1)
All methodologies recommend documenting and incorporating “lessons learned’. For an organisation these are pure gold; building on best practices and eliminating recurrent mistakes.
Unfortunately, these often only happen during the close-out phase of the project, or rather don’t happen because the team is forced to move on to the following project, which is already running late.
Instead of waiting until the end of the whole project “lessons learned” can be captured during each weekly review. Just picking out “one thing we do well and will do again” and “one thing we will change this week to do better” can quickly lead to significant improvement.
Recording these points in the weekly project report means they can be reviewed the following week and not lost from view. Though this seems easy, even the simplest items are quickly forgotten.
Be prepared to come back to these points, maybe more than once, before they are fully integrated into daily working practice. Even though there may be many points that are working well, and just as many points to improve, pick just one of each every week to help keep focus. Note also the emphasis on the “we”; if the items identified are within the control of the project team the chances of something happening are high.
2. Define results of activities so you can measure progress
Agile Principle 3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Since not all projects are about software development we will take the liberty of rephrasing this principle as “Deliver measurable results frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
When drawing up the Work Breakdown Structure for the project, a common practice is to list the activities, cutting them into smaller pieces until they can be reliably estimated and delegated.
One major activity in building a house might be listed as “Lay foundations”. Expressing the same thing as “Foundations laid according to specs.” means the result of the activity is used to measure completion, rather than the hours spent on the activity itself.
At first sight this might appear to be nothing more than an exercise in semantics. However, the focus has now changed from “doing things” to “achieving results”. Being able to show the customer results that demonstrate progress towards the overall end goal is reassuring. True, this is not a demonstration of “working software”, but nonetheless it is a clear and measurable step towards the project’s end goal.
Measuring progress with the results of the activities also helps to improve the “definition of done”. This will most likely lead to a fruitful discussion before the work actually begins. Reviewing results is also more satisfactory for the customer, and is likely to lead to more constructive feedback than looking at the progress (or not) of a line on a bar chart.
You can also use Agile to become agile: for each review it is possible to improve how accurately you can forecast the results expected for the following review, and how precisely you can describe them.
If you can take a step back it is possible to identify many ways of simplifying the project, both what is being done and how it is being done.
For this article we will take one example. No matter how large or complex the project it is essential to provide an overview of the whole thing in 30 seconds or less, ideally using some form of graphic illustration. The overview must be understandable to a reasonably intelligent person who has an adequate grasp of the language being used, not just reserved for the experts. This might sound like an insult to those who have been working for years on, for example, building an experimental thermonuclear reactor**, yet the benefits of creating this anchor cannot be over-estimated because that all the other elements of the project can link to it.
Producing the overview can be a challenge, so it is valuable to have a friendly person, neutral to the project, who can extract the bare bones thanks to not knowing too much of the detail. A reliable test of the effectiveness of the overview is that any member of the project team can present it. An even better test is if the Customer of the project can present it. If you calculate the number of times the project will need to be presented to newcomers then cutting the overview down from 30 minutes to 30 seconds represents a considerable time-saving and a real-life application of maximising the amount of work not done.
4. Customer centric
Agile Principle 1. The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
However, if you are not actually working on a software project then it is perfectly legitimate, as we did for point 2, to substitute “results” instead of “software”. In either case it’s important to know what the customer ranks as “valuable”. You might think that this should have been number one on this list as well, so let’s see how the previous three points in this article contribute to building, maintaining, or, if necessary, rebuilding customer confidence.
Many Customers and Sponsors are overseeing multiple projects, as well as their other activities; their attention is in high demand. A concise 30-second description of the project (Point 3) brings their focus back onto it rapidly.
Next, by showing the Customer or Sponsor some concrete, measurable results (Point 2) the Project Manager can distinguish herself and the team from many of the other projects the Customer is handling. All too often the project manager only talks about issues. Of course, it would be naïve to assume that these do not exist, but if this is the main topic on the agenda then it hardly builds any confidence. Problems and problem solving become so preponderant in the project that, focus on the Customer and value are lost. Talking about results and progress can make a refreshing change.
Thirdly, let the Customer know that the team has already implemented some improvements (Point 1) and what the impact has been. This demonstration of autonomy is likely to build trust and creates an opening to engage the Customer in the cycle of becoming more Agile.
Conclusion. Fully implementing the twelve principles given in the Agile Manifesto is a lengthy journey. It required commitment and dedication at all levels of the organisation: it is not going to happen overnight. However, this article does show what can be done to apply Agile principles, and how this can be beneficial, first and foremost for the project manager and the project team members.
** The website for the abovementioned experimental thermonuclear reactor is an excellent example of simplification: https://www.iter.org/mach.