Agile originated in the world of software development, but over the years people have recognised the principles are also valuable in many other contexts. I use agile ways of working to help plan, reflect, and build momentum.
The Agile Manifesto was published in 2001 as a response to challenges people developing software were facing in the 1990s – and still often face today. Some of the key issues were caused by the planning and documentation requirements of traditional methods like Waterfall.
When I say manifesto, you might picture a big methodology textbook, but the Agile Manifesto is actually a concise statement of four values and 12 principles, which only takes a couple of minutes to read. These values and principles apply perfectly to any workflow.
If you read the manifesto you’ll notice it’s not a methodology with process, rituals, and tools.
It’s really this simple… “Through this work 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”.
Over the years, frameworks have emerged layered on top of Agile principles – though sometimes dogmatically with rigid rules, ironically ignoring the very first principle of Agile: people over process. That’s not how we’ll approach it though.
How We’ll Use It
Agile is a way of thinking and working that prioritises people – how they interact and collaborate – over process and tools.
It’s about responding to change and iterating, rather than holding yourself hostage to a static plan. It’s about delivering value to the people who use your solution – early and often and refining your solution based on what you learn from them – not waiting until you think you have the perfect solution before getting it out into the world.
These principles are core to the approach I take and recommend. I use some practices that are common to agile ways of working to help bring the principles to life. They work best when they become a positive habit, and a natural part of your workflow.
Sprints
A sprint in agile is simply a short repeating cycle that breaks projects or your workload into manageable pieces. They’re usually the same length of time – two weeks is probably the most common – but applying people over process, you might find three or four weeks works better for you, or even one week.
It will probably take some experimenting to get into your sustainable rhythm.
Over the years, I’ve found two-week sprints work best in most contexts – and I use this rhythm across all aspects of my life. It’s a timeframe where I usually know the main things that will need my time and energy and how much capacity I’ll have – same as the people I’m working with.
Within these known constraints, we can set realistic goals for the sprint, and plan the work for it with a high degree of confidence. I also find it’s a good timeframe for a rhythm of planning, doing and delivering the work, and reflecting on how things went.
I frequently use a sprint zero as a time to set the scene, mobilise, and plan the first real sprint. In certain circles the concept of sprint zero is a contentious one, but… people over process.
Part of the sprint rhythm is a session to finish the current sprint and get ready for the next one. The sequence of these sessions is normally a showcase to demonstrate what has been produced, a retro to reflect on how things are going, and then planning for the next sprint to have a clear plan to execute.
Showcase
The purpose of a showcase (also known as a sprint demo or review) is to demonstrate the work you’ve done at the end of the sprint.
A key word here is “done”. Being clear on what you plan to demo at the next showcase during your sprint planning will help you keep focused rather than leaving things open-ended.
The challenge here is to share a coherent story by the end of each sprint. This is about showing the product of your work – not a walkthrough of your task list. What a good showcase looks like will iterate as you progress.
You might not do a showcase every sprint but it’s worth doing one at major milestones. At certain points you might want to present significant findings and insights to stakeholders and customers as your showcase.
Treat showcases as a great opportunity to get feedback and fresh perspectives. This is an area where having a coach can be really valuable.
Retros
The purpose of a retrospective (retro for short) is to reflect on how things went over the past sprint and build a practice of continual improvement.
When doing this as a team, I recommend some personal reflection first. Integrate this as part of your action learning…
Have a think about your mindset:
- When and how did you practice a growth mindset?
- When did you observe a fixed mindset in yourself?
- What were the triggers?
- What behaviours manifested?
- How did you move out of that state?
- What did you do well?
- What didn’t you do so well (and why)?
- What did you learn?
- What will you personally do better or differently during the next sprint?
A team retro commonly focuses on these three key questions, and is something you discuss as a group:
- What’s working well?
- What’s not working so well?
- What did we learn, and what improvements will you implement for the next sprint, and how?
Some keys to a good retro are communicating openly and honestly, and keeping the focus on how to improve, rather than assigning blame.
The improvements you identify – and agree to prioritise – are then included in sprint planning, with how you’ll implement them.
Sprint Planning
Some people will do no planning and call it agile, but agile is very much about planning – just in shorter cycles with iteration and learning embedded in the way of working.
Sprint planning is focused on the sprint you’re about to start. This is the short-term getting it done planning, but it also needs be in the context of the bigger piece of work or roadmap that you’re working towards.
As part of the roadmap, it’s generally good practice to give each sprint a theme or a focus.
In Solve Problems That Matter, each sprint has a theme based on where we’re at in the double diamond, and what our focus is. I mapped the sprints against the double diamond with the parts and chapters of the book.
You’ll need a more detailed level of planning specific to your situation to turn this into a plan to make it happen. This includes being explicit about the capacity you have for the sprint, the specific work to be done, how you’ll know when it’s done, and some rough estimates on how much work each activity is.
If you’re just starting out with a sprint rhythm, one of the first things to do is choose the day of the week your sprint will finish – the next sprint will start on the following day.
Every two weeks, you’ll have a session on the last day of the sprint to showcase what you’ve just done, reflect, and plan for the next two weeks. This will probably take one to two hours, and it’s best to keep a regular rhythm rather than changing days.
Limit work in progress
A principle from Kanban, a popular agile framework, that I think is really useful in our context to help with focus, is to limit work in progress.
Rather than working on 50 things simultaneously, all partly done, try experimenting with working on just a few things at once, with a way of knowing when they’re done – at least for now. When you reach that point, mark it as done (it feels good!) and add additional things you might improve in the future to your backlog.
I recommend using a Kanban board. You can do this on a wall with sticky notes, or Trello, Asana, and Clickup are some great tools for this, and have free plans. You can use the simple three-column setup to get started: “To Do”, “Doing”, and “Done”.
It takes practice and experimentation. But remember, learning and refining your planning is a natural part of this approach. It’s definitely a case of learning through doing. This is another area where coaching can really help.
By the end of the sprint planning session, everyone involved needs to be clear – and for it to be captured – on what you plan to do, by when, and how progress will be tracked and communicated – internally as a team, and with other key stakeholders. Or even just for yourself.
I’m a fan of John Stepper’s Working Out Loud principles – including “visible work”, which I try to practice.
There are a lot of other terms related to sprint planning, like epics, user stories, backlog, backlog grooming, sizing or estimation, velocity, and many more. I’m sharing just enough core concepts here to get started and build your sprint rhythm.
Your Sprint Rhythm
While we use the term “sprint”, don’t take this to literally mean that you’re always running as fast as you possibly can.
Think of it as two-week cycles of sustained focus. At the end of each cycle, you pause, take a breath, reflect on how it went, and plan for the next cycle.
There are different ways to do this, but I find it normally works best to have a single Sprint Review & Plan session to do a showcase, retro, and sprint planning. I strongly encourage you to consistently do this at the end of each sprint.
Take Action: Your Showcase
The purpose of a showcase is to demonstrate the work you’ve done at the end of the sprint.
Note: You’ll probably do the showcase as a separate session when you include other stakeholders or customers. I still recommend including the showcase as part of your regular session as a good practice run.
Start the meeting by having everyone share their best piece of news – this might be work-related or personal. Sharing and celebrating these wins starts the meeting on a positive note, and helps set the right tone and energy for the session.
Show the product of your work from the sprint. Showing is a lot more compelling than telling. The aim is to share this as a coherent story. This is also a good opportunity to practice and refine your story.
Take Action: Your Retro
The purpose of the retro is to reflect on how things went over the past sprint and build a practice of continual improvement. When doing this as a team, I recommend doing some personal reflection first.
Three key questions to reflect on and discuss:
- What’s working well?
- What’s not working so well?
- What did we learn, and what improvements will we implement for the next sprint, and how?
The retro is also an important part of the reflect and conclude steps in your action learning loop. This is a good opportunity to review your key insights and assumptions.
Take Action: Your Sprint Planning
The purpose of sprint planning is to have a more detailed plan for the sprint you’re about to start. Be realistic about the capacity you have, and prioritise the work to be done.
You’ll also need to define when each piece of work is done, and have some rough estimates of how much work each activity is.
What’s the focus of the sprint?
What are the sprint start and end dates?
What completed work will you showcase at the next Sprint Review & Plan session?
What work do you need to do to make that happen?
I recommend using a Kanban board to plan and track your sprint planning. At the top of the “To Do” column of your board, create cards for each of the pieces of work you’ve identified you’ll do in the sprint. This gives you a clear view of the work to be done.
How will you know when the work outlined on each of the cards is done?
What’s your estimate to complete the work outlined on each of the cards?
How does the estimated work fit with your capacity for the sprint?
By the end of the sprint planning session, everyone involved needs to be clear on what you plan to do, by when, and how progress will be tracked and communicated – internally as a team and with other key stakeholders, or even just for yourself if you’re working solo.
The plan needs to be captured and actionable, preferably on your Kanban board.
Take Action: Your Sprint Workflow
When you start work on a card, move it from the “To Do” column to “Doing”. Most of the time, it’s best to only have one or two cards that you’re actively working on in the “Doing” list.
When you’ve completed the work on the card, move it from “Doing” to “Done”. It’s very satisfying seeing the number of cards in the “Done” column increase, and it helps you keep track of how much you’ve progressed.
Solve Problems That Matter
This is an excerpt from my book Solve Problems That Matter, where I go into a lot more detail on all of the things I’ve covered in this post… and plenty more.
It’s a playbook with actions and worksheets to help you take a human-centred design and living systems approach to design, build, and launch your idea. Ideas that customers love, make money, and do great things for people and our planet… all while increasing wellbeing.
Let’s Collaborate
We specialise in coaching, training, and working alongside leaders.
A key way we do this is by designing and delivering action learning experiences with masterclasses, workshops, innovation sprints, and leadership, design thinking & innovation programs.
These sessions build personal, team, and organisational capability to solve problems that matter with more:
- 🌿 Confidence to navigate complexity and solve problems that matter for your teams, customers, shareholders – and build momentum with more certainty and less risk while increasing your wellbeing
- ❤️ Clarity to empathically engage your stakeholders, make better decisions, and collaborate to create solutions that your teams and customers love, make money, and do great things for people and our planet
- 🎯 Purpose that drives progress on your goals and creates meaningful value that you’re proud of for all stakeholders – and build the relationships, workflows, rhythms, and habits for success
Ready to have fun collaborating to solve problems that matter?
