In the final part of my introduction to Scrum, I look at the mind-set and values that are central to making Scrum work.
‘What?’ not ‘How?’
The Scrum Guide specifies the necessary elements of the framework but does not dictate how they should be implemented. This is left up to the Scrum Team to decide for themselves and the implementation often emerges and evolves through the cycles of continuous improvement.
For example, the Scrum Guide talks about the PO role and his or her responsibility for maintaining the Product Backlog. The guide does not, however, stipulate what method or criteria the PO should use to generate and order the backlog or how and where the list should be represented and stored. (Should you use an online system or paper? It doesn’t matter.) This allows for flexibility so that local and organisational context can be taken into account in the implementation.
This flexibility is one of the reasons that makes Scrum so powerful but the simplicity and lack of specific implementation directives makes it challenging to master and is perhaps one reason why there are many examples of Scrum implementations failing.
The ingredient that is so often missed is one of mind-set. It is not sufficient to implement Scrum as a series of tick-box exercises. It takes time and perseverance for a team and an organisation to discover how best to implement Scrum in their specific circumstances.
The Guide addresses this mind-set through 5 values that it identifies as critical to its success. Promoting, encouraging and embeding these within a team can help to ensure the appropriate mind-set is adopted.
Commitment – each team member personally commits to achieving the goals of each sprint
Courage – each team member has the courage to do what is needed and to tackle tough problems
Focus – everyone in the team focuses on the work and goals of the sprint
Openness – everyone agrees to by open about their work and any challenges that they face
Respect – the team members respect one another as “capable, independent people”
To underline their significance, it is worth quoting directly from the guide:
“When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.” https://www.scrumguides.org/scrum-guide.html#values
In many ways, the 5 values are the most important elements of Scrum. Without them, the framework is unlikely to succeed. With them, it can become a powerful force that has the potential to revolutionise the way goals and desired outcomes are achieved.
A look at agile values: https://www.linkedin.com/pulse/values-agiles-toughest-challenge-andy-bleach/ scrum.org: https://www.scrum.org/ Scrum Guide: https://www.scrumguides.org/scrum-guide.html
In this second post of three looking at the basics of Scrum, I introduce the core elements as described in the official Scrum Guide.
The Scrum Guide: The Key Elements of Scrum
The Scrum framework is described fully and eloquently in a relatively short document called the Scrum Guide. It outlines a number of elements:
Transparency – information is shared openly using a common language
Inspection – the scrum team frequently inspect their progress to identify areas for improvement
Adaptation – the process is routinely adjusted to optimise performance
Product Owner – responsible for maximizing the value of the product via the product backlog artefact (see below)
Scrum Master – promotes and supports Scrum, helping everyone understand Scrum theory, practices, rules, and values
Development Team – the team of professionals who do the work of delivering the ‘potentially releasable product increment’
The Sprint – a time box of 1 month or less during which a useable, ‘potentially releasable product increment’ is created
Sprint Planning – a time boxed session for the whole sprint team to agree on what will be delivered during the sprint
Daily Scrum – a time-boxed event for the development team, held at the same time every day, in which they update one another on the status of the sprint
Sprint Review – a review by the Scrum Team and other stakeholders of what has been done during the sprint; the Product Backlog (see below) is then amended where appropriate
Sprint Retrospective – an opportunity for the scrum team to inspect itself and plan improvements to the next sprint
Product Backlog – an ordered list and single source of everything that is known to be needed in the product. Maintained entirely by the Product Owner
Sprint Backlog – subset of product backlog items selected for the sprint
Increment – the value delivered from all previous sprints plus the product backlog items completed during the current sprint
All of these need to be present if Scrum is to be implemented correctly (without all of these, it is technically not Scrum). But Scrum is an intriguing, multi-faceted beast. It is designed quite intentionally as a light-weight framework which is in essence very simple to understand, however, the guide states clearly that it “…is not a process, technique, or definitive method.”
In my next post I look at the extra ingredients that are necessary to make Scrum work effectively.
In this first post of three looking at the basics of Scrum, I introduce the Scrum Framework and where it came from.
Scrum, according to the official guide, is “…a framework for developing, delivering, and sustaining complex products.”
It was created specifically for software development teams as an alternative to the more traditional waterfall development methodology but it is increasingly being used within the wider business world and beyond – including in education.
Scrum was developed by Jeff Sutherland and formalised, with Ken Schwaber, in 1995. It was built upon a wide range of ideas and influences, not least of all on a paper written in 1986 by two Japanese academics, Hirotaka Takeuchi and Ikujiro Nonaka, while they were Visiting Professors at Harvard Business School. They inspired the choice of name for the framework when they likened recent trends in development practices in Japan and the US to the game of rugby and the scrum formation in particular.
The core philosophy behind Scrum is the theory of empiricism – that is, making decisions based upon what is known. To explain this a little further, let’s take a look at one of the key issues with the old way of doing things.
At the start of a large and complex project there are many unknowns, for example:
What is the real-world capacity of the teams involved in delivering the product?
How will that vary over time as team members get used to working with one another?
How will it be impacted when individuals join and leave?
What will be the impact of unforeseen technical challenges, which inevitably occur in any complex project?
How will delays and issues in one area of the project impact other areas?
How well does the customer understand what they need from the product during the initial planning stage?
In what ways will the world and consequently the customer’s requirements change during the life of the project?
What overheads are required to manage the many different parts of the project?
What is the most efficient way to communicate between the different areas of the project?
In the old-fashioned waterfall approach, the project planners either ignore the potential issues or they attempt to estimate their impact. Because every project is different, these estimations are effectively guesses, leading to a plan that fails to predict anything useful. Consequently, projects, if they are delivered at all, are frequently delivered late and over budget – often failing to provide anywhere near the value that was promised at the start.
Rather than trying to understand the entire mountain up-front, Scrum minimises the impact of the unknowns by taking on the challenge in small chunks (called ‘sprints’ – lasting between 1 and 4 weeks). After every sprint, the team, the customer and other stakeholders learn something new about the product, the environment and the performance of the team, allowing for corrective adjustments to be made. This leads to a cycle of continuous improvement.
Realisation of Value
Another big advantage with Scrum is that it’s capable of delivering a working, useable product to the customer almost immediately or soon after the start, whereas waterfall projects typically only deliver something at the end, which can be many months – even years after the project begins. During these long projects, investment becomes tied up and only turned into value for the business when everything has been completed. Scrum allows the business and its customers to realise the value of their investments much sooner.
Also, if a ‘wrong turn’ is taken during a Scrum sprint, the impact is small (typically no bigger than the sprint size) and the resolution quick to apply. In waterfall, errors can go unnoticed for long periods of time and their correction can have significant negative impact on the plan and the budget.
In the next blog I look at the main elements of the framework as defined in The Scrum Guide.
In this post I take a not entirely serious look at the origins and catalyst of the agile ‘movement’, born in the exciting and daredevil world of software development.
It was deep into the evening of February 13th 2001. The wind pummelled the cables and towers of the ski-lift, creating an eerie, semi-musical cacophony of creaking metal and whirling wires. The icy snow rattled against the shutters. Behind them, inside ‘The Lodge’, the debate – which at times had raged almost as violently as the storm outside – came to an abrupt halt. The silence lasted a full minute as each of those present grappled with the implications of what they had created. One by one, they realised that the world would never be the same again…
Well I’ve no idea if this was how it really happened, but the date and location and possibly the bit about the raging debate are true, for it was on this day (or thereabouts) that 17 representatives (or “organizational anarchists” as they describe themselves) from a variety of technical disciplines and backgrounds created a “Manifesto for Agile Software Development”. And yes – it has changed the world.
A great many threads, influences and elements were fed into the cauldron during that meeting but probably two things, rightly or wrongly, have emerged from it to dominate first the world of software development and increasingly the wider world of business, over the subsequent two decades: the word ‘agile’ and the framework known as ‘Scrum’.
I will defer the debate about the word ‘agile’ until another post perhaps, but it is worth pointing out that for some at least, agile and Scrum are the same thing.
They aren’t – the former is a state of mind; a way of viewing the world and the latter is a framework – but it is easy to see how that belief persists due to the dominance of Scrum, which I will cover in another post. Throughout my blogs and other activities I consider ‘agile’ in its widest sense, as an umbrella covering a collection of varied principles, practices, philosophies, frameworks and techniques that fit in with the agile mind-set.
To understand this mind-set, and specifically why it has had such a significant impact on the business world, we need to delve a little further back in time to the bad old days of missed deadlines, blown budgets, disappointed customers and… waterfalls.
Once upon a time – before agile – most software products were developed in a sequence of phases using a methodology known as ‘Waterfall’. It went something like this:
Phase 1 – Requirements Analysis
The customer for whom the software is to be built is interrogated under the glare of powerful arc lights to reveal their inner most desires, which are written down in infinite detail to form the sacred “requirements document” – a tome often so large that entire forests are culled to supply the paper.
At the end of this phase, the customer is whisked away to a secret location until the start of phase 4, typically two or three years later, without any means of communication with the team developing their software.
Phase 2 – System Design
The analysts who conducted phase 1, pass the sacred document to a new group of analysts and return to their basement, for their job is done. This new team pore lovingly over the texts, extracting meaning from it all and writing new documents; sometimes embellishing their words with diagrams of great complexity and inner beauty.
When done, they too retire to their corner of the basement, leaving the new sacred ‘design document’ behind. The original sacred requirements document is carried carefully via a trusted cohort of anointed interns to a secure storage facility deep underground and is never looked at again.
Phase 3 – Implementation/Coding
In phase 3 the magicians are summoned. It is their job to mysteriously transform the sacred design document into code. Millions upon millions of lines of code. In fact it is believed that the greater the number of lines of code, the greater the quality of the finished product.
When the entire sacred design document has been transformed, the code is transferred to a special environment for the grand ceremony of User Acceptance Testing. Tradition has it that this milestone in the project should always happen at least 2 months behind schedule – often considerably more. By this stage the budget for the entire project should already have been spent. Twice.
Phase 4 – User Acceptance Testing
At this stage, the customer is brought back from their exile and presented with a partially functioning system. They are expected to remember what it was that they wanted at the start of the project all those years ago and to be wise enough to know how they should test it. Often they cannot remember the original intent, but either way, they have changed their mind anyway. The world is a different place now.
There is no time or budget to fix anything so the things that are most broken are ripped out.
Phase 5 – Operations
In this phase, a new group of technicians with no prior knowledge of the product attempt to install it (in whatever state it is in), into a new ‘production environment’.
The end users for whom it was built are then told of its existence for the first time. They play with it for a short while then spend the next six months generating a long list of suggestions about how it could be made into something useful, after which the machines upon which it runs are turned off and the process begins again.
Ok – to be fair, I am of course exaggerating – many will argue that in some situations a waterfall approach is a sound and effective way to develop software. It does have some great benefits at least on paper but joking aside, there are significant flaws in the concept.
The group of techno-anarchists who met at the Ski Lodge in Utah during the winter of 2001 managed to distil the essence of a new way of thinking that had been bubbling away in various places. They called it ‘agile’.
This essence is about many things but at the core is a set of values and principles that encourage flexibility, reflection, honesty, courage, trust and above all an in-built obsession with continuous improvement. All these things are achieved by replacing the huge, complex, heavily documented monolithic projects with a continuous stream of small steps, each of which deliver something of value to the end user.
These deliverables are released quicky and frequently so that everyone involved can learn about the product, therefore improving the effectiveness of the next small step (or increment) and ultimately delivering a more effective product or service. Due to the small steps, when things go wrong – and they do – the cost is small and the resolution is rapid.
When executed ‘properly’ this process has benefits for everyone concerned. The customer sees value almost immediately and receives a product that meets their real needs even when those needs are changing on a day to day basis. The timescales for delivering significant value are reduced considerably as are the budgets. The developers are empowered and trusted to ‘do what is best’ and to continually improve in all dimensions of their role, resulting in an improved quality of working life.
The only downside is that achieving the necessary agile mind-set, especially in larger organisations that are still organised with an industrial, ‘command and control’ mentality, is challenging and especially difficult to sustain. But the rewards are immense. I believe there are similar challenges facing adoption of an agile way of life in education but there is a similar scale of potential benefits. Potentially even greater.