Adapting Scrum

That’s not a typo in the title – I see lots of articles about adopting scrum (i.e. getting started) but I wanted to touch on adapting scrum, for those who have been doing scrum “by the book” and are wondering what’s next.

The most common start point for groups as they step into the agile world is scrum. It makes sense because the official scrum guide details many of the things which they need to do, which may well be quite alien to them, for example having regular retrospectives to look for ways to improve how they work. I’ve heard people use the analogy of learning ten pin bowling with “bumpers” to prevent balls from going into the gutter, however, even following the scrum guide word for word won’t prevent a team from encountering problems. Instilling the practice of retrospection should give teams a fighting chance at tackling those challenges, but there are no guarantees. It’s worth understanding that scrum won’t fix your problems – all it can do is shine a light on them, and then it’s up to the people involved to resolve them.

Over time a team becomes familiar with scrum’s pillars (transparency, inspection, and adaptation), values (commitment, focus, openness, respect, and courage), events (sprints, sprint planning, daily scrum, sprint review, and retrospective) and artefacts (product backlog, sprint backlog, and increment). Once they find a cadence that works for them, a team can become restless and wonder “what’s next?” – ideally their mindset of continuous improvement has the team looking beyond scrum.

One area I encourage teams to investigate is XP because scrum focuses on how teams can organise their work and deliver value when faced with complex problems – it doesn’t mention anything about software engineering, and that’s where Extreme Programming fits in. XP provides some concepts which will be familiar to scrum teams (iterations, stand ups, sustainable pace) but also some which are commonly associated with scrum and yet aren’t in the scrum guide, for example, user stories and velocity. Scrum and XP fit together so well there ought to be a name for it!

Just like scrum, XP can appear simple at first but (as claimed by some games) it takes a minute to learn, a lifetime to master! Some of the concepts seem obvious, maybe even redundant, and yet I have seen teams struggle to do them well – “Code the unit test first“, “All production code is pair programmed“, and “Refactor whenever and wherever possible” to name a few; “Simplicity” is maybe the hardest because any half-decent developer can write code which works, but producing clean & simple code takes practice.

Fortunately, unlike scrum, XP doesn’t say you have to do it in its entirety. It was created in the 1990s, so some specifics of XP could benefit from a revamp but on the whole the values, principles and practices would still be valuable to most dev teams. Take an agile approach: understand your needs, find a part of XP which might help, try it, then inspect and adapt. 🙂

It’s often about this time that I find teams want to try Kanban – it’s important that teams are doing it because they want to find better ways of working, and not because they think it’s a way to avoid the parts of scrum that they don’t like. Whereas scrum has “bumpers” which provide a lot of guidance on how to get started, kanban does not mandate any process – this means the team need to provide that discipline themselves.

The simplicity of kanban might seem like freedom or even anarchy, but I feel it is a lot more work – the team need to pursue incremental, evolutionary change, constantly looking for ways to improve the way they work. Moving from scrum to kanban should be an incremental process – scrum is a good starting point from which to evolve. This is scrumban – a hybrid of scrum and kanban, not (as some people seem to use the term) a lesser version of scrum.

Many scrum teams may have started incorporating elements of kanban without realising it, for example the board that most people associate with scrum is actually a kanban board. Visualisation is key in kanban, but as many teams are now working remotely diagrams and images are essential tools in sharing knowledge whether you’re a kanban team or not.

Hopefully, the team is still inquisitive and hungry to improve because there are many other areas to explore – the agile umbrella is quite broad, but there are also many things not considered to be “agile” which can prove fruitful; the two which spring to my mind are Lean and Systems Thinking because they can be the basis for expanding the way the team observes, comprehends and tackles problems.

Some people consider Lean to be part of agile, some people don’t, but regardless of that I think there is a lot to learn from it. I recommend starting with eliminating waste; for me, this opened a whole range of more areas to explore but even a superficial appreciation of the types of waste can help teams see ways to improve. The other principles should resonate with those experienced in scrum and XP: Amplify learning; Decide as late as possible; Deliver as fast as possible; Empower the team; Build integrity in; Optimize the whole. The fact that these same themes keep appearing in different forms should reinforce their importance; if your team struggles with any of these, I hope this will make you revisit them and try to find ways to improve.

Systems Thinking is an area that I am still exploring. (Realistically I’m still learning in all these areas but systems thinking is one I feel I have the most to learn.) I feel that if XP can take a lifetime to master then I need to become a cat in order to fully get to grips with systems thinking! Fundamentally it’s about understanding how everything is connected to everything else.

In scrum, for example, you may observe a challenge in sprint planning but it could be that tweaking the way the team do refinement will address it. Perhaps adding another refinement session will help… but that takes time away from the planned sprint work… so the team may need to reduce their commitment… but we have a deadline to meet so we can’t commit to less (if anything we’re being pushed to do more)… so instead we end up shortening the refinement session… so we’re less prepared for sprint planning… so our forecasts are worse… so our stakeholders push harder… and so on.

So for those who have been doing scrum “by the book” and are wondering what’s next, I think there are many options; I recommend looking at Kanban, XP, Lean and Systems Thinking as a start, but <coach_voice>it depends</coach_voice> – as always, every team’s challenges are different so understand your situation, where you want to grow, and then look for alternatives.

Don’t follow the book if it’s not helping you; maybe there are other sources that can help; maybe you need to create a cocktail from a few things. Not only are teams different, but a single team changes over time, so what worked for you last year may not be right this year. In fact, if you are striving for continuous improvement then working in the same way that you did a year ago should be an indication that you might want to think harder about how to improve in that area. And remember: not every change will result in an improvement; inspect and adapt, constantly.

Moving the sprint end date

Most of Canada has May 24th off work – Quebec calls it “National Patriotes Day” but everyone else knows it as Victoria Day. But what do you do if it falls during your sprint? I’ve heard some teams move the sprint end date to compensate, so their sprint is still the same number of working days. (I’ll use 2-week sprints for simplicity but YMMV – I’ve worked with teams using 1-week, 3-week or 4-week sprints, but I’ve never seen a non-integer week duration; have you?)

I can understand the thinking behind moving the sprint end date because that gives them the same capacity as other sprints, but I think it’s a slippery slope: would you move the sprint end if some of the team are on vacation for a week? What if the company introduces a weekly all-hands meeting that consumes 90 minutes of everyone’s time? Do you move the sprint review and retrospective by the same amount?

The intent behind setting a regular cadence for your scrum events is so that everyone knows when they happen, and it simplifies meeting scheduling (set a recurring appointment and let it run). Often key stakeholders have busy schedules, so knowing the sprint review will always happen at the same time makes it easier for them to move meetings around it. (I would argue that your stakeholders’ willingness to prioritise your sprint review over other activities is a reflection of the value/importance of the work you’re doing.)

A regular cadence does not mean that your sprints will always have the same capacity – today’s stat day (aka Bank Holiday in the UK) means a reduction of 10% of the sprint… or more if some of the team took Friday off to make a 4-day weekend. Hopefully, the team thought about this when they planned the sprint and adjusted accordingly. Some teams I’ve worked with use a simple spreadsheet as a reminder to check each team members’ availability – maybe one person is on vacation for a week and another is on a course for 3 days.
I stop short of then calculating what percentage of the team is available and applying that to their velocity – this isn’t a precise science, just an aide-memoire to get them to think before they plan. If the team still relies on one person for a particular skill (e.g. database design) and they’re away then maybe the team needs to rethink which stories they can complete… and hopefully that’s also the trigger for them to work out how to share that skill so they don’t hit the same problem again.

An extreme case usually happens around the end of the year: a combination of holidays, stat days, and using up personal vacation time can mean a 2-week sprint has a tiny fraction of the normal capacity. I’ve seen teams make an exception and have a one-off extended sprint, spanning three or maybe even four weeks. I’ve seen teams just stick to their cadence and plan on completing far fewer stories. Recently I saw some teams try an interesting experiment where they abandoned sprints and teams for those weeks – instead, they took the opportunity to work on their tech debt backlog and pair/mob with people they don’t usually work with. There’s no “right” way to handle the unusual circumstances but I would recommend resuming the regular cadence as soon as possible.

One More Thing

In the current (2020) version of the Scrum Guide the word “commitment” is used with regards to the sprint goal – “Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.”

So what should happen after the team and product owner agree on the goal for a sprint, create a sprint backlog and start the sprint … but then someone* tries to add something to the sprint? (*The “someone” could be the product owner, a manager, or it could be a critical production defect.)

The Scrum Guide doesn’t provide much in the way of guidance other than “If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.”

What does that negotiation look like? A colleague from a previous company, Kiryl Baranoshnik, wrote a post with some good suggestions but I have a slightly different set of suggestions. Like Kiryl’s post, I’ll break it into two parts: Immediate Action and Retrospection, but I’ve not had time (or the skill) to create my own infographic yet.

Immediate Action:

Postpone it
The first decision should be whether the work really must be done in the current sprint – if it’s not important and urgent then it probably doesn’t deserve to jump the queue. The default answer should be to add it to the product backlog and only bring it into the sprint if it absolutely cannot wait.
If the product owner decides it must be done ASAP, then the team should follow their standard refinement practices, e.g. referring to their Definition of Ready and estimating the new story.
Exchange it
A question that I have found to help focus the product owner on whether the new work really justifies disrupting the sprint is to ask “If we were to bring this new story into the sprint then we will remove the equivalent (estimated) size of work from the lowest priority items in the sprint backlog – is that ok?” This tends to make it clear that some of the originally planned work is unlikely to be done, which often has a knock-on impact on the product roadmap.
Absorb it
If the team are confident they have the capacity to complete their sprint goal as well as the new request, then they can choose to bring the additional work into the sprint as is. The risk is that, despite their confidence, the team are unable to complete everything; this should be raised with the PO and discussed just the same as the team would do if a regular (uninterrupted) sprint was in jeopardy.
I put this option last as it can sometimes be more of a non-decision, e.g. because the team may feel pressure to accept the new work in addition to their plan or be overly optimistic. If it is the route taken then I strongly recommend the team make it clear that, even though they will try to absorb the additional work, it could put the lower priority sprint backlog items at risk. It’s always important to talk to the product owner if reality isn’t going as planned, but in this instance, I think it is especially important for the PO to be aware.

In summary, the three reactions to choose from are: “no, we’ll put it in the product backlog”, “yes but something has to make room”, or “yes we think we have room for it”.

Retrospection:
If the decision was either flavour of “yes” then the team and product owner should hold a retrospective to discuss the root cause (why did this work appear after sprint planning?) and how it impacted the sprint. I would recommend a retrospective even if the answer was “no” because the root cause question should still be addressed – why wasn’t the new request just added to the product backlog?

One other thing to discuss is how often these unplanned requests arise: if it becomes frequent then the team and product owner should discuss whether the sprint length is appropriate (if two-week sprints are frequently interrupted then maybe try one-week sprints), or if the nature of the incoming work is simply unpredictable (e.g. support teams tend to use kanban’s flow approach rather than sprints). There could be other causes, for example is the product owner able to say “no” to stakeholders (see Henrik Kniberg’s excellent “Agile Product Ownership in a Nutshell” video) but ultimately the aim of the retrospective is to identify the root cause(s) and experiments to try to address them.

Anti-patterns:

Leaving room for emergencies
If the sprint interruptions happen frequently then there may be a temptation to leave some capacity unplanned, ready to insert the additional work. The reason I list this as an anti-pattern as it can hide the problem but also because it can give a distorted impression that the team is over-delivering.
Having one team member assigned to emergencies
A slight difference to the previous one, I’ve seen teams allocate one team member (often rotating the duty each sprint) as their “on-call” person; they plan the rest of the team’s sprint as normal but the selected individual works from an unplanned “to do” list. Again, this hides the problem of late-breaking unscheduled work.
Saying “yes” without being able to consider the impact
Teams that don’t feel they can say “no” or discuss how the additional work impacts their sprint plan aren’t really planning their sprints – if you can’t say “no” then saying “yes” has no meaning. Morale tends to be very low as the team has no control over their workload, which management often describe as “lacking engagement or ownership”.

This list could probably include a lot more anti-patterns, but please leave a comment if you’ve had success with these Immediate Actions or seen other ways to handle the mid-sprint request to add One More Thing.

Scrum doesn’t work for us

Hearing a team say “Scrum doesn’t work for us” can trigger a negative reaction, based on an assumption that the team doesn’t understand Scrum or isn’t doing it right, but it could be a positive sign – maybe the team is growing and needs to move beyond “Scrum by the book”.

Scrum can be a good starting point because it provides structure and guidelines on how to “do” Agile – the Scrum Guide specifies roles, artifacts, and events. It specifies pillars (transparency, inspection, and adaptation) and values (commitment, focus, openness, respect, and courage), so it also tries to instil a mindset of “being” Agile. Scrum’s definition states “Scrum is simple” and “purposefully incomplete”; it is not intended as an endpoint but as a stepping stone on an Agile journey.

But rather than say “we’ve outgrown Scrum” and throw it away, this could be an opportunity for the team to inspect the way they work, consider which aspects they would like to change, and then run experiments to try to move towards where they want to be. That might sound like a retrospective, and that’s not an accident – effective retrospection is, I believe, the engine that powers change. If, for example, a team identifies the way that they collaborate during a sprint as something they could improve then they may decide to try pairing for the next couple of sprints. After those two sprints, they should ensure they discuss collaboration in their retro and whether pairing is helping – it could be they decide to extend the experiment, try something different, and adopt it permanently as part of how they work.

Another example could be to move towards kaizen (continuous improvement); maybe the team decide it’s working so well that they decide to drop scheduled retrospectives from their calendar. A purist might ask if you are still doing Scrum if you aren’t doing everything in the Scrum Guide; as a pragmatist, I would be pleased to see the team grow and wouldn’t care what they call it.