Continual Delivery could blow it away
It’s common to see Scrum as a panacea; an answer to our prayers.
We know we need to move beyond those drifting, missing the mark deliveries, those Zombie Scrum teams — and we know, with the right team and Agile Coaches, you can achieve an almost zen like flow.
These enduring product teams, with reduced overhead, when combined with DevOps practices that marry quality and value, can deliver great products more effectively and efficiently than the old ways. What’s not to like?
Unfortunately, there are three reasons to maybe feel a little concerned. Three things, that for me, could spell doom for Scrum.
Death knell number 1
Key in the palm of hand photo by CMDR Shane on Unsplash
The Product Owner
Or, a layer between your Product team and the business. Or worse — between the business and the actual customer. Only a master product owner can avoid becoming a glorified backlog administrator, truly connecting the product teams with the various business stakeholders and customers. There are some great ones, who work hard to understand the nuances of different requirements for a given product, across the myriad user sets, and apply panache in demonstrating value and quality and involving the users. But there are dangers that can undo you.
Take a look at Product Owners — The Good, The Bad and The Ugly that Elad Sofer wrote for some additional perspectives — with a picture of Clint Eastwood in the article, how can you not enjoy it? Roman Pichler also writes well on this in the Product Manager vs Product Owner. So, with the right Product Owner, Scrum can survive this.
But we have…
Death knell number 2
Photo by sydney Rae on Unsplash
The Scrum Master
For many of us the Scrum Master should be an Agile Coach — to reinforce the nature of what this role is all about. Rather than pass an exam and have the title, you need to coach or be passionate in developing your coaching ability. What’s worse, it’s dangerous for a product team to outsource facilitation of agile practices to a single role, and with a nominated Scrum Master to do that part of it, there’s a chance that can happen.
Teams should live and breathe agile, with soul and empowerment. Agile coaching plays a great role, nudging from time to time, helping teams to raise their game, introducing variance and innovation into retrospectives where required, fixing issues that creep into daily stand ups, and so on. We don’t need a Scrum Master as the conductor for all this, we need teams that are agile to the core, with Agile coaches to help them be even better. In my best American accent, teams, you’ve got this.
The Career Path of a Scrum Master by Mike Cohn is worth a read for other perspectives.
So overall, with the right Scrum Master, and a team that owns it, Scrum survives this.
But, we have…
Death knell number 3
Sprinting picture by Tim Gouw, Unsplash
Sprinting (and stopping — and scaling)
You have a great Product Owner. You have a great Agile product team with Agile coaching as required, but this last point could kill Scrum: scaling it. SAFe, Nexus, LeSS, so many frameworks to scale Scrum. But is that a good idea? Perhaps no, and here’s why.
First, we need to ask ourselves the question, would we prefer iteration based agile, where you start and stop and start again, or flow based agile, where interruptions are reduced? Or, how can we ever do multiple deploys to production a day if we’re in two or three week sprints? Now it [be sure to read the comment from Stef below this article, for a cogent argument as to why only releasing at the end of a Sprint is a fallacy].
Let’s look closer at Scrum — we have planning meetings, daily Scrums, retrospectives. To quote:
To standardize on a Scrum-based scaling framework means that high performance lean or continual delivery teams would actually be stepping back in their delivery capability. Standardizing on frameworks such as Nexus, LeSS, SAFe immediately places limits on your organization’s ability to maximize true business agility due to the inherent inflexibility to adapt to context and maturity. Rather than promoting moving to a combination of Lean and Exploratory approaches as advocated in the Lean Enterprise, it instead promotes moving from small batch Scrum iterations to large batch program increments, thereby scaling up the associated overhead with it.
This quote is taken from one of my favourite books of 2018, Scott Ambler’s and Mark Lines’ An Executive’s Guide to Disciplined Agile, an essential read and recommended by my friend Chris Kyte.
It goes on…
While Scrum prescribes the use of a set of ceremonies, Lean does not prescribe this overhead, in fact it considers them a source of waste and instead suggests that it be done only when necessary. This requires a degree of discipline and self-awareness not usually found on teams new to agile, hence this lifecycle is considered advanced.
And further…
A team following the Scrum-based Agile lifecycle may never identify the strategy of Continuous Deployment on their own because having a two-week iteration may preclude the idea of releasing several times a day into production. Yet, if people on your team were to hear about other teams in your organization working that way, they might soon choose to start experimenting with CD techniques — this in turn could lead to the abandoning of time-boxed iterations and moving much closer to a Continuous Delivery lifecycle.
Scrum has overheads, you stop working, and review the sprint, and have a retrospective on the sprint, and plan another.
You keep starting and stopping.
These ceremonies can be so valuable, but you risk holding them in a fixed pattern, whereas, could a disciplined truly agile team not be better to hold them on demand, or as required?
Not just this, but there’s a danger that the way Scrum may be applied works against continual delivery, and potentially worse still, you’re scaling the overhead, with global retrospectives of retrospectives, and prescribing an approach which by its prescription inherently can’t be agile. A bit of soapbox maybe, but food for thought.
Don’t get wrong, I love Scrum. I think it’s great and I like the practices, despite often starting with process versus what the first line of the agile manifesto tells us. It works, and with the right ingredients, it’s powerful beyond the sum of its parts.
Scaling it can be great too, at a point in time. Which is the key point for me — scaled agile is a natural evolution that an organisation probably needs to go through, but it could be a mistake if it’s viewed as the end state. Instead — when you’re ready, you can take it to the next level — further towards Continual Delivery, to flow and daily deploys/daily releases — to the three most important metrics in software delivery performance: lead time, release frequency, and mean time to repair — with the Sprint cycle diminishing in relevance.
Ultimately in all this, it’s about delivering value to your customers, and whatever way you can do that the fastest and most effectively is the best. We should operate above the method, whether it’s Lean, Kanban, Scrum or anything — but there are some interesting questions around Scrum in a Continuous Delivery world which can’t be ignored.
And for a truly interesting event, if you’ve not already done so, read about ING Bank’s agile enterprise transformation. It began with
a spectacular big bang event in Amsterdam’s Ajax soccer stadium in which the organisation morphed into Spotify-inspired agile Tribes and Squads overnight.
It’s described in more detail by both McKinsey and Mary Poppendieck.
Apparently ING Direct’s ambition is to become “…a digital bank, an IT company delivering banking services” — as we all know, all organisation’s are becoming software organisations.
Gary Watts
If you enjoyed this article hit 👏👏 👏 a few times.
Footnote: Having deleted the original version of this article and re-published, it wouldn’t be right to not include the comment that Stef left on the original article, so that’s included again for posterity. Aside from the comment being a 3 minute read to the 6 minute read article, which we both found amusing, his comment is a compelling and expertly argued response to this article — worth reading more than the article itself 😊
Stef wrote:
An interesting and thought provoking article …
I feel Death Knell (DK) 1 and 2 could be directed at any roles that are not properly understood or landed within an organisation — does this really mean we should give up???
The main issue I see around POs is lack of authority, influence or connection back to the business, rather than some dark art that needs 20 years mastery. Does this matter? Well if you value clear, timely and decisive decision making “Yes” — so if organisational agility is the aim, understanding the value of the product owner role would really help the organisation maximise business value. In my experience, you tend to get Jira Monkey POs when there is a complete misunderstanding of what the PO role is, and here, the entry level Scrum training and exams are effective at pointing out the way it should be (as should any SM worth their salt)
Whilst I agree that the Scrum Master exams are basic and don’t teach you everything to be a ninja Agile Coach, they are a start not an end to the journey. There are parallels with most other exams like ITIL or PRINCE2 which have foundation level, practitioner and beyond. Many US based Agile educational organisations could learn from this naming clarity — ICAgile being a beacon of good practice in an otherwise confusing market place.
On DK3 — Around the Scrum events, it is a surprisingly common misconception that you can only release once in Scrum — at the end after the Sprint Review. I don’t really understand this as in the Scrum Guide states very clearly that “Release products and enhancements, as frequently as many times per day”.
These events, not only do they help to develop physiological safety and team building, they provide the main mechanisms to facilitate Transparency, Inspection and Adaption — which are central to any empirical approach. I simply don’t see them as start or a stop, I see that as essential activities of doing the work. They embody “Individuals and interactions over processes and tools” — line one of the Agile Manifesto. This is central to high performance teams and complex adaptive systems; lose this, lose being “Agile”. If we ignore the value of the events and relationships with the SM and PO, we slip away from empowered teams to subservient teams — losing 20 years of hard earned improvements.
We also need to consider the physiological effort of not having a (Sprint) goal to commit too. I know at least one organisation that has adopted a CD approach only to revert to a sprint based approach due to the physiological impact of not being able to clearly visualise a goal. Ask yourself the question, if you wanted to run a marathon, would you prefer to do this on a tread mill or actually get out on the open road with a clear goal and reward at the end? I know which one I would choose!
Finally, I don’t see Scrum is a panacea. It is only a framework albeit a simple and effective one. As a framework it is intentionally incomplete and needs augmenting with domain specific practices. The real challenge in software delivery is not the process you use, but the ideas and technology you are working with. CD is a great technique to getting product out quicker, but I would urge people not to confuse it with an approach that encompasses the complexity of working with actual human beings.
Thanks Gary or the well articulated argument — it is an excellent example of “Inspection”. Whilst I always keep an open mind, for me, I’m not persuaded there is anything better (currently) which would make me “Adapt” and ditch Scrum.