Patterns for Scrum Masters
Top item on my backlog today was prepping my deck for my Certified Scrum Master course here in DC next week. In looking through it, I thought I'd share one of the things that I teach that isn't in the Scrum Guide, but I think is critical for Scrum teams: The Swarming Pattern.
Here’s the simple truth. Humans love distractions. We’re like dogs and magpies. Every time we see something shiny and new we leap on it. We all know this. I certainly hope by now people have internalized that multitasking is not only bad, but a mirage. Trying to do more than one thing at a time kills productivity. Every time we get interrupted by an email, or switch from one task to another (“Hey, did someone just say something wrong on the internet I must address right now?) our focus collapses. It can take hours to get back into the frame of mind of what we were doing.
This is true at the individual level, but it is also true at the team level, and at the organizational level. Let’s just start with the team.
Let me take you back to the founder of the Toyota Production System, Taiichi Ohno. He had a taxonomy of waste, things that slowed the system. He divided them up into Mura, Muda, and Muri. Mura translates as “inconsistency or unevenness†-- it is actually a term from textile work, a snag in the cloth. Muda translates from the Japanese as “no result.†And Muri translates as “no reason.†Basically, the stuff that gets in the way of getting stuff done, such as overproduction, waiting, transportation, absurd expectations and the like.
The worst form of waste for Ohno, and truly the worst in any context was In Process Inventory. People often call it Work in Progress or WIP. The reason it is the worst form of waste is that you have spent time, money, and human effort and you still have nothing to show for it. The work is not done.
The key is to move to what Ohno called “one piece continuous flow,†and which I call getting stuff done, fast. In any Scrum team they’ll have, I don’t know, 10-20 things in their Sprint Backlog -- the work they’ve committed to that Sprint. And in almost every company I’ve visited all those projects have been started but nothing is done. There’s half done work.
The Swarming pattern says -- therefore focus solely on the most important thing in the backlog, and work on nothing else until it is complete. The whole team, or as many members as makes sense, should put their entire effort into completing one thing all the way through before they even think about doing anything else. Because they are focused on the goal, delivering value quickly.
I teach a bunch of other patterns in my courses and write about them in my new book, but the Swarming Pattern, IMHO, is the most important.
Data Specialist at Turing.com
3 å¹´Jj, thanks for sharing!
Associate Solutions Consultant at Adobe || PGDM - IMI, New Delhi
3 å¹´Jj, thanks for sharing!
Change Vanguard I Bespoke Change Consulting, Executive Coaching, and Facilitation for Executive Sponsors. I Feat.: The Guardian, Metro.co.uk, Brainz Magazine, The I Paper, The Sunday Post
5 å¹´I see this pattern very often. There seems to be distraction and also addiction to fire-fighting.?
Software Craftsman Product Engineer
5 å¹´I gain new understanding reading this one: "The reason it is the worst form of waste is that you have spent time, money, and human effort and you still have nothing to show for it. The work is not done." Thanks JJ Sutherland! After understanding SOLID Principles, Analysis Patterns, DDD, Steve Blank's Customer Development model, now I understand what the real purpose of Scrum and how to achieve twice of the work in half the time, as what your book title said:?https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X
Staff TPM @ Meta | Expertise in Product & Security Engineering Programs | Proven Leader in Cross-Functional Collaboration
5 年I agree that this is the most efficient pattern, but outside of the realm of Engineering teams, in practice this issue seems to be systemic/organization wide. Below are few root causes that the parallelization happens: 1) Stakeholder priorities conflicting with adhoc high priority requests (regulatory, production issues caused by external 3rd parties or external teams). In this case team runs a multi threaded operation, since the originally planned initiatives was started prior to the adhoc request 2) Issues with the design of the existing tech org and its tech stack (ie/ monolith vs micro-services), where it only makes sense to have single engineer to make changes to a given repo due to complexities associated with merging changes in non-prod and prod environments. This forces team members to pick up a separate initiative since they dont want to wait for 2 weeks on another higher priority item that can’t utilize their input. 3) Constantly changing priorities, due to intensive experimentation culture at an organization or top down design, where leadership dictates most of work to be done and constantly changes priorities 4) I am sure there are many other reasons but these seem to the most common in my experience