But yes, a team of people that understand the business, and can prioritize well without needing someone to do it all for them, scrum just slows the team down. I've seen it happen multiple times in my career, and sometimes succeeded at either undoing the change, or making the jira-based work basically fictional.
"The process failed because you didn't have enough project managers on board"
No the process failed because it was fucking shit and everyone went somewhere else.
The only good thing heavy processes are for are propping up employment statistics.
The amount of dancing required for the sake of management in this industry is just insane.
If you don't want to have to talk to customers, which only one developer who I've ever worked with has actually wanted to do, you need a way to equip someone else to do so.
Same thing if you want to keep your investors happy, your counterparts in other departments informed of when they need to have the hardware to pair up with your software ready, etc.
There's definitely such a thing as too much overhead, but developers who just do the things they are interested in without considering that they are part of a larger business are the other side of the coin that you're describing.
1. If other departments need metrics/insights/visibility, why don't they go collect it? As a PM, go collect that information yourself and deliver it to stakeholders? Why does everything need to be done by engineers?
2. When engineers get measured, evaluated and pitted against each other using these activities, it breaks camaraderie. We don't enjoy these activities because we see through the management practices of rating people based on the number of proverbial TPS reports or the quality of the cover sheet or the number of story points completed - none of which are actually important to the success of business but very important to the manager who will just recycle them upwards. Do you really think people are motivated to do this meaningless work?
I love the movie, but damn it hits close to home and I never know if I should laugh or cry.
Most of us are not.
If scrum isn't working for you and you're productive, do more of that.
If what you have isn't working, and scrum might help. Do that.
That's the point. Don't break something just because others are doing it.
did they revert back to the old method, did it deteriorate so fast there was no way to stop it, was the team not very important
what happened ?
i'm obviously turning this into a hypothetical
Rule number 1: management is never wrong. The progress did not slow down.
They said that we didn't measure the work before, so they had no visibility into how much the team does. But after introducing scrum, they were very happy to see that the team usually delivered around 20 story points per sprint, while the other teams in the company did around 10.
In my view, if we estimated tickets in old process as we did after introducing scrum, we would have been delivering around 60 points in two weeks through old process.
Their goal was never increased productivity and developer hapiness. It was literally what they said "introducing scrum and bringing in a scrum master". Their purpose is to add and manage processes (bureucratic layers) and increase their dependants.
Middle managers will always increase headcount so that they eventually can become directors. Oldest game in business.
So .... the one you were dealing with was just an average bullshitter pretending to do scrum.
Either way, it was awful, and it was looked down upon to try and find some peace and quiet to actually get things done.
I get that this often doesn't work because individuals don't really grasp their function properly and don't defend or don't prioritise and then that part of the scheme cannot work. Sometimes the company structure makes the POs too scared to standup. IMO that would be a problem without scrum.
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
Oh wait till management finds engineers to scapegoat for their own decisions. If there is one truth about management, it is that they cannot accept "I told you so" from their reports.
So to exaggerate a little bit, not accepting "I told you so" from their reports is directly required to keep paying their mortgage and feeding their children. It's not weird that they get upset when you endanger their livelihood. OP has got the right idea and is just being zen about it IMO.
Indeed. I've been thinking about shifting back into management after a couple years as an individual contributor (playing an instrument is fun, but so is conducting a well functioning orchestra). In this space, aligning with stereotypes has become very important in the past decade or so.
Perhaps we need to reduce the number of levels, replace managers with technical leaders whose incentives are aligned with the needs of the business. Offload all grunt paper work to an executive assistant.
No need for EM1, EM2, EM3, Director, Sr Director, VP, SVP, SSVP nonsense.
In my experience, the only time a company does well with structures is when there are fewer levels in the org chart and when the C-Suite penalizes management before ICs.
Doesn't happen very often though.
Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement.
But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master and no P.O., and gave the Scrum Master some or all of the P.O. duties. Even as weakly prescriptive as the current Scrum Guide is, that's still not real Scrum.
(Moreover, most places that purport to do Scrum also purport to do Agile, and having a bottleneck between the team and client is even more explicitly not Agile than it is not Scrum.)
Which is not to say your scenario isn’t a valid illustration of problems with Scrum (or Agile) in terms of the (largely cargo-cult) common behavior going under the name.
Its just that in terms of clarity of discussion of what practices should be adopted, its worth noting that the problems being identified are with practices which the Scrum Guide (at the organizational level) and Agile Manifesto (and the broad practice level) are pretty explicitly directed against. Not just in terms of the communication bottleneck but also things like:
> tickets taking exactly one sprint to complete
This seems to be confusing increments or Sprint Backlog items (for which the dev team is responaible for making from Product Backlog items) with Product Backlog items that the P.O. is responsible for (and also Product Backlog items with client tickets, though the Scrum Guide doesn't explicitly discuss client tickets at all — in fact, it mentions customers only once — and so doesn’t explicitly distinguish them from Product Backlog items. The P.O. is free to, and responsible for, structure Product Backlog items optimally based on achieving customer goals, which is almost never realistically going to be 1:1 with tickets.)
EDIT: I want to make extra clear that I am neither disagreeing with the criticism of “Scrum as the thing that I am likely to have imposed on me if my workplace says they are doing Scrum” nor arguing that the Scrum Guide (or Agile Manifesto and principals) are anything like perfect edicts that can only be failed but never fail.
I am just saying it is important to recognize the difference between “this failure is caused by a set of practices a workplace adopted under the label ‘Scrum’” and “this failure is caused by adopting the practices described in the Scrum Guide”, eepecially if you are interested in what good practices might be.
In the same way, I don't particularly care if Scrum fails because people consistently fail to implement it "right" or if it fails because it's a flawed concept at its heart. Either way, odds are that my team will suffer if we introduce Scrum: if Scrum isn't fundamentally flawed, it's still hubris to assume that we'll be the team that finally gets it right.
[0]
> “Listen, if tomorrow we pulled into Biren and someone told you there were shamble-men in the woods, would you believe them?” My father shook his head.
> “What if two people told you?” Another shake.
> Ben leaned forward on his stump. “What if a dozen people told you, with perfect earnestness, that shamble-men were out in the fields, eating—”
> “Of course I wouldn’t believe them,” my father said, irritated. “It’s ridiculous.”
> “Of course it is,” Ben agreed, raising a finger. “But the real question is this: Would you go into the woods?”
“Steer clear of things called Scrum” is a very limited guide to how to develop software, actually figuring out what the methodological pitfalls are and addressing them is something that is, I would submit, worth pursuing in more detail, especially for people who have some influence over substantive development methodology choices, rather than only having a choice of whether or not to avoid some place that is imposing a thing that they call “Scrum”. (And, really, you should probably steer clear of any place where being in the dev team gives you no input on substantive methodological decisions irrespective of whether what is imposed is called “Scrum”.)
I am suggesting that calling it Scrum will increase your risk of failure, and you'll likely be better off choosing a completely different methodology that has more consistency in implementation and a higher success rate.
By all means let's dig into what specific details of the implemented methodologies work well and which don't! But taking the output of that process and calling it "Real Scrum™" will just lead to further confusion.
I’m not saying “Real Scrum™” should be the name of the output. I’m saying that diagnosing the problem is obscured by not distinguishing between “what is in the Scrum Guide” and “what someone is doing and calling Scrum”, especially as the latter can be a diversity of mutually incompatible approaches.
Much less TLDRish, but zooming out to take a broader perspective:
There seems to be an intense agreement with both of the following statements:
1. The practices in the industry that the people imposing them call “Scrum” are often quite bad, and
2. The practices in the industry that the people imposing them call “Scrum” often bear very little relationship to the methodology laid out in any version of the Scrum Guide.
Apparently because consensus is a bad thing and there aren’t enough real issues to argue about, some people who agree on points #1 and #2 seem to have squared off into a weird tribal battle over whether “Scrum” is bad due to #1 specifically that mostly turns on whether or not the One True Meaning of “Scrum”” is the thing they agree is very often bad in #1 or the thing they agree that thing differ differs from in #2. My position is that this is mostly silly, especially since there are very few contexts where both of those things are meaningful to consider: the first is so inconsistent in terms of actual practices that it is useless describe as a single thing in the context of concrete development practice, though it may be interesting to discuss as an industry cultural phenomenon, whereas particular practices or combinations of practices within its ambit can be discussed more productively when the focus is on concrete development practice; the second is specific enough to be useful to discuss in the context of concrete development practices, but not much else, except maybe in terms of its historical role in relation to the cultural phenomenon. With a little care to being clear what they are talking about and the what it is people are looking for from a discussion, the whole semantic side-debate can be avoided.
I appreciate you being willing to articulate an unpopular opinion :-)
Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple - no one in your team was open to adopting scrum so it failed. That's fine but it's not the fault of scrum rather than the company management.
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
If you go into something with the intention of 'this sucks' and then do not even want to make it work would it not reason that it probably will fail?
Scrum usually fails because people become enamored with the process instead of thinking about what that process is for. Layering on more and more of it because something is not working. Until you are busy with 40% of your time just managing scrum. Something in scrum not working throw it out. Do not double down and add more.
we can rephrase this as "the serum didn't work because you didn't have faith in it."
But the GP point is valid. not every iteration can be blamed on "scrum" anymore than anything bad that happens in life can be blamed on Satan. If people want it to fail, they can make it fail.
But that said, to slightly counter my own point: I think that demonstrates a weakness with Scrum. If people following the system (even malicous compliance) can make it fail, then the system is flawed. It obviously sucks for those people or they wouldn't have a bad attitude about it. For example, Scrum likes to pretend that all engineers are fungible, but this is clearly wrong and a big problem with the system.
People are stuck in their ways and don't actually want to try anything new. That's why management always fails- you can't manage people.
Those damn people. Business would go so much better if you didn't have to hire them /s
How do you know no one was open to trying it? I specifically mentioned that I personally objected to scrum, but wrote nothing about other people.
What happened in fact was that people initially really tried their best ti cooperate, but it simply didn't work very well and crippled the team.
And that was your big mistake. Those are real concerns, but those things are abstract and non-quantifiable. The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.
In my experience even the dumbest and thick-headed management can understand that. I've always imagined if it didn't I could ask to hire more people to compensate for the time lost, but I never had to resort to that.
Granted, you still end up with a mutilated scrum at the end. But if you mutilate it right, you can fit your pre-scrum work process into the terminology of a mutilated scrum.
I do not understand how this is possible.
* Sprint planning: 2 hours
* Sprint review: 1 hour
* Sprint retro: 1 hour
* Daily stand-up: 15min / day
On a 2 week sprint, 80 hours, that's 5.5 hours spent on ceremonies. That's ~7%.
What are you doing that it could ever take _half_ of total work time and how will you convince management that you aren't completely fucking up scrum?
Yes, we weren't doing "scrum" right, but like communism, no one does it right.
[1] The silliness didn't start until new management took over.
[2] The term "team lead" meant "manager". I didn't get the memo.
[3] I was regularly talking to him at least once a week. He didn't want me to leave the company and to give him time.
* pre-planning - 30m
* planning - 30m
* refinement - 90m
* ultra refinement - 90m
* retro - 60m
It's laughable.
Week 1: One whole day for demo, retro, planning, commitment. But because the scrum master had to "build" a sprint and couldn't do that without knowing the size of tickets, there were two morning meetings every week to "analyse" tickets. So two mornings for "analysis" to produce point estimates for tickets.
Week 2: Also two mornings for "analysis".
So 3 days out of the 10 day sprint, so 30% time spent on Scrum.
Plus standups, they were at 10am so 9am-10am nobody did anything (as judged by the number of PRs and comments and Slack activity) so that's an hour plus the time for standup every single day, so I guess the work day started 10:30am on those days which weren't scrum days or scrum mornings.
Plus the scrum "analysis" meetings were in the morning as it was generally accepted everyone was too tired in the afternoon to to those meetings. So what that actually meant imho was that programming was a low-importance activity that could be done when tired, after the actual work of Scrum had been completed.
Maybe that's insanity, I mean I certainly thought so, but these things do happen.
But, what little progress there was, was easily measured. That seems to be the important part.
Lunatics run this asylum.
In reality we don't have good software development because people at some level or another don't want to do the things that make it possible. They're always going to pretend they care but do what suits them.
It can be from the most basic thing: the customer doesn't want to pay what it really costs to get something good but can be made to pay for something that's going to turn out to be crap in the end.
If you're confessing that it's contrary to human nature and/or the engineering thought process, then I humbly accept your concession in this debate.
Then that is what scrum is.
I know how it worked and why every team I've been on since has not been able to make it work and it all boils down to: 1) internal sabotage - an influential developer does everything they can to shit on it. 2) Management interference - developers could not change the things we needed to change to make it fit our circumstances.
Oh, that's very easy. Business meetings can take more than expected in the best of cases, and the various dysfunctions inherent in scrum only add to that.
Here's a fairly obvious example - scrum encourages you to have a lot of management. At minimum a team needs a product owner, a team lead and a scrum master (and if you merge those positions you aren't "doing scrum properly"). Because there are so many managers, each is under pressure to prove they add value. How do they prove that? By providing valuable input in the various ceremonies scrum requires. Hours of it.
And sometimes they add so much value it can't be contained in the normal flow of scrum meetings (or rather, the meetings can't be contained in the course of a work day), so more meetings have to be created.
The 13% takes into account the time tax of context switching. 18% if we consider only (at best) 6 hours per day and meetings are taking away from that high productivity time (which is to say a greater proportion of time is spent around the coffee maker and not coding)
To go into detail, there is a tax to every meeting. With 13 scrum meetings this adds up fast. For me, as a remote worker, I stop everything 5 minutes before or else (for example) 1:57 is going to suddenly turn into 2:03 and then I'm late. Recovering from a meeting takes me about 10 minutes (plenty of resources state it takes 25 minutes to get back into a flow state once interrupted).
Thus, for me, the meeting tax of scrum meetings alone is 13*15 = 195 minutes. Further, there is a conflict as projects have their own required meetings (if the scrum meetings are the only meetings, then seemingly the team is just talking once a day and then not again - that sounds bad! So yeah, there are other meetings too).
Further, not all 80 hours are equal. Software development is a highly creative field, it's not an assembly line with interchangeable parts. If you have your developers in office for 90 hours instead of 80 you're not going to get 10% more on your story point velocity. Similar for 70 hours vs 80, eventually there is a point of diminishing returns.
By measures of how long I can pair program with someone, 5 hours is a pretty upper limit on how long I can stay in a high productivity state for one day. Time spent in meetings can take away from that high productivity.
Let's say a person can generously be in a high productivity state for 6 hours per day and that meetings take away from that time, then we are very reasonably at 10.75/60 => ~18%*
*I'll emphasizes we are talking scrum meetings only, and still not even taking into account prep time for the scrum meetings
[1] https://resources.scrumalliance.org/Article/scrum-events
"The general rule of thumb is to allow two hours of sprint planning for every one week of sprint length. That means teams should timebox sprint planning to four hours for a two-week sprint and eight hours for a one-month sprint."
It is a bit sad, but that is my experience as well. I had one good manager in my 12 years experience. I had to work around the rest.
Nobody usually wants this.
For developers scrum is actually quite nice. The main success metric is predictability, i.e. the team is held accountable for delivering the sprint successfully. Which means you're supposed to be left alone while the sprint is ongoing.
Some bug? Pfft, if not critical, will maybe take it next sprint.
Finance needs a new report, pronto? Sure, let's talk about business value for priorization. And earliest next sprint anyway.
CEO has a crazy idea that he wants somebody to pull off? Sure, but please talk to Product.
What do you mean, you need more story points delivered per sprint?
The main issue is there are actually people that thrive in this kind of bureaucrazy. I've seen a number of 20-something POs burning themselves over these shitty processes.
The difference is when people do communism, they actually follow the recipe (and failing), i.e. central planning, one-party state, state ownership, etc.
But when you read about people complaining about Scrum, it doesn't look like what the Scrum training taught nor the Scrum guide.
(This reminds me of a time when a manager pulled all the teams into a room, then pulled out all the Scrum terminologies and say "now we're going to have a meeting to decide what we want them to mean".)
In situations like this, one strategy I have used (not for Scrum, but for people who want to tinker with shit for the sake of tinkering) is to say: "Great, we welcome experimentation, this is really cool. What will we measure to decide whether this change is improving our process, and how long will the initial round of experiments last?"
However, the management insisted that we adopt Scrum and get a Scrum Master to help us.
I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).
The management response was: "that is not real Scrum, you had bad experiences because you weren't doing it right previously".
After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time.
Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)