There are plenty of managers and software engineers frustrated with Scrum. In my opinion, the fundamental difference between managers and engineers appears to be unclear understanding of each other’s job.
Specifically, managers don’t know
What is the team’s charter and how to communicate it clearly to the team.
How does the team’s work align with company goals.
What kind of work-structure works for what kind of work. Tools in the management toolbox if you will. You can’t use the same tool for all kind of work.
Further, individual contributors often burn out because
They’ve misunderstood the underlying goal of their work.
They see the gap between management expectations and reality of work.
The daily work setup doesn’t set them up to succeed in their job.
Scrum plays a big role in perpetuating frustrations. This article attempts to bring some clarity to the software engineering work environment and why there is so much frustration with scrum.
This article talks about
- Various careers where scrum helps
- Various careers where scrum doesn’t work
- Where does software engineering fit in
- Some FAQs
Where in the world does scrum work?
Scrum works in very specific environments characterized by the following:
Well-defined output every day: Scrum helps when there is a well-defined output everyday. The work just repeats in a different combination the next day.
Assembly line output: Scrum helps when the output is more like an assembly line. Every day is a different permutation of a well-defined set of tasks.
Bite-sized tasks: Tasks can usually be bounded within short timeframes.
Well-defined roles: The team members have well-defined roles that interplay with each other.
Sequentiality in a day: The order of events during the day matters for output and for people(see point 3 about roles interplaying with each other)
Some examples of jobs that benefit from scrum
- A team of medical practitioners and nurses can discuss their day before jumping into procedures for the day. Here’s an example of a medical facility operation:
Well-defined output in a day: Patients receiving care in fixed time slots, care follow ups, restocking supplies for next day etc. all constitute a fixed well-defined output.
Assembly line output: Check in patient, fill forms, check insurance docs, doctor visit, follow up care.
Bite-sized tasks: Outside of exceptional circumstances, every activity is usually time-boxed.
Well-defined roles: Doctor, in-room nurses, check in assistants, administrative assistants, on-call doctors and nurses.
Sequentiality in a day: The sequence of operations is usually well-defined for every day. The service changes for every patient. A scrum meeting in the morning is enough to keep everyone aligned with changing conditions.
Every day, the order of operations, the equipment, the staffing, the methods may change. But the output is fixed and well-defined. Scrum simply helps align the team on the output regardless of changing conditions.
Note: The doctor’s work is sometimes not scrummable but the day-to-day operations are. Some speciality surgeon work cannot be planned at all.
2. A kitchen team in a restaurant of discussing tasks for the day among various roles. Here’s an example of kitchen operations:
Well-defined output in a day: Stocking, cleaning, preparing for business hours all constitute a well-defined output for the day.
Assembly line output: Stock up in the morning, clean up at noon, prepare in the afternoon, open for guests at 5 pm, run the service until 9 pm, dishwashing.
Bite-sized tasks: Outside of exceptional circumstances, every activity is usually time-boxed.
Well-defined roles: Chef, sous-chef, saucier, dishwasher, pantry supervisor.
Sequentiality in a day: The sequence of operations is usually well-defined for every day, just for different customers. A scrum meeting in the morning is enough to keep everyone aligned with changing conditions.
Every day, the order of operations, the ingredients, the staffing, the methods may change. But the output is fixed and well-defined. Scrum simply helps align the team on the output regardless of changing conditions.
3. A sports team discussing their training schedule for an upcoming game over the weekend. Here’s an example:
Well-defined output in a day: Warmup, coach driven exercises, a practice game, speciality training, pain therapy etc. all constitute a well-defined output for the day.
Assembly line output: Warmup, 3 hours of exercises, practice game, therapy are all usually planned to operate like an assembly line.
Bite-sized tasks: Outside of exceptional circumstances, every activity is usually time-boxed.
Well-defined roles: Head coach, offense coach, defense coach, fitness coach, physical therapist, scout all have well-defined roles interplaying with each other. Even players have well-defined roles so offense players generally would work with offense coaches.
Sequentiality in a day: The sequence of operations is usually well-defined for every day, just for different upcoming games. A scrum meeting in the morning is enough to keep everyone aligned with changing conditions.
Every day, the order of operations, the exact training drill, the staffing, the methods may change. But the output is fixed and well-defined. Scrum simply helps align the team on the output regardless of changing conditions.
There are plenty of other work situations that benefit from scrum. Here’s a non-exhaustive list:
- Factory assembly line
- Airport operations
- HR operations
- Marketing operations
- IT tickets (this is different from software engineering)
- An actual school (school timetables are a predefined scrum for kids)
Where does scrum not work?
Scrum does not work well in environments characterized by the following:
Undefined output every day: The work involves dealing with ambiguity. Daily status update appears like micromanagement.
No assembly line output: Every day is not a permutation of a well-defined set of tasks. Attempts to create a well-defined set of tasks fails because every task may need special consideration.
Long running tasks: The norm is for well-contained tasks to be long running — often over many days or months. Estimation is futile. Constant asks for estimation appears like micromanagement.
No well-defined roles: We are not talking about corporate titles. A role means an owner for a specific area of work for the business. And no, scrum master is a made up role because you are following scrum, not because the business needs that role. Wearing many hats is part of the job.
No sequentiality in a day: The order of events is usually not as important since dependency between roles is low. Daily order of events is pointless. Attempts to sequentialize everyday tasks appears like micromanagement.
Every day, the order of operations, the exact task, the staffing, the methods are very likely to change. And the output cannot be quantified. Scrum doesn’t do anything when output cannot be quantified.
Some examples of jobs that are hampered by scrum
- Lawyers working on a non-administrative legal case.
Undefined output every day: Working with law (especially trial) often produces no daily output. The output is spread over days, months and years interleaved with the occasional output. The deadlines and dates are often ambiguously set by law, government, judges or counter parties. If you ever tried to transact a legal case, you are already aware of the ambiguity and lack of daily progress. Lawyers have to deal with this every day. Daily status update appears like micromanagement.
No assembly line output: Most non-administrative law work cannot be assembly-lined. Attempts to create a well-defined set of tasks fails because every task may need special consideration.
Long running tasks: The norm is for well-contained tasks to be long running — often over many days or months. Estimation is futile. Constant asks for estimation appears like micromanagement.
No well-defined roles: While lawyers may have corporate titles, an attorney with a case only has a small set of people to work with. It is the attorney’s prerogative to create some roles for the team and distribute work. Often attorneys work alone on a case. A staff is not necessary and not a guarantee. Wearing many hats is part of the job.
No sequentiality in a day: The order of events is usually not as important since different members working on a case can operate independently. Daily order of events is pointless. Attempts to sequentialize everyday tasks appears like micromanagement.
Every day, the order of operations, the exact task, the staffing, the methods are very likely to change. And the output cannot be quantified. Scrum doesn’t do anything when output cannot be quantified.
2. Real estate brokers
Undefined output every day: Real estate brokers can never clearly define what the next few days may look like. If you ever tried to transact a single property, you are already aware of the ambiguity and lack of daily progress. Imagine the same ambiguity over multiple properties and that is the job or real estate brokers. Daily status update appears like micromanagement.
No assembly line output: Most real-estate work cannot be assembly lined since the input funnel itself cannot be assembly lined. Attempts to create a well-defined set of tasks fails because every task may need special consideration.
Long running tasks: The norm is for transactions to take weeks/months of navigation of work. Estimation is futile. Constant asks for estimation appears like micromanagement.
No well-defined roles: Even if there is a team of real-estate brokers, an individual broker often needs to wear many hats — sometimes all at the same time. Wearing many hats is part of the job.
No sequentiality in a day: The order of events is usually not as important since different real estate transactions are in different stages. Daily order of events is pointless. Attempts to sequentialize everyday tasks appears like micromanagement.
Every day, the order of operations, the exact task, the staffing, the methods are very likely to change. And the output cannot be quantified. Scrum doesn’t do anything when output cannot be quantified.
3. Detectives and Investigators
Undefined output every day: This should be intuitive but investigations are undefined. There is no guarantee that there will be an output every day. Daily status update appears like micromanagement.
No assembly line output: The investigation can go in any direction. There is no way to create a permutation of tasks. You can create a run-book but not a permutation of all possible set of work. Attempts to create a well-defined set of tasks fails because every task may need special consideration.
Long running tasks: The norm is for investigates to take weeks/months of navigation. Estimation is futile. Constant asks for estimation appears like micromanagement.
No well-defined roles: Even in a team of investigators, people need to wear many hats. You can’t abandon a financial crimes investigation just because you are only familiar with California law and not with NY law. Wearing many hats is part of the job.
No sequentiality in a day: The order of events is usually not as important since different cases are different. Daily order of events is pointless. Attempts to sequentialize everyday tasks appears like micromanagement.
Every day, the order of operations, the exact task, the staffing, the methods are very likely to change. And the output cannot be quantified. Scrum doesn’t do anything when output cannot be quantified.
In fact, here is a list of all careers by freedom to make decisions: https://www.onetonline.org/find/descriptor/result/4.C.3.a.4?a=1
Bonus points for you if you figure out where software engineering lies.
What kind of job is software engineering?
Undefined output every day: Software engineering is a combination of learning, investigation, case studies, gamedays and transactions. There is no guarantee that there will be an output every day. Daily status update appears like micromanagement.
No assembly line output: There are no fixed permutation of tasks to pick and choose from. Attempts to create a well-defined set of tasks fails because every task may need special consideration.
Long running tasks: The norm is for investigates to take weeks/months of navigation, solutions to be hairy, tech stacks to be complex and infrastructure to just not work when needed. Estimation is futile. Constant asks for estimation appears like micromanagement.
No well-defined roles: Even in a team of software engineers, people need to wear many hats. You can’t abandon a slow query investigation just because you are only familiar with react. You can’t abandon a feature rollout just because the sales team doesn’t know what they need. Wearing many hats is part of the job.
No sequentiality in a day: The order of events is usually not as important since problems are different and solutions to them will be different. Daily order of events is pointless. Attempts to sequentialize everyday tasks appears like micromanagement.
Every day, the order of operations, the exact task, the staffing, the methods are very likely to change. And the output cannot be quantified. Scrum doesn’t do anything when output cannot be quantified.
This brings us to Scrum
In my opinion, scrum is a perverted implementation of the agile philosophy. Detectives are agile, Real estate brokers are agile, Lawyers are agile. Scrum is for assembly-line work. Software engineers are being forced to not be agile without a scrum process.
FAQs
But but but…without scrum
Q. How can management track work?
Use modern tools like Jira. Encourage your team to post asynchronous updates on tickets. You don’t need to hear status every day.
Q. What about status updates?
Status updates can be weekly/biweekly. It can be written bullet points. Unless the manager has anything to share with the team, there is no need for status update meetings — certainly not every day.
The best status update meetings are a team weekly meeting where team members
- Can have some banter
- Do demos, reviews or discussions
- The manager uses that time to broadcast and discuss gossip from outside the team.
- Pro tip: Status meetings are meant for upwards, downwards and sideways communication — not just for the manager to farm data.
Q. How would the team get rapid feedback if not for daily standup?
A daily standup is already NOT rapid. Create a culture of openness where the team can ask questions asynchronously and without penalty. There is no need to wait for the next day to figure something out if an engineer is blocked.
Q. But how will the team work together as a team?
See text on No well-defined roles above.
Q. What about shy engineers who don’t reach out?
They won’t reach out in standup either.
Q. What about backlog grooming, sprint planning and working together as a team?
Unless every single member of the team is working on the same output, a singular goal for a sprint will not help achieve anything. Working together as a team does not require working in lockstep. Work can happen independently to move the goals of the team ahead.
Q. What about estimation of work?
See text on Long Running Tasks above.
Q. But I still need some estimate, as a manager
You need to be a skilled engineer yourself to make such estimates. This would involve you (the manager) to understand the problem space, talk to various stakeholders and come up with an estimate yourself.
Is this a lot of work? You bet.
Q. Where will team members raise concerns about dysfunctional tools or other teams?
A biweekly retrospective is a ceremony that helps. It can also be combined into the weekly status update meeting. Raising dysfunctional tooling or other team problems in a standup meeting is not saving as much time because the manager is not likely to jump on the problem right away.
Q. What about other scrum ceremonies?
Ask yourself how scrum ceremonies help move the work forward. There is a good chance that the ceremonies are not helping any real work and are just another meeting.
Q. How about camaraderie, especially during remote work?
I admit that camaraderie is an important part of software engineering teams.
But stand-ups help in building forced camaraderie, just like middle school makes forced friendships out of sitting in a classroom. Real camaraderie is built from working on entire projects together. Can 10 people work together on the same software task? Even middle school kids know that the answer is no.
Further, there are better ways to build camaraderie such as team events, demos, tech talks and remote happy hours.
Q. But people can’t remain isolated everyday
No one is asking engineers to remain isolated. If they need to chat about something with someone, use a modern IM tool to ping them for a quick chat or set up something on a calendar and chat over video.
Back in the day, before the remote world, people used to ping each other for coffee chats and bubble tea trips all the time. An important aspect of camaraderie is that it must not be forced — often must be on a need to do basis. Forcing an interaction with standup is futile and engineers can see through it.
Q. I want more processes
No. Engineers thrive with less process and more room creativity. Some processes help — such as task trackers but those should be lightweight and asynchronous. Daily standups are very heavyweight and eat a lot of human time.
More meetings == less actual output. More ceremonies == less actual work done.
Q. How can I, as a manager, keep tabs on the work? What if my engineers just slack off?
Ask yourself (the manager) if your job is supervisory or inspirational?
If your job is supervisory, your reports will pick up on your supervisory attitude and will slack off and lie anyway. Keeping tabs just keeps the lies rolling over and over.
If your job is inspirational, you wouldn’t need to keep tabs. Inspired engineers will automatically produce things that will positively surprise you.
Q. How can I, as a manager, measure work and offer bonuses/pip people?
I am not sure why you became a manager without understanding what your job entails.
Q. What about stakeholder conversations?
They can happen in other meetings. They don’t need to happen in sprint planning or daily standup. In fact, stakeholders are often unprepared and “will get back to you later” anyway.
In conclusion
Hopefully, this article explains what kind of work software engineering. The hope is that this serves as a rough guideline for managers and process enthusiasts — to make better use of software engineer time.
If there’s any takeaway from this article, it’s that
Management can be done without scrum.
Do you have any more unanswered questions about engineering teams and scrum? Feel free to post them in the comments section and I’ll be happy to share my thoughts.
Discussion on hacker news https://news.ycombinator.com/item?id=30236996
