Agile has changed Project Management. And not just the attitudes and processes – which have had a huge impact (both positive and negative*). If you aren’t persuaded, then I offer you the wealth of agile tools and methods that we can bring to bear on any project. Managers of predictive projects can gain a lot by adding these to our toolkits. In this article, I select my top twelve.
* I asserted above that agile attitudes and processes have had a huge negative impact on Project Management. I hope the positive impacts are evident: the Agile Manifesto and 12 principles offer a powerful set of attitudes. And the various methodologies and frameworks have enriched our options for successful delivery and new ways of working.
So, what are these negative impacts? I’m thinking here of eager project managers and, more often, ill-informed senior managers who have been keen to seize on agile methods as a silver bullet to solve problems they are not well-suited to solving. As flavor of the month, too many organizations are aiming for agile-everything. This is to the detriment of their own project delivery and damages the reputation of Agile.
And, as for attitudes… For too long, there was a cadre of agile practitioners who took a simplistic (and foolish) attitude that ‘agile good, predictive bad’. This, of course, is nonsense, but it drove polarizing arguments that have only really petered out in the last couple of years.
Organizing My Top 12 Agile Tools and Methods
I have organized my top 12 Agile Tools and Methods into six sections:
- Defining the Work
- Estimating the Level of Work
- Use while Delivering the Work
- Monitoring Progress
- Conducting a Retrospective
- Big Ideas that Agile Offers Us
Agile Tools for Defining the Work
I think Agile’s biggest contributions are in selecting and delivering work. However, delivering work (which we’ll look at below) is more driven by the core principles of incrementalism and iteration. These lead to the big process shift towards iterations, or sprints, which I shan’t consider to be tools or methods.
So, this section of defining work contains three of our 12 tools.
01: User Stories
User stories and their big siblings, epics, make up my first pick. I love the way these define what we need to do, in terms of what the users need. The articulation is clear and simple, so I think that many predictive projects can benefit from adapting this approach for their own Project Definition stage.
HM: Spikes, or Spike Stories
My first Honorable Mention goes to a very particular type of User Story, a Spike Story, or Spike. The idea of conducting an experimental min-project with a very strict scope and time-box is fabulous. It enables us to research a feature, problem, or technology with low risk. And, in so doing, we reduce the risk of the project overall.
For more on risk in Agile Projects, check out my video, How to Do Risk Management in Agile Projects.
HM: Story Map
If you want to extend the idea of user stories, to get a visualization of a whole product or process flow, then you can do a lot worse than using a Story Map. I have made a video, User Story Mapping 101, about how to create a User Story Map.
02: Backlog
Fundamental to the iterative approach of agile projects is the concept of a backlog. But this is a concept made real. A product backlog is a physical record of all the things the project might do, ready to be drawn down into a sprint or iteration backlog. This is, in turn, a record of all the things the project will do, in the next iteration.
I love its simplicity as a record of what we need to keep on our agenda. But a product backlog has the huge benefit of not committing us, until the time is right to draw stories down from it, into a sprint backlog.
HM: Backlog refinement or grooming
Alongside the tool of a backlog is the method of refining, or grooming, that backlog. It would be all too easy to let your product backlog become a dumping ground. Like the home of a hoarder, it would fill up with junk that has no use. And this would make navigating the backlog and finding what matters almost impossible.
So, we can do a periodic decluttering process, just like an agile Marie Kondo. And that is Backlog Grooming, or Backlog Refinement.
03: Road Map
I chose to give story maps an Honorable Mention, alongside User Stories. So, let me single out another way we can chart out hope to do, without building a ‘plan’. And that is a Roadmap. It can be a project roadmap or a product roadmap. The concept is one of a series of time periods, within each of which, we anticipate delivering a broad contribution to what our customers or users want or need.
Superficially, this can look like the poster child for predictive project management, the Gantt Chart. But it is not the same, as I explain in this video:
HM: Design Thinking
One method that I would love to have included in my list, had I not run out of space, is Design Thinking. However, this is more a method that agile practitioners have embraced than it is an agile method.
It’s a design process that begins with discovering what users need, so lends itself well to agile values and principles. I explain Design Thinking in this video…
Agile Tools for Estimating the Level of Work
One of the biggest challenges (and points of failure) in traditional project management is estimating. Estimating the time required, resources needed, and the budget to pay for them are all extremely hard in a project context.
This is also one of the biggest bones of contention between some parts of the Agile community and other project managers. The #NoEstimates mindset would argue that when doing something wholly new, we should fix a schedule and budget and deliver what we can. We can’t make a good estimate, and so should not try.
At the opposite extreme, is the view that clients need to know what they are committing to, and the need for estimating is both respectful to the people who must pay, and also a commercial reality.
I deprecate either/or arguments that polarize debate between two extremes. And it is a shame because Agile offers us so many great tools for making estimates in a simplified, but helpful way. These are methods that any predictive project manager can find use for. Having them in your toolkit is a no-brainer to me.
I’ll start with an Honorable Mention, before selecting my favorite.
HM: Planning Poker
Planning poker makes estimating into a fun and serious game, using Planning Poker cards that use numbers of story points, based on the Fibonacci Sequence. I have a video that explains how it works, What is Planning Poker?
04: Tee-shirt Sizing
Tee-shirt sizing is an even simpler estimating process than Planning Poker. It allows users to rate the scale of work required to deliver a User Story in terms of Tee-shirt sizes like small, medium, and large. As with other story-point-based estimations, the sizes will scale according to the Fibonacci Sequence of 1, 2, 3, 5, 8, 13…
Agile Tools to Use While Delivering the Work
Once you get into the work, there are two methods that jump out at me, that predictive project managers can incorporate into your projects. Indeed, I have been using the first of these, Morning Stand-ups’ since before I’d even heard of ‘agile project management’!
As I mentioned above, I have chosen not to include sprints, or iterations, into my list. This is mainly because I see it as a core process of most agile approaches, rather than a method or a tool. It’s also because, incorporating it into a predictive project will move that project to be a more agile-like hybrid, than a predictive project!
06: Daily stand-ups
What could be simpler (and more effective) than getting your project team together, once a day, for a short, focused meeting? If it has a clear structure that addresses only the most important things, and a fixed time in which to do it, everyone can see how it is worth their while attending and participating. What more can I add, than explaining how to hold them…
05: Kanban Board
Kanban boards had me puzzling for a while. Is this a tool I should include, or a whole methodology? Because I think it can be of great use as an add-on or work-planning tool for a predictive project, I decided to include it. And I am glad I did.
Agile Tools for Monitoring Progress
When it comes to monitoring progress, Agile has contributed one simple and effective idea that I cannot not mention…
07: Burn Charts: Burnup and Burndown Charts
Burn charts simplify progress monitoring to match the most important increments of progress in agile projects: story points. This simplicity suggests to me that we can readily adapt these to milestones, deliverables, work packages, or many other aspects of a more traditional project.
HM: Velocity
If you watched the video, above, about burndown and burnup charts, you’ll also have met the idea of velocity. Measuring velocity from a burn chart is a method that I think deserves an Honorable Mention, as an extension to the burn chart tools.
HM: Information Radiators (Big Visible Charts – BVCs)
A free-standing Honorable Mention goes to the tool that is sometimes called an Information Radiator, and sometimes (with much more plain speaking) as a Big Visible Chart (BVC).
The idea of making data highly visible to team members, so they can see where they are, is an old one. Much psychological research endorses the fact that our performance increases when we have good feedback on how we are doing. And it is motivating too. However, is an Information Radiator a new idea to Agile? No. That’s why, despite the flowery metaphorical name, it only gets an HM!
Agile Tools for Conducting a Retrospective
There are lots of ways to conduct a Retrospective. And, despite it being little different from a Lessons Learned Review, I am going to really celebrate it here. The frequency, efficiency, and attitude towards agile retrospectives is, for me, one of Agile’s greatest contributions – not just to Project Management, but to working life.
There are many formats that all deserve Honorable Mentions. In our Project Management Checklists kit, I offer six additional formats to the one I have chosen…
08: Starfish Retrospective
A Starfish retrospective facilitates a team discussion of five things (like the arms of a starfish). We ask, ‘What should we…
- do more of?
- do less of?
- start doing?
- stop doing?
- keep doing?
I made a video describing how to use this format for giving feedback, on my sister YouTube channel, Management Courses:
Big Ideas that Agile Offers Us
On top of all the goodness I have shared already, Agile has drawn together a huge wealth of ideas that add a lot of insight and capability to project management. I have picked out my four favorites, along with some more Honorable Mentions.
09: Minimum Viable Product (and its friends)
Getting something done and out there so people can use it should be what we are about. So the concept of Minimum Viable Product (MVP) is excellent. Basically, this is a prototype that works. So, you can show it to the customer and use it to help drive a decision or inform the next steps.
This is, however, just one of a family of related ideas:
Minimum Releasable Feature (MRF)
The single, smallest feature that can work as part of your MVP. It creates real value and so is sometimes called a Minimum Marketable Feature (MMF)
Minimum Business Increment (MBI)
The smallest chunk of value that you can justify waiting for. Without it, the release makes no sense.
Minimum Marketable Release (MMR)
The smallest group of business increments that you believe the end customers would be prepared to pay for. Contains one or more MBIs. Also called the Minimum Marketable Product (MMP)
10: Stacey Complexity Model
This is a simple way to understand different levels of complexity from simple to chaotic, that has been co-opted by agilists. It charts uncertainty in the end-requirements against technical uncertainty:
- Low requirements uncertainty and low technical uncertainty suggests a simple problem that is susceptible to linear, planned approaches.
- Low requirements uncertainty but high technical uncertainty or high requirements uncertainty and low technical uncertainty suggests an increasingly uncertain environment that ranges from complicated to fully complex. You will need to apply adaptive approaches.
- High requirements uncertainty and high technical uncertainty suggests a chaotic environment that has high levels of risk.
I favor this model because it is very simple. But, for deeper insight into complexity, I offer you…
HM: Cynefin
Perhaps the Cynefin Framework (pronounced kun-ev-in) should have been my top tool, with the Stacey Model getting the honorable mention. Cynefin is deep, rich, and complex. This makes it a more powerful model that offers more insight. But, its complexity means it will take more study to understand it – and to hold the model in your mind.
But, it is worth at least some study, so I do recommend you watch this short video:
11: T-shaped People and a T-shaped Team
When you are thinking of your own personal development, the idea of a T-shaped professional is hugely valuable. It reminds us that having a deep skillset is not enough. You also need a broad appreciation of many aspects of the context in which you aspire to work.
A T-shaped team likewise has breadth and depth. There is also the concept of n- and M-shaped people and teams, with multiple verticals of subjects with a real depth of knowledge. And, in one of my conference keynotes, I discuss my concept of J-shaped people.
12: Agile Manifesto and principles (of Agile, Scrum, DA, SAFe…)
MY final Top Tool or Idea is the set of concepts that underpin all of Agile:
- The Agile Manifesto
- The 12 Agile Principles
In summary, the authors of the Agile Manifesto state that:
…we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Other Agile Principles
And, let’s not forget that the Scrum Guide, the Scaled Agile Framework (SAFe), and Disciplined Agile (DA), all have their own sets of principles.
HM: Cone of Uncertainty
An Honorable Mention must go the idea of The Cone of Uncertainty, as a simple thinking model of how uncertainty (and hence, risk) evolves.
HM: Agile Triangle
And talking of risk… It is conspicuously absent from the Agile Triangle. I give it an Honorable Mention because of the regard some people hold it in. I do not think it is that useful – not least because of the absence of risk. Some, I suppose, would argue that agile manages out risk. I do not; and believe that we need active risk management in any agile project.
I have a whole article on alternatives to the traditional Triple Constraint – the Iron Triangle or Time-Cost-Quality Triangle articulations. But, if you are interested in the Agile Triangle formulation…
HM: Fist of Five
The ‘fist of five’ concept is really simple. It is a way to assess the extent of consensus around the idea, and act accordingly.
After discussing the idea, ask the team for their reaction with a fist of five. Count 3-2-1 and everyone holds up from one to five fingers. I’ll explain the ‘coding’ in a moment. Based on the response, you can either discuss further or move on.
The Fist of Five Meanings
- One finger: I hate the idea and oppose it
- Two fingers: I have concerns that we need to discuss
- Three fingers: I can agree to the idea
- Four fingers: It’s a good idea
- Five fingers: It’s a great idea. I love it!
If everyone thinks the same, then either:
- Act on the idea (this needs ALL 3, 4, or 5-finger responses)
- Reject the idea (if you have ALL or nearly all 1 or 2-finger responses)
If there is a mix, you need to hear from the people with concerns and then discuss the idea carefully. I suggest you start with what two and three-finger responders think. This can avoid polarizing the discussion too early. Focus on finding out what some people may have noticed, that others have not.
After the discussion, if you need to, repeat the ‘fist of five’ process. However, it is likely that the discussion will tell the group what the decision needs to be.
What are Your Favorite Agile Tools and Methods?
Please do share your thoughts in the comments.
Dear Dr. Mike Clayton,
Thank you very much for your useful and interesting lectures! I appreciate that very much! But that is so-called “theoretical part”. It could be great if you will be able to include in your lectures some practical examples. That will be really cool!
Thanks in advance for such a possibility and your support!
Best regards,
Vladimir
There is a limit to how long I can make my articles. This one is about giving you ideas for tools you can use. Looking for or creating practical case studies is just not something I can do for an article like this. It may be a style others take.