In the first installment of this Introduction to Agile Project Management series, I wrote about Setting the Scene: why we need to be Agile, Feasibility, Vision, Justification, and Initiation of Agile Projects. In part two of the series, I wrote about The Team, the Project Brief, the Culture and Ways of Working, and Backlogs of an Agile Project. In part three, I wrote about Roadmaps and Story Maps, Product Iterations, Adaptive Planning, Story Creation, Sprinting, and Defining Being Done. Consider checking out those articles first before reading on in the series. In this final installment of the series, I elaborate on how to measure the success of your Agile project, how to continuously improve based on feedback, and concepts beyond Agile Project Management.
Continuous Measurement
If you can’t measure it, you can’t manage it. The same goes for improvements. The need to gather empirical data in an Agile project is almost as vital as having blood course through your veins! How do you know what needs managing, correcting, or improving if there’s no data? Well, simply put, you’ll be relying on gut feelings and unsubstantiated guess work, which falls apart pretty quickly under scrutiny. And, depending on who’s doing the scrutinizing, this can be a rather uncomfortable place to be. So, from the outset of your project, ensure you know how you are going to demonstrate progress and by what measures others are going to view your success.
Fortunately, Agile comes loaded with useful tools and techniques. The first thing to do is go back to the Agile Manifesto, type the following words into your favorite word processor, blow them up to 96pt, print, and apply to the wall for all to see:
Working software is the primary measure of progress
Your greatest demonstrable power in delivering software is to show it to people working, doing what it’s supposed to do. Not only will this make your customers happy, it will earn your team great respect and grease the wheels for greater adoption throughout the business.
Here are some other tools:
- The daily standup: There are a few variations of this ceremony, but the essence is to have all team members talk to each other face to face, keep it short, keep it focused, and keep it light. If anything needs discussion at great length, park it for a longer conversation between those needed after the standup. If impediments are raised, write them up like a story, add them to your backlog, and get them addressed ASAP. Anything that is impeding your team slows their progress and will be demonstrable in reduced velocity and software that does not meet expectations.
- Velocity: Is a historical tool. It’s a little like those financial warnings you get that say past performance is no guarantee of future performance. But in Agile’s case, we do hope to achieve a team velocity that is largely smooth. It’s velocity that allows us to project future performance and confidence in our plans. There may be influences outside of your control which might lower the number of story points output for a given sprint. If this happens, you’ll probably be able to recover. Never use velocity as a stick to beat your team with; it will win you no favors. One thing that’s for sure is that velocity will be erratic for the first 2 – 4 sprints. Somewhere in that timeframe, however, you should start to see consistency and stability. If your velocity is wavering from one extreme to another, you’ve got a problem which you’ll need to fix with your team.
- The burndown chart: This measure of progress is a thorny one. For that reason, I haven’t given a link to go find out more, you’ll have to do your own research and agree as a team and business which works best for you. The reason it’s thorny? Well, not one resource out there tells the same story! One thing agreed is that it will show how, within a sprint or a release, how you’re performing against your timebox. If maintained daily, it will show if you’re on track or deviating. Some teams use it to represent how much value is left to be created. More often than not, others use it to show how much work is left to be completed. The former is a celebration of success and value generation, the latter is less inspiring and motivating.
- The burnup chart: If you must show work completion rates, use the burndown chart for that. But using the burnup chart allows you to show how much value has been created and how much more value you’re planning to create by the end of the sprint. A much more motivating tool for a team to both demonstrate to the business what has been done, and what they still have their sights set on. In any case, use the charts to spot where progress is not tracking as expected, look for patterns or deviations, and get on top of them to fix the underlying problem as soon as possible. Update them daily for sprints and once at the end of a sprint for release version charts.
- Task boards: These are great visual radiators for demonstrating value being created. When updated daily, or at any point in the day, they immediately show progress being made. If combined with Kanban, they’re also great tools for visualizing flow and blockages in the system. If you can see that loads of development is completed, but testing is not as productive, you can see the problem happening and respond appropriately and swiftly.
Other tools to consider are Agile Earned Value, cycle time, and Cumulative Flow Diagrams (CFD’s).
Keep these measures, charts, and other tools visible, preferably loud and proud on a wall for all to see. The team, stakeholders, and other interested parties can immediately see the status of a project. It’s transparent and serves as a valuable communication tool. If you can’t put these artifacts on a wall, use tools that are sharable and collaborative and make sure those that want access have it.
Continuous Improvement
Throughout your Agile life, seek to identify and learn where improvements can be made. Lessons are not captured and learned at the end of a project. It’s like passing your driving test and tentatively taking your first drive without an instructor. You’ll know what works and what you’re supposed to do, but over time you’ll tailor your driving skill and capabilities, learning new techniques. You’ll even pick up bad habits. Look for them, understand them, and find ways to improve.
There are many opportunities for identifying what does not work and applying remedies. The built-in approach to this in Agile is the retrospective. This is the primary tool for reflection and adjustment. At the end of every sprint, take time with the team to improve how work gets done, how quality is delivered, how efficiency can be maximized, how waste can be minimized and how capacity is increased. When you identify measures for improvement, don’t be tempted to fix all your problems right away. Identify the ones that will have the most impact and can be implemented in the next sprint. Measure and observe. If it had the desired impact, lock it up, write it up into your ways of working and definitions of done. If it doesn’t work, think again. Any lessons learned that don’t get put into the upcoming sprint can be parked and prioritized for attention in the next sprint.
Tailor the process. Remove anything that does not work. Remove impediments. Your maturity as an Agile team will know no bounds if you let it.
Beyond Agile Project Management
It’s important to know what happens after the project is delivered. Support and maintenance are key to ensuring that once the project is in the customer’s hands it remains performant, that customer feedback is factored into future releases, and customer issues are dealt with appropriately. A project is a unique, time constrained endeavor. The product it delivers has a life after the project team has been disbanded. Ensure you are capable of supporting the product once it is live.
Agile projects co-exist with more traditional approaches. Balancing the requirements for budgetary control and stakeholder visibility with the Agile aims of flexibility and responsiveness.
A governance framework or Agile governance model is used in conjunction with a standard Agile processes, such as Scrum. They work in two specific ways:
- They provide a wrapper for an Agile project by clarifying the processes that occur outside of development iterations (sprints). This includes providing clear criteria for the successful completion of project initiation and proper validation of the decisions and plan.
- They shift the emphasis of specific parts of the standard Agile process and highlight particular principles and techniques that need governance or support governance.
In today’s ever-changing world, organizations and businesses are keen to adopt a more flexible approach to delivering projects, and want to become more Agile. However, for organizations delivering projects and programs, and where existing formal project management processes already exist, the informality of many of the Agile approaches is daunting and is sometimes perceived as too risky. These project-focused organizations need a mature Agile approach – agility within the concept of project delivery – Agile Project Management.
Learn and grow with your adoption of Agile. Only ever do what your team is comfortable with, ensure their voice is heard, and act on their requests. Encourage your team to adopt new and more valuable techniques when the time is right. Negotiate with the business and encourage them to understand what it means to be an Agile organization.
Enjoy the journey.
This article originally appeared on Toptal.
