Script

Introduction

I have been using the Scrum process to successfully deliver software applications for years. For me, it is my default approach that "just works", so rather than spending time trying to invent a new process, I usually just fall back to using regular Scrum.

In recent years however Scrum has fallen out of fashion. I don’t know why, as I have been too busy just using the process, but I have read many posts online and heard some people say that Scrum does not work, and even that we are living in a "post-Scrum World".

In spite of this I still use scrum, and my position is that:

1. Scrum works well for my teams and I.
2. I have not found a better way yet.

When I find an alternative to Scrum that fits better, I will use that too. I have had some success with Kanban with support teams for example, where sprints make less sense. For the majority of cases when I want to deliver something in phases however, it’s still Scrum for me.

I will now try to sell Scrum to you in case you still have doubts, but before I do that I will give an overview of Scrum itself as a refresher for old hands, or an introduction for new comers.

It is also important to note that I am not obsessed with any process: I am a pragmatist, not a zealot. As soon as I find something better than Scrum, I will drop it.

What is scrum

Scrum is a process with two aims:

1. To deliver something in phases or "iterations", for example a project or application release.
2. To continually improve the process itself via retrospectives.

Each iteration, or "sprint", typically has a planning phase at the beginning, an implementation phase making up the majority of time in the middle, and finally a retrospective at the end.

Lets break that down further, and define those terms one by one, by describing a typical sprint starting on the first day.

Day 1: planning

On the first day, the team get together with their stake holder, usually referred to as a Product Owner or a Product Manager, and they agree on the scope of the upcoming sprint. Higher priority tasks are taken in first, or those that are dependencies for other teams.

Each task is then estimated. It is important to estimate the size of each task, as this will help the team to plan capacity better and also to track the level of completion during the sprint (more on that later).

A task is estimate either in days, or "story points", which are points that the team agrees to assign to a task that roughly equate to whether it is a small, medium, large, or extra large effort. Often a team will estimate in a group, with each member assign an amount of points to a task, and the most common value assigned will be selected. That approach is often called "planning poker", and therefore the meeting itself is often called a "planning game".

The benefit of the planning game approach is that estimates are peer reviewed, and weighted. It is also important to note that estimates need to be inclusive, for example they should not only include implementation time, but should also allow for design and testing activities.

Once the scope is decided, and the estimates are recorded, each task is then assigned an owner for the upcoming sprint, matching the nature of the task to the skill-set of the team member.

All told, a proficient team should be able to complete their planning game in 1-2 hours.

Day N: implementation

During the main part of the sprint, the team are busily building and testing their new features, bug fixes, or whatever other tasks that have been assigned to them.

I like to think that the team have a virtual "do not disturb" sign on them, meaning the best thing you as a leader can do is ensure that you do not interrupt their flow, and try to prevent others from doing the same.

In each team, a "scrum master" should be assigned. That can be a permanent role for someone, or I have also seen it successfully done via an agreed-upon rotation within the team.

The scrum master has three important jobs:

1. Run the "daily stand-up" meeting.
2. Ensure that nobody is blocked from progressing.
3. Gather the team feedback for the retrospective.

The "daily stand-up" or "daily scrum" is one of the main benefits of scrum, as it gets the team talking to each other at least once per day, and any blocking issues are raised immediately to the scrum master. Scrum is light on process and light on meetings, therefore there is a real reason why it is called a "stand-up" meeting.

Before the days of remote work and Zoom, when I started my career stand-up meetings were face-to-face, in a circle, with team members literally standing up. The aim is to keep the meeting short, as nobody likes standing up for too long. Those meetings are supposed to be uncomfortably: to keep people on-topic and stop them from digressing.

Sadly with the move to Zoom meetings, we have lost that feature so the need for good meeting discipline is even higher now.

The person responsible for maintaining those good meeting habits is the scrum master. An experienced scrum master will typically ask each team member only three questions each meeting:

1. What did you finish yesterday?
2. What are you working on today?
3. Are you blocked on anything?

If they answer no to the last question, then they move onto the next person. If they answer yes, the scrum master needs to identify who in the team can help to unblock the topic, and then schedule a follow-up meeting with just those people after the stand-up.

I hope you are seeing now that scrum meetings are short, to the point, and quick. If they are running too long, its a red flag.

Last day: retrospectives

You remember those story-point estimates the team assigned during the planning game? During the sprint, those points will be burned through as the time is being spent on building and testing the solution. The scrum master will be able to plot this on a "burn-down chart", that are generated automatically by tools like JIRA, that show the effort over time being burned.

Ideally, the burn-down chart goes down at approximately 45 degrees from left-to-right, until it reaches zero on the last day of the sprint. In reality that rarely happens, but that is perfectly fine as it’s meant as an ideal target, not a hard cut-off.

Sometimes your burn-down hits zero too early, meaning your overestimated the effort during planning, but more often your burn-down never reaches zero by the end of a sprint, because you underestimated the effort.

In general in the software industry, underestimation of tasks, sprints, and projects is endemic, and I have my own theories about why that is, but that’s a topic for another episode.

Once the scrum master has the final burn-down chart for the sprint, the next thing they need to do is to run a retrospective meeting with the team, and again ask each member only three questions consisting of the following:

1. What went well during the sprint?
2. What went badly during the sprint?
3. Are there any improvement actions we need to take?

This meta-step is very important in scrum: remember we discussed before that scrum is not just about delivering something, but it is also about improving the process itself per iteration. Therefore each team may end up tweaking their process in different ways, which is absolutely fine!

Once that feedback has been gathered anonymously by the scrum master, it is aggregated into their sprint report alongside their burn-down.

Finally, its a good idea to gather all of the teams together into a wider review for 1-2 hours, to enable each scrum master to present their reports, discuss improvement actions, and finally for the team members themselves to demo what they have built during the sprint to their peers!

Those demos are a key cultural touch-point for you the leader, to ensure that achievements are praised in public, and healthy peer review is happening on a feature-by-feature basis. Review demos should be fun, and the more demos there are, the more real work was delivered per sprint.

If the demo count is low, naturally that is a red flag that needs to be addressed.

A brief history of scrum

Now lets talk about the origins of scrum. Scrum was built upon the ideas of several predecessors, but it is broadly agreed that the creators of Scrum as we know it today are Ken Schwaber and Jeff Sutherland, in their joint paper "Business object design and implementation", presented at the OOPSLA '95 workshop.

Scrum is an example of an agile process, meaning it aims to adhere to the "agile manifesto" [1], of which Ken and Jeff are co-authors. That manifesto contains the following opening statement on their website:

"We are uncovering better ways of developing software by doing it and helping others do it. 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."

Its a great statement of intent, my favourite aspects of it being to value people over process, and to embrace change.

Scrum being an agile process, is actually very light on the process part: you could explain the entire process on a single sheet of paper.

Instead, its best to think of scrum as a framework for people to collaborate together, who share a common goal to build and release something.

If you want to get a deeper dive into Scrum, including its origins, I would strongly recommend the book "Scrum: The Art of Doing Twice the Work in Half the Time", by Jeff Sutherland, the link for which is in the episode notes on my blog.

The underrated benefits of Scrum

Now that we have discussed what scrum is, now we can review some of the benefits. Rather that giving you the textbook benefits, inside I will present my personal benefits based upon using scrum in the field for many years.

There are different benefits for different people. Firstly we will look at the benefits to the practitioner, then the customer, and finally the manager.

For the practitioner in the scrum team, you get a high degree of certainty about what you need to work on next. The tasks brought into a sprint for you have been planned, prioritised, and estimated, and are therefore "ready for sprint".

Part of that "ready for sprint" definition is also agreeing upon the "definition of done" for each sprint tasks, meaning in plane English the team not only agree upon the sprint entry criteria for each task, but also the sprint exist criteria when the task is considered done, for example the feature is tested and integrated into the next release.

All of this removes any doubt around the question "what am I doing next?". You already know, because you were part of the planning game along with the rest of the team.

The practitioner has clarity. In addition, they have an escalation process via their scrum master in case that clarity breaks down, or there is some other issue that is impacting upon their ability to deliver on their sprint tasks.

Finally, the practitioner has a voice, and a number of forums like sprint planning games, stand-ups, reviews, and retrospectives in order to express their opinions or suggestions. Scrum is an open, transparent process where everyone is accountable for a successful outcome.

For the customer, be they internal or external stakeholders, scrum gives them visibility into what is being worked on next, and certainty that they will receive their deliveries in iterations. They don't have to wait 12 months before they get their hands on their releases, instead they can receive frequent, small releases in iterations to play with, and more importantly give feedback on immediately.

That flexibility to give ongoing feedback, and change upcoming sprint priorities based upon changing requirements, makes scrum a very agile process.

Lastly for the manager, the main benefit in my mind is the ability to have visibility into what is happening now, via the current sprint dashboard, and what is happening next, via the sprint backlog. The manager can help shape priorities in the backlog to ensure higher-priority tasks are brought into the next sprint sooner, or they can de-scope tasks that are no longer relevant.

Personally, I love to drive processes by metrics as much as possible. I tell my teams that facts are more important that feelings, and scrum gives me that reassurance that the sprint dashboard will act as a single source of truth for my teams and I.

One of the scrum habits I insist on is no sizeable task, say for example 1 day or more, should be carried out unless there is a corresponding ticket for that task in the dashboard. Put simply, if there is no ticket, it's not being tracked so in my mind it does not even exist (and no resources will be allocated to it).

Scrum is about always moving tasks and topics forward, and that forward motion, or "velocity", is measurable via the burn-down charts. A good scrum team has good velocity, with tasks being consistently closed within their estimates.

Velocity is the key metric for scrum, and measuring and maintaining a good velocity per scrum team is one of the main management goals. Put simply, the burn-down is the pulse, or tempo of your teams. The healthier the tempo, the more that will be delivered at the end of the sprints.

Why does Scrum fail?

Scrum usually fails due to under-commitment. Most organisations that fail to successfully implement scrum do so due to half-implementing it: they cherry pick some of the parts they like, then bolt that onto their existing processes and call that "scrum", and then complain that "scrum doesn't work" when their efforts falter over time.

I once worked with a manager at an insurance firm, and he told be "we don’t do agile, but we deliver in an agile-like manner". Some people like the terminology around agile processes, but are less eager about the hard work and commitment required to make them work.

In another company, we in the Engineering teams used to joke that we were doing "wagile", which was the unwelcome marriage of waterfall and agile in the same Frankenstein-like process. You could summarise wagile as "waterfall with sprints", and it’s remarkably common in the wild.

If your organisation has a dedicate PMO (Project Management Office), Project and Programme Managers, Gantt Charts, and even Microsoft Project licenses, then chances are very high that you are not doing scrum (even if some folks are claiming the opposite).

Scrum in many ways is an anti-process: the whole point of the agile manifesto is to put people before process. Your scrum process should be definable on a single slide. Any more than that is over-engineered.

Wrap-up:

Lets recap what we have covered today:

1. In spite of Scrum falling out of favour with some, for me it is still my go-to process for delivering software, until I discover something better.
2. At a high level, Scrum delivers the releases via iterations, and reviews of the process itself in those same iterations. You can consider it to be a sell-adjusting process, or framework, that the team using it can adjust every sprint.
3. A scrum master is responsible for ensuring the process runs smoothly, the deliveries are fast, and that nobody is blocked for too long.
4. Each sprint is broken into three phases: a planning game at the beginning, a main implementation phase in the middle when the work is done, and finally a retrospective at the end to view demos and review all outcomes.
5. During the implementation phase, the team have daily "stand-up" meetings, and track their delivery velocity via a burn-down chart. Ideally, all work should be burned-down to zero by the end of the sprint.
6. Scrum is an example of an agile process. The principals for such processes are defined in the Agile Manifesto. Broadly speaking, those processes are light and favour human collaboration over bureaucratic processes.
7. Some of the benefits of Scrum include certainty over what needs to be worked on next, earlier releases to customers via iterations, earlier customer feedback, plus the flexibility to adjust the delivery plan based upon that feedback and other external conditions.
8. Where Scrum fails, typically in my experience its due to a poor implementation, for example trying to bolt Scrum onto an existing waterfall process, and then watching that fail while blaming Scrum for "not working".

I hope you enjoyed this episode, and I look forward to covering the next topic in this series with you! In the interim if you want to follow me online, you can find my blog at TechLeader.pro, or follow me on Twitter @TechLeaderPro.

Thanks for your time, take care and have a great week!

References:

[1] : Agile Manifesto - https://agilemanifesto.org/

[2] : "Scrum: The Art of Doing Twice the Work in Half the Time" - Amazon

Download

techleaderpro-episode-15.mp3

File details: 27.7 MB MP3, 19 mins 14 secs duration.

Title music is "Still Cold" by Crystal Shards, licensed via www.epidemicsound.com

Subscribe

Apple Podcasts (iTunes)

Spotify

Google Podcasts

Amazon Music

Main RSS feed

Sponsor

Five.Today is a highly-secure personal productivity application designed to help you to manage your priorities more effectively, by focusing on your five most important tasks you need to achieve each day.

Our goal is to help you to keep track of all your tasks, notes and journals in one beautifully simple place, which is highly secure via end-to-end encryption. Visit the URL Five.Today to sign up for free!