Business Sprinters Win Tools and Resources
...solve thorny business challenges in the time it takes to drink a cup of tea
Here's how to quickly and successfully tackle the biggest challenges and opportunities facing your business...
©Shutterstock/AI
When it comes to your business, how many times have you started a new project, faced a challenge or wanted to make a change, and you and your team have started eagerly, only to get bogged down in the work, making slow (or no) progress?
How many times have you wanted to implement a change or take advantage of an opportunity, and your team has been reluctant or there has been a general lack of enthusiasm?
You might think that your people are the issue – that they want to stay how they are, preferring the status quo, and that they aren’t engaged in the new idea or change – but the likelihood is that you have historically tried and failed to run projects or make changes in your business and they are fatigued with the lack of success or with the time it takes to implement these projects.
The real issue is your process and system… how often have you looked at them and asked yourself this one question:
How do I create a management system that allows me and my team to react to the opportunities and challenges facing my business?
STOP thinking your people are to blame for lack of performance and progress in your firm.
START to focus on an agile system that will help your small, cross-functional teams work faster.
The one ‘BREAKTHROUGH QUESTION’ you must ask to help yourself…
How do I create a management system that allows me and my team to react to the opportunities and challenges facing my business?
Creating an agile management system will enable you and your team to react quickly, dynamically and efficiently to any opportunities or challenges facing your business. It will also mean that your team will be accustomed to being flexible and adaptable to change as a constant method of working and business improvement.
This way of working was implemented at Toyota and is called ‘continuous improvement’. It has been replicated worldwide and is largely regarded as the highest standard when it comes to business management systems.
But how do you adopt an agile management system and ensure you and your team use it actively to drive all of your business decisions and actions?
How do you get your team on board with this? If they have not been used to this way of working, it’s a significant shift for them.
All good systems are based on a framework, and at the end of these tools you will be familiar with the terms Scrum and Sprint and how you and your team can learn from the likes of the FBI, Toyota, Google and Amazon to implement a management system that means you can react to any changes your business faces. But first, let's start with what NOT to do.
Why Gantt charts and the waterfall system result in failed projects
“The waterfall model is badly suited to the kind of highly iterative, creative process that software development inherently is.”— Steve McConnell, Rapid Development: Taming Wild Software Schedules
Since the First World War trench construction, Gantt charts (a waterfall approach to planning and reporting) have been used by many organisations for managing projects or planning change.
The waterfall management system is a traditional, linear project management approach that follows a structured and sequential process. In this method, tasks are completed in distinct phases and each phase must be fully finished before the next begins. It's called "waterfall" because progress flows steadily downward, like a waterfall, through several pre-determined stages.
These projects tend to have a rigid structure, comprehensive and time-consuming planning, are inflexible and lack adaptability during the process. Testing and analysis come right at the end, which means that any issues that occur during the process are unlikely to be spotted until the end of the project, often resulting in costly readjustment and work having to be undone and redone.
Despite all of this, Gantt charts and waterfall management systems are still in use today.
Here is a typical example of the waterfall model - Shutterstock/asteldesign 416241931
Many large businesses have used the waterfall management system in the past, particularly in sectors where predictability, regulatory compliance and thorough documentation are needed. However, in some cases, the rigid structure of the waterfall system has led to challenges, especially in fast-moving industries where adaptability is essential.
Here are 2 examples of big businesses that have used waterfall to their detriment:
Nokia
Nokia used the waterfall management system for its product development processes, which involved highly structured and sequential design and manufacturing procedures. Nokia believed this method was perfect for controlling complex projects and ensuring that each phase was completed fully before moving on to the next.
The rigid nature of this system slowed Nokia’s ability to adapt to the rapidly evolving smartphone market. By the time they finished developing products, consumer preferences and technology had advanced. Nokia struggled to adjust to innovations like the iPhone, resulting in a significant loss of market share.
Kodak
Kodak, once a market leader in photography, used a traditional waterfall approach for its product development. They focused on the manufacturing of physical film and cameras, as their development cycles followed a strict, sequential process.
With digital photography and camera technology evolving rapidly, Kodak’s determination to stick to this rigid process didn’t allow for quick change and adaptiveness. They were slow to embrace digital photography, and by the time they caught up, the market had already progressed. Their inability to adapt quickly resulted in the downfall of their core business.
World-leading research firms – Gartner, Forrester Research and Standish Group – now say that, for the following reasons, the waterfall management system is obsolete:
- Inability to adapt
- Structure is too rigid
- Testing and feedback only happen at the end of the project
- Issues are discovered too late
- Expensive to fix any issues
- Long project life cycles
- Numerous delays and overspending – think HS2
- Competition or business sector has moved on during your project
- You get left behind
What does an agile management system look like?
“What’s dangerous is not to evolve. Companies that don’t embrace agile decision-making and adaptability will be left behind.”— Jeff Bezos, founder of Amazon
Image from @Shutterstock:725631544
An agile management system is a flexible, iterative approach to managing projects and teams, designed to enable you to adapt quickly to opportunities, challenges and changes and to deliver continuous value to your business, unlike the rigid, linear structure of the waterfall system.
One of its core principles is collaboration, where cross-functional teams work in short cycles, often called sprints (more about them later), to produce small, incremental improvements.
Agile management focuses on regular feedback from customers and stakeholders, allowing teams to quickly adjust priorities and solutions based on evolving needs.
Other key elements include transparent communication, prioritising tasks based on value and fostering a culture of continuous improvement and psychological safety.
This system is particularly effective in dynamic environments where rapid adaptation and customer-centric development are crucial, but it can be applied to all businesses in some form – even yours.
The founder of this 1995 approach, Dr Jeff Sutherland, has dubbed this a framework, not a methodology.
He believes that there are four core principles of an agile management system; they come from the Agile Manifesto (written by Sutherland and sixteen other leaders in software development), and they guide the mindset and approach of agile project management. These principles emphasise flexibility, collaboration and delivering value:
1. People and interactions over processes and tools
An agile management system places real value on your people, your team and how they collaborate, which is more important than strict adherence to formal processes or reliance on tools. Communication and teamwork drive a project's success in your business.
2. Working products over comprehensive documentation
Delivering functional and usable products needs to be prioritised over creating extensive documentation. While documentation is still vital, an agile management system focuses on delivering something that works and adds value to you, your team and your business.
3. Customer collaboration over contract negotiation
An agile management system emphasises ongoing collaboration with your customers and stakeholders throughout the project to ensure that the product meets their needs, rather than sticking strictly to pre-determined contracts or specifications.
4. Responding to change over following a plan
An agile management system is flexible and embraces change, taking into account that your requirements or your customers’ requirements may evolve or that you may be affected by outside forces that were not evident at the start of the project or that there may be global or economic changes or software developments. Rather than sticking rigidly to a pre-defined plan, an agile management system enables your team to adapt to new information and to shift priorities to continuously deliver the best possible outcome.
Sutherland calles this framework 'Scrum'.
image from quino-al-ce79TRf3Fyw-unsplash
The Scrum framework takes its name from rugby football, where “scrum” refers to a formation in which players work closely together to gain possession of the ball. In rugby, the team must collaborate intensely and move as a unit to advance, relying on collective effort, strength and strategy.
Similarly, in an agile management system, the Scrum framework emphasises teamwork, collaboration and moving forward together as a cohesive unit. Just as in rugby, Scrum in project management involves a self-organising, cross-functional team working in short, focused bursts (called Sprints) to achieve a common goal. The idea behind the name reflects this intense collaboration, adaptability and collective problem-solving – these are essential elements of Scrum.
Here is a 70-second video that explains the difference between waterfall and agile – from the Agile Shop.
Scrum and Shu Ha Ri (adapted from Jeff Sutherland’s book, SCRUM, The Art of Doing Twice the Work in Half the Time)
“In Shu, you repeat the forms and discipline yourself so that your body absorbs the way of doing things. In Ha, you begin to branch out. In Ri, you discard the forms and your knowledge becomes second nature.” — Martin Fowler, software developer and thought leader
Scrum has its roots in Japanese thought and practice. When Jeff Sutherland first visited Japan, he met Professor Ikujiro Nonaka, who made it clear that, in Japan, ‘Scrum’ isn’t seen simply as the latest work trend – it’s a way of doing, a way of being and a way of life.
Scrum is something you can only learn by doing. Sutherland discovered that in Japanese martial arts, you learn a concept called Shu Ha Ri. The term breaks down into 3 stages:
1. Shu - Follow the Rules
In the Shu stage, a learner or Scrum practitioner follows the rules, practices, and principles of Scrum rigidly. The focus is on mastering the basics by adhering strictly to Scrum ceremonies, roles and processes, without deviation.
2. Ha - Break the Rules
In the Ha stage, the learner begins to understand the principles behind the rules and can adapt and tweak them as necessary. This stage is about breaking away from rigid adherence to rules and experimenting with new techniques or approaches based on the context of the project.
3. Ri - Transcend the Rules
In the Ri stage, the practitioner fully understands the essence and purpose of Scrum and can innovate or create their processes while staying true to agile management system principles. At this point, the learner no longer needs to rely on formal rules because they understand the mindset and values behind them.
Shu Ha Ri provides a framework for learning and evolving within Scrum. Initially, teams follow Scrum by the book (Shu). Then as they mature, they adapt it (Ha), eventually transcending the framework to create a uniquely effective way of working (Ri), all while maintaining the core principles.
So how do you put this to work in your business?
How do you implement an agile management system using the Scrum Framework and the 3 distinct Shu Ha Ri stages?
How to put the Scrum framework to work in your business
"Scrum is not a methodology. Scrum is a framework for building complex products. It doesn’t tell you what to do when, but rather provides a structure and encourages you to fill in the gaps based on your team’s context and needs." — Ken Schwaber, co-creator of the Scrum framework
Here is the Scrum framework and how to make it work in your business. To succeed, you start with Shu.
People/Roles in Scrum
Product Owner: This is the person with the vision of what you are going to do, representing your stakeholders and customers and responsible for defining and prioritising the Product Backlog. They also ensure that your team is working on the right elements of the project and constantly delivering value.
Scrum Team: pick a small team of 3-7 members (+/- 2 or 3) with a wide range of skills within your business. They are responsible for delivering increments of the product/project, and they need to be able to work independently and collaboratively. This is critical when it comes to the Sprints and the Sprint goals.
Scrum Master: This person will act as a coach and mentor to the Team to ensure the agile management system principles are being followed. They will also endeavour to remove any barriers that slow the team down.
Your approach
Product Backlog: This is normally created by the Product Owner and is a dynamic list, in priority order, of everything that needs to be done to deliver the outcome. This can include software implementation, recruitment, bug fixes and technical tasks. This list is managed by the Product Owner throughout the life of the project. Items in the Product Backlog are estimated in terms of effort or complexity.
Refine and Estimate: The Team will estimate how much effort is needed on each element using relative terms, e.g., the Fibonacci sequence or another grading system, but not time. See more on the grading systems below.
Scrum Board: One key element of the Scrum framework is the visibility of the Product Backlog to all the members of the Team; this enables them to manage and update the Product Backlog throughout the Sprint. A perfect example of this is to have sticky notes that you can move across your Scrum Board columns of the same name (see the image below):
Image from @Shutterstock/AndreyPopov 1612695718
To move the sticky note to ‘Done’, it must meet your team's definition of completion, ensuring that it is usable and potentially shippable.
Events in Scrum
Sprint: A fixed period (usually 1 to 4 weeks) during which your team will work to complete a defined set of Backlog items. Sprints are consistent in length throughout the project to establish a rhythm.
Sprint Planning: Your team discusses the Sprint goal and everyone agrees to it, selects items from the Product Backlog and creates a plan for how to deliver them. Each of your Sprints must result in a completed, working, ready-to-use element of your whole project.
Daily Scrum (Standup): This is the heartbeat of a fast-acting, agile, team approach to making the most of your opportunities or to effectively deal with any challenges. A short (15-minute max) meeting is held daily where the team members share updates on their work.
This meeting should be agenda-driven, using the Scrum Board, and asking 3 questions:
- What did you do yesterday to help the team finish the Sprint?
- What will you do today to help the team finish the Sprint?
- What impediments are blocking you or the team from achieving the next Sprint goal?
These 3 simple questions help keep your team aligned and identify issues early.
Sprint Review: this meeting allows the team to demonstrate the completed work to stakeholders and gather feedback at the end of the Sprint.
Sprint Retrospective: This is a meeting held after the Sprint review where the Team reflects on the past Sprint. The Team discusses what went well and what could be improved, which then creates actionable items to enhance their processes moving forward.
Then you immediately start the next Sprint.
Fibonacci, Dogs and Education (adapted from Jeff Sutherland’s book, SCRUM, The Art of Doing Twice the Work in Half the Time)
“Nature is written in mathematical language, and the letters are triangles, circles and other geometrical figures, without which it is humanly impossible to comprehend a single word.” – Leonardo Fibonacci, mathematician
There are some great stories in the book that can help you use the Scrum agile management system in your business.
The Fibonacci Sequence
The Fibonacci code is often used in agile management systems and can be used in the Scrum system for estimating effort or complexity when planning tasks. This method employs the Fibonacci sequence as a scale to assign relative values to different tasks and it will enable your team to assess the complexity or effort required more effectively than using standard numeric values.
The Fibonacci sequence is a series of numbers where each number is the sum of the two preceding ones, usually starting with 0 and 1. The sequence looks like this:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, ...
In the Scrum framework, teams use the Fibonacci sequence for a few key reasons:
Relative Estimation: Instead of estimating tasks in absolute terms (like hours), teams estimate them relative to one another. This relative sizing helps to account for uncertainty, as it can be challenging to predict exact durations, especially for complex tasks.
Handling Complexity: The non-linear progression of the Fibonacci numbers reflects the increasing uncertainty and complexity as tasks become larger. For example, estimating a task at 5 indicates more confidence than estimating one at 21, as larger numbers signify a higher level of uncertainty.
Encouraging Discussion: Using Fibonacci numbers can stimulate discussion among team members about why a particular task is estimated to be a certain size, leading to a better understanding of the work involved and fostering collaboration.
Let’s say a team is estimating three tasks to be completed:
Task 1 – Simple task (estimated at 2 points)
Task 2 – Moderately complex task (estimated at 5 points)
Task 3 – Very complex task (estimated at 13 points)
It is obvious to the team that Task 1 is straightforward and requires minimal effort. Task 2 is more complex, involving more components and dependencies, hence the higher estimate. And Task 3 is significantly more complex, with many unknowns, justifying the much larger estimate.
Using the Fibonacci sequence for estimation helps teams communicate effectively about complexity, encouraging discussion and allowing for a clearer understanding of the work required. By adopting this relative estimation method, teams can better manage workloads and make informed decisions about Sprint planning and project execution.
Dogs – Size Does Matter Story
Image from @shutterstock_2237534495
In Sutherland’s book, he describes a team that was struggling with estimating the size and complexity of tasks. To make the estimation process clearer and more relatable, they decided to use dogs as a metaphor for size.
The team assigned different breeds of dogs to represent various sizes of tasks based on their complexity. For example:
- Chihuahua: Represented small tasks that were quick and easy to complete (such as simple features or bug fixes).
- Beagle: Represented moderately sized tasks (for example, more involved features).
- German Shepherd: Represented larger, more complex tasks (which required significant effort and collaboration).
- Great Dane: Symbolised the largest and most complex tasks, requiring extensive time and resources.
Instead of assigning specific time estimates (hours or days) to tasks, the team began to estimate tasks in terms of the size of the dog. This method emphasised understanding the relative complexity of the tasks rather than focusing on exact durations.
Using dog breeds made the estimation process more fun and less daunting for the team. It enabled conversations about the tasks and allowed team members to express their perceptions of complexity openly and without judgment. The team discussion led to a more accurate estimation of the time and resources needed to complete tasks.
By framing tasks in terms of dog sizes, the team could better communicate what needed to be done and had a clear understanding of what was expected, which helped them plan and prioritise.
The dog analogy emphasises the importance of relative sizing in estimation. It shows how comparing tasks in terms of complexity can lead to better understanding among team members.
Using familiar and humorous analogies can make something complicated, such as estimating task duration and complexity, more engaging, which can improve team enthusiasm.
Scrum in Education
In the ‘Scrum in Education’ chapter in Jeff Sutherland's book, Scrum: The Art of Doing Twice the Work in Half the Time, the story of Willy Wijnands is a compelling example of how Scrum principles can be applied in an educational context to improve learning and collaboration.
Willy Wijnands is a high school teacher in the Netherlands who faced challenges when it came to engaging his students and getting them to work together.
Traditional teaching methods resulted in students feeling disconnected and uninterested in learning.
Inspired by the agile management system framework, Willy implemented the Scrum framework in his classroom. He aimed to create a more dynamic and engaging learning environment.
He restructured his lessons to include Scrum practices, encouraging students to take ownership of their learning.
Willy assigned roles within student teams, such as Product Owner, Scrum Master and Development Team members. This helped students understand their responsibilities and the importance of working together.
The classroom was organised into short Sprints, where students worked on projects over a specified period (usually two weeks).
Students held Daily Standup meetings to discuss their progress, share challenges and plan their work for the day. This practice fostered accountability and encouraged open communication.
The students learnt to share their feelings and work out problems together.
At the end of each Sprint, students participated in retrospectives and reflected on what went well, what didn’t and how they could improve in the next Sprint.
This continuous feedback loop allowed students to adapt their strategies and learn from their experiences, reinforcing a growth mindset.
The implementation of Scrum led to remarkable changes in classroom dynamics. Students became more motivated and engaged, using their initiative and taking responsibility for their learning.
The structured roles and Daily Standups improved the teamwork and communication of the students, and the feedback and reflection meant that they were working to continuously improve what they were doing.
Willy Wijnands’ story demonstrates the powerful impact of applying Scrum principles in education. By fostering collaboration, accountability and continuous improvement, Willy created a more engaging and effective learning environment for his students. This example highlights how agile management system frameworks can transcend traditional boundaries, enhancing, not just project management, but educational practices as well.
The book and other resources
Scrum: The Art of Doing Twice the Work in Half the Time.
Jeff Sutherland and JJ Sutherland
Scrum is the revolutionary approach to project management and team building that is transforming the way businesses operate. Scrum is based on the way people really work, rather than how they think they work. It reduces team sizes, breaks down projects into short-term goals and allows constant assessment with an adaptive approach to problem solving.
Scrum improves speed and quality immediately.
What people are saying about this book:
‘This book contains immense practical value that could be transformative for your company.’ – Stephen Lundin, New York Times bestselling author of Fish!
‘Full of engaging stories and real-world examples . . . On a mission to put this tool into the hands of the broader business world for the first time, Jeff Sutherland succeeds brilliantly.’ – Eric Ries, New York Times bestselling author of The Lean Startup
‘If there was a Nobel Prize for management, and if there was any justice in the world, I believe that the prize would be awarded . . . to the invention of Scrum.’
– Forbes
‘Scrum is mandatory reading for any leader, whether they're leading troops on the battlefield or in the marketplace. The challenges of today's world don't permit the luxury of slow, inefficient work. Success requires tremendous speed, enormous productivity, and an unwavering commitment to achieving results. In other words, success requires Scrum.’ – U.S. General Barry McCaffrey
'Jeff Sutherland is the master of creating high-performing teams. The subtitle of this book understates Scrum's impact. If you don't get three times the results in one-third the time, you aren't doing it right!' – Scott Maxwell, Founder & Senior Managing Director, OpenView Venture Partners
Watch this 15-minute TEDX talk from Jeff Sutherland as he explains how to be agile, not just in software development, but in every business.
A former US Air Force ‘Top Gun’, Jeff Sutherland is the co-creator of the Scrum process. This methodology, developed in 1993 and formalized in 1995 with Ken Schwaber, has since been adopted by the vast majority of software development companies around the world.
Jeff is a leading expert on how the framework has evolved to meet the needs of today's businesses. Realising its benefits are not limited to software development, he has adapted this strategy to several other industries, including finance, healthcare and telecommunications. His processes are now widely used for managing challenging projects and hyper-productive development teams.
As the CEO of Scrum Inc. and the Senior Advisor and Agile Coach to OpenView Venture Partners, Jeff shares best practices with organisations around the globe.
Here is a shorter video where Jeff Sutherland breaks down the structure of the Scrum process and framework and how it came to be – just 5 minutes and well worth a watch.
YOUR SUPPORT TOOLS ARE HERE:
Click the button below and you'll be able to download a pdf version of this page.