Before there was The Scrum Guide there was Scrum. The Scrum pattern, which was derived from ideas drawn from two sources12 and the personal experience of its early adopters,3 existed happily for some fifteen years, and was, from the early 2000s, practised widely, if thinly, in many different contexts.
Importantly Scrum was interpreted from the original pattern according to the context of its practitioners. There were Scrum forums where some of the originators offered guidance and members hashed out ideas to make the pattern work in different situations—there were also those on the forums who challenged some of the tenets of Scrum4, but rather than undermining the system these criticisms helped refine it.
Like any good idea, the wider it spreads the weaker it becomes. Take smart phones, as an example. Once past the early adopter period of the iPhone 1.0 and the first Android phone hundreds of different models flooded the market, getting ever cheaper and ever poorer in quality. You can buy cheap Scrum now too. It comes in the form of various competing certifications, each with its promise of two-day mastery, and each obedient to this document known as the Scrum Guide. The committed learners read the Scrum Guide—but little else, and most not even that. There is no longer any real dialogue about Scrum because, hey, just like Science5, after all this time, and with so much knowledge we now know all there is to know. So, instead of dialogue we now have monologue: experts telling people off on LinkedIn for doing Scrum wrong. It’s all a far cry from “we are uncovering better ways”.6
So, Scrum, through its creators wanting to nail down its definition, became stale and lifeless. Hammer enough nails into a living thing and you will surely kill it. The early guides, 2010 to 2013 were an attempt to capture what was being practised, but the later ones introduced new ideas which seemed to be dreamed up by the creators themselves, with little community involvement. This came to a head in the 2020 incarnation of the guide, where the development team disappeared, the scrum master went from being a servant leader to become a “real leader”, a vapid, meaningless term and perhaps worst of all the scrum roles became “accountabilities” introducing great potential for finger pointing and blame.
Teachers of Scrum continued valiantly to respect the words of its founders, but it became increasingly harder as each new version contradicted previous ones, or introduced ideas the majority of seasoned practitioners disagreed with.
Simple Scrum
In March this year, my colleague Bob Hartman and I created a simple guide to Scrum specifically to reduce Scrum to its bare essentials and remove all the prescriptive detail the guide had grown to include. The has been surprising widespread adoption of this simple guide, with (at the time of writing) twenty-five translations completed and fourteen more in the pipeline. While this certainly seems to free practitioners from the detailed prescriptiveness of the official Scrum Guide, I don’t believe it goes far enough—both far enough back to recapture the soul of Scrum, and far enough forward to anticipate the next generation of software development practice. It needs something more… or perhaps something less.
Scrum Without Tears
What I describe here is not exactly Scrum, certainly not ‘Scrum by the book’, but I believe it captures what matters, and frees people up to truly use their imaginations and their collective wisdom. I call it Scrum Without Tears, or SWoT for short. The term developer is replaced with maker to avoid the confusion of overloading an already well-established term in software development. You’ll notice the concept of Scrum Team has gone, and the development (now maker) team has returned.
SWoT is centred around one or more small, cross-functional teams of makers who work closely with a product owner in sprints of up to four weeks in length, with a cadence agreed in advance. Multiple maker teams working together on a single product are supported by a scrum master, who is responsible for creating an environment conducive to free movement, autonomy, collaboration and creativity. All maker teams synchronise at the planning, review and retrospective meetings, but separate into their individual teams for their day-to-day work.
Each sprint starts with a planning conversation, and ends with a product increment, consisting of one or more completed items of value, where ‘completed’ means the item/s meet a predefined quality standard, and are ready for release. Work can be reviewed by the product owner (maybe alongside other stakeholders and users) at any time during a sprint; completed items are released to production according to the organisation’s release cadence.
At the end of each sprint there are two reflection meetings. The first meeting, is a product review conversation, involving makers, product owner, and all supporters and audience members who’d like to be involved. The aim of the meeting is to inspect the product and consider changes and improvements for the next sprint.
The second meeting is a process review conversation, which is just for the makers and product owner—and the scrum master when such is involved. It’s purpose is to acknowledge new learnings from the previous sprint, and consider improvements to try out for the next. This way the team/s and the wider organisation continuously improve the way work is done.
Individual maker teams should have their own, private reflection meetings any time they feel they need to, i.e. as soon as something goes off track, or any team member senses that something isn’t quite right. This is similar to the Lean manufacturing principle of “stop the line”. Teams are known to move with speed, grace and accuracy when they deal with their issues in real time, rather than letting them pile up.
Some teams will choose to have a short, daily check in, to mitigate problems before they occur, or to simply ask “how are you?” of each other. Such get-togethers are a team choice, not an obligation.
Periodically, larger reflection meetings should occur, involving representatives from other departments, e.g. sales, marketing, HR, facilities, and senior management. This is to keep all those involved in alignment with intent and direction, and to hear ideas of improvement from different perspectives. These meetings may occur regularly every 1-3 months, or are organised on an ad hoc basis, according to need.
SWoT People
For the sake of simplicity those working with SWot are identified in just one of five ways.
Maker: One who is engaged in the making of the product, in any way. Makers work in small, cross-functional, self-organising teams and are collectively responsible for completing all the work necessary to take a product from an idea to an actuality. While there will be support and collaboration between teams there are no hand-offs from one team to another, only—from each team—the release of completed work into production.
Product Owner: In bespoke situations this is likely to be someone from the organisation or group that has requested the product; in corporate/enterprise settings this may be someone from the product or marketing department. As product decisions often need to be made on the fly, whoever is established in this role, must have both decision-making authority and budgetary control.
Scrum Master: One who manages the environment, aligns the organisational procedures and processes with the purpose and principles of SWoT, guides the makers towards solutions, and liaises with management to ensure support for those doing the work.
Supporter: Everyone else employed by the organisation, for example those working in sales, marketing, customer service, operations, facilities, training and education, hr, finance, legal, etc.
Audience: Those outside of the organisation who are served by the products created: the users, paying customers and other beneficiaries. A SWoT audience is not a passive one, but one with a voice, with opinions, with ideas. SWoT makers, product owners and scrum masters engage and interact with audience members as appropriate.
You’ll notice that SWoT neatly sidesteps the scaling problem that Scrum ran into right from the start and has never adequately overcome, requiring several competing frameworks to deal with the ‘problem’ faced by most organisations of having more than eight developers. The structure of SWoT assumes one or more teams from the start, and by the teams being maker teams, rather than Scrum Teams we don’t run into the questions of how many product owners, and how many scrum masters. Growth from five developers to fifty is seamless.
Looking Forward
As our technology changes, so must our structures, but rather than inventing new structures, big, awkward ones with excessive rules, roles and meetings, like SAFe for example, we can utilise the simplicity of original Scrum, stripping away what is unnecessary and keeping only the essential pattern, allowing those using the framework to create a meaningful and useful process according to context. Ultimately it is the people doing the work who best know what they need to do the work. And it turns out they need very little to be imposed. The rest they will invent.
The New New Product Development Game, by Hirotaka Takeuchi & Ikujiro Nonaka, Harvard Business Review, 1986
Wicked Problems, Righteous Solutions, by Peter DeGrace & Leslie Hulet Stahl, Yourdon Press, 1990
In particular Jeff Sutherland, Ken Schwaber, Mike Beedle, Martine Devos and Yonat Sharon.
Mary Poppendieck and Scott Ambler come immediately to mind. There were plenty of others though, this author included.
This is, of course, sarcasm, a dig at those who use phrases like “The science is settled” or “the laws of nature are fixed”.
A reference to the opening statement of the Manifesto for Agile Software Development.