This is the part I wrote first. All the other parts were written to justify this coldhearted analysis on what should be the role of management in Scrum. I was convinced that there had to be something more for management to do than “support the team and get out of the way.”
Over the years, managers of all stripes, engineering managers, product managers, project managers, manager managers have complained to me, usually as a stage-whispered aside, that “agile is dead” or “scrum is not agile.” Their frustration seemed to come from several places: the lack of promised accelerated productivity, the lack of visibility (other than the sphinxlike story point’s slow burndown), and complicated answers to simple Waterfall milestone status questions.
We managers, of all flavors, have layered on a whole superstructure of improvements on top of Scrum in our quest for certainty in an uncertain world. But let’s look ourselves in the selfie: Have these improvements worked? Have we improved Scrum? Have we delivered more certainty than what Scrum originally promised? No.
Working through the Computer Science foundations of Scrum, the data structures and algorithms, I realized that all these improvements to Scrum brought about by managers like me haven’t improved Scrum but obscured a scientific model of work under a fog of superstition, old husband tales, and best practices.
So, now, after all this, what really is the role of Management in Scrum?
Scrum is system and humans are its parts
First, a quick summary of parts 1, 2, 3, 4, and 5
- I read a book on Scrum by the inventor and co-creator of Scrum and his son
- I read this book because while I’ve been supporting Scrum for more than a decade, I kept hearing about how Agile is dead and Scrum is not Agile.
- I realized two insights from a close reading of the book: managers have no formal role in Scrum (autonomous teams don’t need managers) and there is a hardcore computational basis for the many of the processes that people follow in Scrum.
- I further realized that if you don’t treat these data structures and algorithms for what they are, you don’t get the productivity and team happiness benefits of Scrum.
I bet, as an experienced scrum master, you already knew all this. But most of the management folks I run with don’t think of Scrum as a computational system. We managers tend to see Scrum as a set of new best practices for project management. This is a little like seeing Astronomy as a new a better way to cast horoscopes for Astrology.
Scrum, at its heart, is a computational system that creates a human-based machine. Scrum uses this human-based machineto accelerate productivity by removing waste from the work process. The secret of Scrum is in the constraints it puts around inefficiencies but not around creativity. The beauty of Scrum is in its economy of design. This design enables Scrum to apply to a wide range of work problems (not just software development). A side effect of Scrum is that the human-machine manages itself and its moving parts (team members) are happier than they are in with a traditional manager managed process.
If Jeff Sutherland, like Jeff Bezos, had built a private platform out of Scrum instead of a public framework, he would be rocketing people to Mars and tooling around on his billion-dollar yacht.
Treat people like machines
OK, fellow managers, here is my advice (caveat emptor)
First, leave Scrum alone. Don’t fix it. Don’t do pre-work outside of the Sprint. Don’t tell the Sprint team or the Scrum master what to do or how to do it. Let the Scrum process fix itself over time.
Second, fix the problems outside of Scrum with formal computation systems (human machines) for those folks left out of the Scrum process. Translate your work into data structures and algorithms and eliminate waste. Don’t worry about whether the computation will be performed by silicon or carbon.
Scrum does an excellent job of work-as-computation at high efficiency. It does this by creating formal roles for the people who Sprint and ensuring that all work is filtered for priority and done with in a predictable, repeatable, time-boxed process.
BTW, this process of treating people like machines is nothing new!
The first computers were not made of silicon and software. They were people. For thousands of years people were doing the computing that enabled empires to trade, businesses to serve customers, and NASA to send rockets to the moon. Only within my lifetime have we delegated computation to non-humans.
I sense your eyebrows rising sharply! Managers who treat people like machines are inhumane.
And you are right. If we don’t follow Scrum’s model of how to compute well with people, then we managers are the living incarnation of Dilbert’s pointy-haired boss. We are micromanagers who make buzzwords out of useful tools like Agile, Scrum and DevOps. But if we don’t treat our people like machines what are we treating them like? Resources? Head counts? Soft capital?
So, if you think about it, as a manager, you pretty much treat your people like machines at some level. You give them tasks, expect them to ask relevant questions, and then to do the task to your specifications by the due date. You expect high-functioning employees to work well with vague input and all the rest to require SMART input. You don’t expect the employee’s feelings to impact the work. You are not a monster, but you have a business to run.
It is interesting to note that the people-treated-like-machines who follow a Scrum practice are far happier than their beleaguered and belabored non-Scrum counter parts Why is that?
Formal (systems) beats casual (anything)
I know we live in an age of the casual work environment. Dress codes are relaxed, hours are flexible, and hierarchies, while still in use, have been hidden away like ugly relics of a less enlightened age. But only the outside of the workplace is casual. On the inside our workplaces are just as formal as they have always been. I believe the patina of unscripted, casual interaction has made the workplace hard to navigate and an unhappier place.
Let’s contrast the formalism of Scrum with the casualism of the rest of the office:
| Scrum | Non-Scrum | |
|---|---|---|
| Workload | Prioritized backlog (sorted queue) locked during the Sprint. Lee just sent a high priority email. Scrum master will take care of it for me! | Multiple uncoordinated sources that can change at any time. Lee just sent a high priority email. Should I drop everything to work on it? |
| Workday | Defined by the sprint as a loop of predictable duration, where the team commits to a specific number of story points and a daily check-in meeting. I can completely focus on my stories and if I get blocked the scrum master will unblock meI only have one meeting a day, so I don’t have to rudely work on my laptop during that meeting. | Multiple uncoordinated open ended workstreams with soft deadlines that demand multitasking. I can’t focus completely on Lee’s request so it’s going to take days instead of an hour or two. I have so many meetings that I have to work on my laptop during each! I should also work during lunch and stay late but I’m feeling low energy and the kids need help with their home work. |
| Work unit | Story point: a well described task with a set business priority and expected labor value such that worker knows if they are spending too much or too little time. I tested, documented, and committed my code. My teams are doing a code review and will get back to me with feedback shortly. I know for myself that my work is on track, so I’ll start on my next story. | An email, a document, a presentation, a spread sheet, a list with no definition of done or labor value. I sent Lee a deck, but I had to bump my other work to complete it. Is it finished? Should we meet to review it? Will my boss get a call from an angry department head because of all the bumping? |
| Work team | Product owner, scrum master, and a specific set of developers. Nobody else is on the team. I know exactly who is working with me on this project. Lee is the EVP of XYZ but I don’t have to worry about that. The Scrum master will take care of it. | Probably the people on the email you just got. Is Lee working on this project of is Lee a stakeholder? Even Lee isn’t sure so to be safe just CC Lee on everything! The RACI is always out of date! |
We can easily see why the members of a Scrum are happier than the members of a Non-Scrum. Formalism brings clear boundaries so that employees know what they are doing, how well they are doing, and when they are finished. Non-Scrum team members might work all night on a project and find they failed because they didn’t work with the right info, or the right people, or the right priority. This kind of work-tragedy brings tears of frustration to the most experienced and valuable employees and leads to cynicism and other productivity busters that we managers are supposed to be managing out of the organization!
Because Scrum embraces and thrives on change the RACI is never out of date! Inside the sprint the priorities, the work to do, the due dates, the team members, and the estimated labor values do not change! Outside the sprint management brings everything the team has to do up to date. As a manager who prides himself on closing and finishing, I love the elegant efficiency of Scrum. I don’t know how other managers in other departments cope without Scrum.
We managers need not to fix Scrum but to fix ourselves. The dev team has become super effective. We, engineering management, product management, project management, and all the other managements need to catch up. We need formal systems of our own, similar to Scrum in the sense that they use data structures and algorithms to eliminate waste and accelerate work.