Using Scrum for Product Development

Scrum is a framework that helps deliver products in the VUCA (Volatile, Uncertain, Complex and Ambiguous) world that we currently live in. It was created by Jeff Sutherland and Ken Schwaber, launched in 1995 and is the most widely adopted framework for agile product delivery according to the latest State of Agile survey (~75% practicing Scrum or some form of hybrid with Scrum).

Empiricism

Scrum is founded on empiricism. This means that we create knowledge from doing and building experience, not by assuming. It is fine to start work with some assumptions, but we work to quickly validate assumptions, reduce risk, and learn so that we can increase predictability and control risk. This is achieved by working iteratively and incrementally, using Sprints. The output of each Sprint is potentially shippable (for feedback in either a production environment or a UAT environment as examples) or consumable (by another team where components or APIs are being developed).

Three pillars

• Transparency - a common standard is visible to those responsible for the outcomes
• Inspection - frequent checks on Scrum artifacts and progress towards the Sprint Goal, to detect any undesirable variances
• Adaptation - adjust based on any unacceptable undesirable variances detected when inspecting. This should be done as soon as possible to prevent further impact

Five values

• Commitment - personal commitment to achieving the Sprint Goals the team has co-created and to collaborating as a team to deliver valuable working software after each Sprint
• Courage - to do the right thing and work on tough problems
• Focus - on the work of the Sprint and the Goals that they have committed to
• Openness - about all of the work of the team and any challenges they are facing when performing the work
• Respect - for Scrum teammates to be capable and independent people

Measuring progress and learning through iterative product development

A key part of Scrum is that the team delivers a potentially usable increment of a product by the end of each Sprint. This is really important as it helps with the empiricism that Scrum is founded on. When we have an increment of the product that can be demonstrated at the end of a Sprint, which is what the Sprint Review is for and an example of inspection, we can demonstrate progress and we can get feedback. One of the Agile Principles for Software Development is that "working software is the primary measure of progress", not status reports. The Scrum framework helps with this, as you build an increment, show the progress and get feedback to learn. If there are things you want to change then you can adapt, and you are able to control risk. Scrum will highlight the issues you have within your organisation and it is managements responsibility to then resolve things that are preventing teams from delivering efficiently and effectively.

Some common anti-patterns to Scrum product development

I've been around long enough to have personally experienced and also heard stories about a few anti patterns, too many to list. There are a smaller number of really important ones to call out though;

1. Lack of planning. Sprint planning can take up to 4 hours for a 2 week Sprint. The reason why it can take this long is because it is for planning out how to deliver the user stories that are candidates for the Sprint, before the team validates their ability to deliver the chosen scope. The output of Sprint Planning is a Sprint Backlog which is created by the team in collaboration with the Product Owner and is based on the teams's capacity. Once the team has created the Sprint Backlog they then make a commitment to work together transparently and collaboratively to achieve the Sprint Goal. A mature Scrum team will likely;

• take the highest priority user story from the Product Backlog
• discuss how to deliver it
• break down the story into technical tasks and agree how to implement it and who will do each task
• check they have the capacity to deliver it
• split it if not enough capacity
• move onto the next story if capacity permits

When a sensible capacity has been reached, the team will;

• stop taking user stories in
• confirm the Sprint Backlog
• co-create a Sprint Goal

This kind of structured approach enables predictability. When teams rush planning, they usually end up planning during the Sprint when they pick the user stories up, which results in new understanding during the Sprint and often missed goals and a lack of predictability.

2. No potentially usable increment at the end of a sprint. If there is no product to demonstrate at the end of the Sprint, the Sprint has failed. This might sound a harsh statement but it is true. You cannot demonstrate a working product to a user, which means that you cannot demonstrate progress or get good quality feedback. These are two fundamental pieces to the jigsaw of Agile software development. This has secondary impacts too, like a need to produce status reports to provide an update on progress. That kind of impact is an example of waste, because it does not add any value and is actually additional effort required because of an ineffective implementation of Scrum. Also, priorities often change which means teams may have to stop working on something in flight to start a new piece of work. What if that initial piece of work doesn't get prioritised again? Well, you'll have just wasted whatever time had been spent working on it as there is no potentially usable product available.

3. Technical stories rather than user stories. User stories are exactly that, a story of how a user will use the product. The reason why this is taught to product development teams is because it is an effective way to understand how users want to use the product, so that we only build products that add value. Another of the Agile Principles for Software Development is "Simplicity; the art of maximizing the amount of work not done, is essential". Agile product delivery is not about people writing code faster, it's about working on less things that add more value which in turn means we get better outcomes sooner. When teams get swamped in technical detail they lose focus on the user and what the real value is.

4. Regularly not completing sprint scope. Scrum teams are self organising, ideally, autonomous teams. Part of building trust with stakeholders, and being afforded autonomy, is that we do what we say we will do most of the time. If we regularly allow work to carry over, not burn down on commitments and miss our Sprint Goal then trust will wither away. It is much harder to build trust than it is to lose it. A lack of predictability makes life hard for the team because it makes life hard for their stakeholders. Stakeholders then require other things to get comfortable, because they don't trust the team to just get on with things. Those things that stakeholders then ask for are usually waste, which prevents the team from getting on with work, which can become a vicious circle.

5. Non cross-functional team. If you depend on other people or services outside of the team, you have introduced waste into the system. Scrum enables continuous learning and delivery by simplifying the environment, so that teams can deliver independently of others. If there are trade offs outside of the Scrum teams control, like organisational design incorporating front end and back end teams, then the Scrum team should make visible the waste for management to consider, and look at what is within their control. This would mean building close relationships and an integrated delivery system with any individuals and/or teams/services they are dependent upon, and also ensuring there are no dependencies within the team (dev, test etc.). This means that they visualise the work on one board (based on the customer request), they plan together to ensure that collectively they deliver a valuable increment of product, they review together so that the customer can see and play with something that they care about, and they create a mechanism for collective learning.

6. Cargo Culting. This is a term used for people who just follow the process, blindly hoping that they'll get the benefits. As an example the team holds Sprint Planning meetings, Daily Scrums, Sprint Reviews and Sprint Retrospectives but does not deliver something that the customer cares about. They spend more time trying to improve the practices rather than work out how to deliver valuable products to the customer more effectively. This type of team generally focuses on story points as a measure of value delivered, rather than on working software that a user can play with. During the Sprint Review they will talk about how many points they've burnt down, share their burndown, but demonstrate nothing valuable to stakeholders, who have by this point stopped coming along.

It's a framework

Scrum is a framework, not a process. There are many processes, techniques and methods that you can use within the framework. As Jeff and Ken state; "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices."

There is a guide, you should read it if you are working in or with a Scrum team

The Scrum guide can be found online here. It's a short read and if you are working in a Scrum team it is essential, so that you understand what Scrum is all about and can make better decisions about how you work. If you are a Scrum Master you will know this inside out and be using the framework to shine a light on disfunctions and be actively working with the team and organistaton to resolve them.

Scrum isn't always suitable

Before deciding on a framework to use, it is a good idea to understand the environment you are operating within. The Cynefin framework enables this by helping to understand different domains, which can then be used to indicate whether something like Scrum or maybe Kanban would be a suitable framework to help deliver.

I am a Scrum Master, and believe passionately in the value Scrum offers to enable delivery in a VUCA environment. If you have any questions about Scrum I'm more than happy to engage in discussion either directly or in the comments below.

Thanks for reading,

Simon