How to distort Scrum until it no longer works(lucasfcosta.com)
lucasfcosta.com
How to distort Scrum until it no longer works
https://lucasfcosta.com/2022/10/04/distorting-scrum.html
173 comments
I swear someone created SAFe as a joke by just taking the strawman waterfall diagram and adding scrum words, and sprinkle in a few more useless people for good measure. It also ensures that anyone that needs to actually talk or work together is far to busy to achieve progress.
I think that's pretty close except for the joke part.
The early-days problem with the Agile movement was that it promised actual change by empowering the line workers to actually get things done for users by shipping early and often. That was an intolerable threat to industrial-age managerial power structures, to which waterfall is an ideal that justifies lots of management control.
But since then it's been gradually watered down and tamed. Scrum's certification scam was the start of that, and SAFe strikes me as the end result: lots of Agile jargon with the rigidity of waterfall, providing long-term safety to managers in large companies everywhere.
I wrote about this dynamic before SAFe existed, but it seems to fit right in with what I described: https://williampietri.com/writing/2011/agiles-second-chasm-a...
The early-days problem with the Agile movement was that it promised actual change by empowering the line workers to actually get things done for users by shipping early and often. That was an intolerable threat to industrial-age managerial power structures, to which waterfall is an ideal that justifies lots of management control.
But since then it's been gradually watered down and tamed. Scrum's certification scam was the start of that, and SAFe strikes me as the end result: lots of Agile jargon with the rigidity of waterfall, providing long-term safety to managers in large companies everywhere.
I wrote about this dynamic before SAFe existed, but it seems to fit right in with what I described: https://williampietri.com/writing/2011/agiles-second-chasm-a...
You hit the nail on the head and posted just before I would've. The only thing I can add to that directly here is this:
Just look at the acronym itself!
It tells those managers at Big Corp that it is finally safe to implement Agile!
Just look at the acronym itself!
It tells those managers at Big Corp that it is finally safe to implement Agile!
You are exactly correct, except:
1) it was RUP, not waterfall (RUP is basically many waterfalls in parallel)
2) they were dead fucking serious.
1) it was RUP, not waterfall (RUP is basically many waterfalls in parallel)
2) they were dead fucking serious.
Ugh, SAFe. My group has been trying to implement this methodology for well over a year. My observations:
* Program increment planning is absolutely painful. Three full days of meetings, and rarely do the stakeholders come with fully refined features. And, typically, what plan emerges is changed within two weeks because of emergencies or an executive seeing a shiny bauble we absolutely need to have.
* Two week sprints seem too short, at least for a group working in a highly regulated industry that requires a ton of manual testing and paperwork. I will also admit that we likely have trouble writing appropriately sized stories, but part of that circles back to the need for massive validation efforts.
* We suffer from lots of turnover in product management (and perhaps too many product managers). If a PM leaves, their features tend to die on the vine, even if some executive has decided they are important. That leaves us with a massive backlog.
* Program increment planning is absolutely painful. Three full days of meetings, and rarely do the stakeholders come with fully refined features. And, typically, what plan emerges is changed within two weeks because of emergencies or an executive seeing a shiny bauble we absolutely need to have.
* Two week sprints seem too short, at least for a group working in a highly regulated industry that requires a ton of manual testing and paperwork. I will also admit that we likely have trouble writing appropriately sized stories, but part of that circles back to the need for massive validation efforts.
* We suffer from lots of turnover in product management (and perhaps too many product managers). If a PM leaves, their features tend to die on the vine, even if some executive has decided they are important. That leaves us with a massive backlog.
> highly regulated industry that requires a ton of manual testing and paperwork
This describes every industry for a company I've seen SAFe at.
Or, in other words, SAFe is:
{how do we say we're doing Agile?} + {how do we avoid changing any of our regulatory compliance pipelines?} = {business as usual} + {a bunch of extra useless Agile theater}
This describes every industry for a company I've seen SAFe at.
Or, in other words, SAFe is:
{how do we say we're doing Agile?} + {how do we avoid changing any of our regulatory compliance pipelines?} = {business as usual} + {a bunch of extra useless Agile theater}
Yep. I'd explicitly never work at a place that implemented SAFE. Reading this article felt like someone describing the process at a previous employer. Just nailed it with all planning right at the intersection of useless, time consuming, and painful.
We do standups three times a week, and I will flat-out hang up Zoom once we hit 15 minutes. I find standups helpful, but not if they're longer than 15 minutes!
My previous workplace was only half as bad as you describe, and I left, very disillusioned and upset. When I read the article, most fit with what I went through in that company. By now the company is bankrupt. I'm very happy at my current workplace. My advice: asap search&find another employer.
It's at its worst when the company can't go bankrupt: e.g. because they're in the healthcare insurance space.
Do you guys also use scrum poker? I always found that one of the most hilarious exercises.
More like humiliating. And like most Scrum terms, absolutely zero to do with poker.
They should rename it "Scrum Auction", as all it ever devolves into is some morons overselling their capacity and shooting themselves in the foot regarding any chance at cleaning the codebase.
They should rename it "Scrum Auction", as all it ever devolves into is some morons overselling their capacity and shooting themselves in the foot regarding any chance at cleaning the codebase.
Create very small tasks, that way you all will be super productive.
Does it ever occur to Scrum people that it’s not a good idea to spend your entire life in a mad state of sprinting? Marathon runners don’t sprint 100m, then sprint another 100m, repeatedly, to cover the distance of a race.
That's always bugged me as a broken analogy, too.
In college it was an extremely common aphorism "It's a marathon, not a sprint" as reminder to sustainably pace yourself and it has always seemed like Scrum originators had heard that phrase and gotten it exactly backward and it stuck.
In marathon pacing analogy terms, "Split" would be the more accurate term. Though I know a lot of people don't think that sounds as good as "Sprint" does. Personally, I've often preferred just calling them "Fortnights" as an accurate description for "two-week process" (and a useful callback to long watches in older times). (Though the game "Fortnite" has confused that term a bit recently among the youth. "What does this have to do with the shooter?" Sigh.)
In college it was an extremely common aphorism "It's a marathon, not a sprint" as reminder to sustainably pace yourself and it has always seemed like Scrum originators had heard that phrase and gotten it exactly backward and it stuck.
In marathon pacing analogy terms, "Split" would be the more accurate term. Though I know a lot of people don't think that sounds as good as "Sprint" does. Personally, I've often preferred just calling them "Fortnights" as an accurate description for "two-week process" (and a useful callback to long watches in older times). (Though the game "Fortnite" has confused that term a bit recently among the youth. "What does this have to do with the shooter?" Sigh.)
The point of a sprint is that you shouldn’t sustain your pace. You should reach a given point and stop.
The problem is that far to many programmers “sustain their pace” by implementing 1/3 of 4 things in 2 weeks instead of finishing a single thing completely. That’s not a problem in waterfall if your 100% sure that those 4 things will have to be complete over the course of 30weeks, but in scrum you are trying to deliver small increments to your customer to have them validated so you don’t spend 30 weeks on something that ends up not meeting client expectations(even if it does meet specified requirements exactly)
The problem is that far to many programmers “sustain their pace” by implementing 1/3 of 4 things in 2 weeks instead of finishing a single thing completely. That’s not a problem in waterfall if your 100% sure that those 4 things will have to be complete over the course of 30weeks, but in scrum you are trying to deliver small increments to your customer to have them validated so you don’t spend 30 weeks on something that ends up not meeting client expectations(even if it does meet specified requirements exactly)
Of course, Scrum is concerned with sustainable pacing: avoiding end of waterfall "crunch", setting estimation horizons that are sustainable (developers are terrible at estimating things in two-week time periods, but developers have an impossible time estimating anything beyond that), modest attempts at preventing burn out, even regular "small increment" delivery is itself an attempt at sustainable pacing (rather than big blow out quarterly releases, for instance).
> You should reach a given point and stop.
"And stop"? I would almost pay to see a Scrum team that allows front-loading stories and pays for time off if they are completed ahead of sprint deadlines. That sounds like an incredible unicorn.
There's no stopping in Scrum. There's always "pick a new story off the backlog" and there's always an infinite backlog to pick from, in my experience.
> You should reach a given point and stop.
"And stop"? I would almost pay to see a Scrum team that allows front-loading stories and pays for time off if they are completed ahead of sprint deadlines. That sounds like an incredible unicorn.
There's no stopping in Scrum. There's always "pick a new story off the backlog" and there's always an infinite backlog to pick from, in my experience.
Maybe a 'lap'.
The original legendary Marathon was a run between the cities of Marathon and Athens. No loops in that course to consider "a lap". 'Lap' doesn't fit the analogy quite right either. (Some modern street Marathons do use lapping courses today, but that is more for simplifying the logistics of getting people back to their cars and such from the finish line as anything proper to the "form" of a Marathon.)
> The original legendary Marathon was a run between the cities of Marathon and Athens.
In that story the messenger running the marathon collapses and dies soon after coming back to Athens.
https://en.wikipedia.org/wiki/Pheidippides
Maybe the analogy is not so different :)
In that story the messenger running the marathon collapses and dies soon after coming back to Athens.
https://en.wikipedia.org/wiki/Pheidippides
Maybe the analogy is not so different :)
> The original legendary Marathon was a run between the cities of Marathon and Athens.
Why's it have to be a marathon in your mind? Any race - doesn't have to be that literal.
Why's it have to be a marathon in your mind? Any race - doesn't have to be that literal.
The reason for picking a marathon as the specific analogy, which Scrum intended to do (but got backwards) is that:
1) It's a (very) long haul. Pacing yourself is mandatory. (In most of the legends of the first marathon, the runner collapsed to the death after delivering his message in Athens.)
2) It's explicitly an A to B with a long-term goal in mind. From software product idea to finished software, in theory. (This part of the Scrum analogy has largely been forgotten/ignored/killed of course in the modern view of software as a constant Ship of Theseus that is never finished and always has infinite backlog.)
3) Pacing yourself while running a marathon consists of breaking your run into smaller time boxes. Most runners do plan specific paces for different "splits" within a marathon. Some runners pay coaches lots of money to try to come up with these plans. (Again, here Scrum screwed up the analogy by using the exact wrong term, "Sprint": a short fast race where pace is as fast as possible, and no need to think about "the next mile" after the "Sprint".)
4) The type of race doesn't change in a marathon. A triathlon might make a similarly good long haul project development metaphor if you have to shift entirely different contexts every so often (swimming, biking, running), but software development doesn't (necessarily) have drastic context switches like that. "Mile to mile" ("week to week") in software development you are still largely doing the same tasks.
I kind of agree with the Scrum originators that the marathon was a good analogy for software development projects. I just wish they hadn't immediately broken the analogy by getting fundamentals wrong like the relationship between Marathons and Sprints.
(ETA: I'm not myself a runner. Most of what I know is from siblings and friends and trying to be a good sideline supporter.)
1) It's a (very) long haul. Pacing yourself is mandatory. (In most of the legends of the first marathon, the runner collapsed to the death after delivering his message in Athens.)
2) It's explicitly an A to B with a long-term goal in mind. From software product idea to finished software, in theory. (This part of the Scrum analogy has largely been forgotten/ignored/killed of course in the modern view of software as a constant Ship of Theseus that is never finished and always has infinite backlog.)
3) Pacing yourself while running a marathon consists of breaking your run into smaller time boxes. Most runners do plan specific paces for different "splits" within a marathon. Some runners pay coaches lots of money to try to come up with these plans. (Again, here Scrum screwed up the analogy by using the exact wrong term, "Sprint": a short fast race where pace is as fast as possible, and no need to think about "the next mile" after the "Sprint".)
4) The type of race doesn't change in a marathon. A triathlon might make a similarly good long haul project development metaphor if you have to shift entirely different contexts every so often (swimming, biking, running), but software development doesn't (necessarily) have drastic context switches like that. "Mile to mile" ("week to week") in software development you are still largely doing the same tasks.
I kind of agree with the Scrum originators that the marathon was a good analogy for software development projects. I just wish they hadn't immediately broken the analogy by getting fundamentals wrong like the relationship between Marathons and Sprints.
(ETA: I'm not myself a runner. Most of what I know is from siblings and friends and trying to be a good sideline supporter.)
As someone recently said it here, the difference between software development and marathon is that marathon runners know their destination.
I'm tired of pretending software developers don't know their destination.
If you started making a task-tracking app, and after all the work for scrum end up building a video game instead, something has gone terribly wrong.
If you started making a task-tracking app, and after all the work for scrum end up building a video game instead, something has gone terribly wrong.
I think experiences vary greatly based on company and domain. I work on a team supporting features for an app that is used by tens of thousands of people every day. Yet, what we plan to produce at the beginning of the quarter rarely matches what we actually produce. Example: my team spent months working to integrate our app with a new data gateway service. We were, I dunno, 75% of the way there when executives decided the data gateway should not be used (this months after they said this same gateway was the future of the company). So, I'm not pretending when I say sometimes, I don't know my destination. Sometimes I think I know my destination, only to find that both my course and the destination have changed.
Didn’t Slack do that exact thing, but the other way around, and are now worth 20 billion?
The founder even did it twice. The last time he set out to make a video game, he came out the other end with Flickr
According to its inventor, Scrum™ was created to manage a team of dysfunctional COBOL programmers at a bank[1], not to find a Product/Market Fit (PM/F).
Instead of using an SDLC methodology here, use one of the relevant product frameworks for that, but needless to say, there is a large element of luck here, as finding a PM/F isn't guaranteed.
Usually you use low-tech SDLCs like Scrum/SAFe at the places that already have found PM/F, or those relying on violence (aka "taxation") as their main business model (e.g. military/government/public sector).
The only PM/F Scrum Inc found is how to make bazillions from useless certifications and training.
--
[1] Scrum | Dr Jeff Sutherland | Talks at Google
https://youtu.be/2L1oBLTICx4?t=1217
Instead of using an SDLC methodology here, use one of the relevant product frameworks for that, but needless to say, there is a large element of luck here, as finding a PM/F isn't guaranteed.
Usually you use low-tech SDLCs like Scrum/SAFe at the places that already have found PM/F, or those relying on violence (aka "taxation") as their main business model (e.g. military/government/public sector).
The only PM/F Scrum Inc found is how to make bazillions from useless certifications and training.
--
[1] Scrum | Dr Jeff Sutherland | Talks at Google
https://youtu.be/2L1oBLTICx4?t=1217
Plus they ended up with the most elaborate Easter eggs I have seen in a web app: https://slack.com/404
While I personally don't believe it, one could easily explain it with survivorship bias.
Yet I’ve seen agile/scrum ending up in exactly the situation you’ve described! It goes wrong more than it goes right and it’s about time the industry stops letting management dictate these “practices” to engineers.
Made me laught
Orienteers then? They don’t know their destination until they have their next waypoint. It’s not healthy to live in an eternally manic state of having to sprint at work.
Orienteering definitely fits better.
And it's a competitive sport. It might not be healthy, but that's how you win.
And it's a competitive sport. It might not be healthy, but that's how you win.
Not all who wander are lost.
A hiker or a marathon runner or a club cyclist not currently at an event have a destination: where they started. But the good stuff happens in the middle, and that’s not necessarily planned out in advance.
Pacing is even more important then because there may be nobody to come bail you out, or it might take hours for them to do so.
A hiker or a marathon runner or a club cyclist not currently at an event have a destination: where they started. But the good stuff happens in the middle, and that’s not necessarily planned out in advance.
Pacing is even more important then because there may be nobody to come bail you out, or it might take hours for them to do so.
> marathon runners know their destination
Hell, in this analogy even the marathon organizers don't know the destination. Or much care.
Hell, in this analogy even the marathon organizers don't know the destination. Or much care.
Ideally, during first few years organizers are runners. They don't know the destination, but they care more than anyone.
So do sprinting runners, unless something has gone horribly wrong in the track design. Maybe we should get rid of the running analogies altogether and adopt the term "voyage" instead
Or "journey" - then you can explore philosophical concepts like "it's not about the destination, it's about the journey" to help cope with projects that never get finished...
The value of a sprint is to help keep everyone focused on how to deliver something of value and usually this means working with the customer to figure out how to make sure you deliver the valuable pieces while deferring the pieces that can wait until later. So basically making sure everyone is able to work efficiently. If they are being used to try to make people work more hours every week, then they are missing the point.
Ah yes, the mythical customer that can tell you exactly what they need, and even prioritize it. This customer probably also can be bothered to give usable feedback on what you have built in a timely manner. But I've yet to see such a customer...
If there is no customer for the software that is being built, then there is no one who would be disappointed if it was not built. :). So the most efficient thing to do is to do nothing.
There usually is a customer. It may not be the person who is called the customer, but somewhere there is someone who is spending money on development and is wanting to be able to us or benefit from whatever is being produced.
If the customer doesn't have time to collaborate with the devs to provide feedback, it might be a sign that what is being built isn't valuable to them. This could be either because it doesn't address a real need or because the cycle time is so slow it isn't going to help them any time soon. When a dev team is working on the customer's biggest pain point and has a track record of delivering a solution in a few days, customers will magically have time to talk about it.
There usually is a customer. It may not be the person who is called the customer, but somewhere there is someone who is spending money on development and is wanting to be able to us or benefit from whatever is being produced.
If the customer doesn't have time to collaborate with the devs to provide feedback, it might be a sign that what is being built isn't valuable to them. This could be either because it doesn't address a real need or because the cycle time is so slow it isn't going to help them any time soon. When a dev team is working on the customer's biggest pain point and has a track record of delivering a solution in a few days, customers will magically have time to talk about it.
It doesn't literally have to be a customer talking to you.
You could measure engagement, conversion, churn, or any other meaningful metric. The main point is shortening feedback cycle.
You could measure engagement, conversion, churn, or any other meaningful metric. The main point is shortening feedback cycle.
Why need a "push" sprint for that, a "pull" priority queue like XP is just fine. Then demo every few weeks plus or minus, when there is something tangible to show.
I prefer pull systems and most teams I've seen that are more concerned about following Agile than following Scrum eventually evolve from Scrum to something that looks more like Kanban. If you regularly talk about how to make things better, pull systems tend to emerge.
But sprints are often a reasonable step especially for teams that are part of a large organization. It is often easier (and faster) to move a team from waterfall to sprints to a pull system than it is to go from waterfall to a pull system directly.
But sprints are often a reasonable step especially for teams that are part of a large organization. It is often easier (and faster) to move a team from waterfall to sprints to a pull system than it is to go from waterfall to a pull system directly.
IMO Kanban (i.e. "pull") is better suited for reactive work (bug fixing, QA, support, ops, etc.).
There is a third approach: to give autonomy to the team so that it can distribute and perform tasks as it sees fit. There may be hints about priorities, such as a must-to-have or nice-to-have. See: Shape Up Method or Informal Mini Waterfall SDLC (design->plan->build(iteration)->ship) used by FAANG.
Once you have a written design document (especially if you wrote it yourself), you don't need a ticketing system like Jira. In many places we have only used tickets for bug reports and not for tasks.
There is a third approach: to give autonomy to the team so that it can distribute and perform tasks as it sees fit. There may be hints about priorities, such as a must-to-have or nice-to-have. See: Shape Up Method or Informal Mini Waterfall SDLC (design->plan->build(iteration)->ship) used by FAANG.
Once you have a written design document (especially if you wrote it yourself), you don't need a ticketing system like Jira. In many places we have only used tickets for bug reports and not for tasks.
[deleted]
Can you please show me a single example of a real company working under classical waterfall in the last decade?
NOTE: informal SDLCs, mini-waterfall, and RUP are not classical waterfall.
Agile™/Scrum® consultants implanted false memories to so many people. My colleagues who worked with me under lightweight flavor of RUP using an incremental approach, after getting Scrum Master certification now referring to it as "waterfall" ;)
NOTE: informal SDLCs, mini-waterfall, and RUP are not classical waterfall.
Agile™/Scrum® consultants implanted false memories to so many people. My colleagues who worked with me under lightweight flavor of RUP using an incremental approach, after getting Scrum Master certification now referring to it as "waterfall" ;)
employers are happy to let people "burn out" via exiting after a number of years of consistent sprinting because hiring occasional replacements can also be useful in other ways and the social cost of those burnout patterns isn't really the company's concern. so as often said at companies/by management, try to connect your view on what an individual's healthiest or most productive life would be to what is actually valuable to their employer as a business
Estimates are done by developers. If devs think they must do things quickly it's up to them to communicate estimates that will make their life stressful. My approach was not to challenge estimates except if I thought they were too low, which led my teams to almost always meet their sprint goals.
This is true, but in reality what happens a team has estimated that 40 points of work is need to reach the point that management has requested, for a 30point capacity sprint, it always ends up being a discussion with the team about “scaling down estimation” and never a discussion about “how do we break it to management that what they have requested is impossible to achieve”
> Does it ever occur to Scrum people that it’s not a good idea to spend your entire life in a mad state of sprinting?
It’s just a word. Variables can be constant and constants can have values that are different from time to time, yet programming isn’t a futile endeavor. You’d think that people who create software could abstract from words but no, we are doomed to repeat again and again that “sprint” is just a word that was chosen to signify that in one time boxed period you are trying to reach a given destination, not to get as far as possible.
In safe they call them iterations instead of sprints. But it doesn’t matter what word you use, what matters is the definitions and intents. Would a sprint by any other name not smell as sweet?
Marathon has a clear route and a clear end point defined before the starter gun goes off.
Now imagine a marathon run by a drunk monkey who changes the route on a whim every 30 minutes.
Who wins, the sprinters who sprint for 30 minutes and check where the next target is or the marathon runners who are still going by the original plan?
Now imagine a marathon run by a drunk monkey who changes the route on a whim every 30 minutes.
Who wins, the sprinters who sprint for 30 minutes and check where the next target is or the marathon runners who are still going by the original plan?
Well nobody can keep up a sprint pace for 30 mins let alone a marathon distance, so those people will burn out before they get that far.
Well, one man can[0], but in general this is very true. My team was talking about this same thing a few days ago, as one of our team members got switched to a new team that sprints all the time. You can't sprint your whole life, it's much better to pace yourself and avoid burnout/injury.
[0]: https://youtu.be/A73HQwEct-o
[0]: https://youtu.be/A73HQwEct-o
Doesnt matter, if you cant keep the pace they’ll pip or underperform you and then throw you out.
Yes, and there have been some attempts to popularize longer cycles with saner breaks built in. 37signals’ Shape Up methodology is one, for example.
Would you rather call it a saunter?
I'm probably doing standups wrong, but I find it useful for devs to (briefly) talk about what they're working on. Bring up something you're struggling on and maybe I can jump in and help. Let people know you're working on a hotfix today, so try to not bother you. Get early feedback on priorities from the PM if you're going down the wrong path or a customer changed their mind on something you didn't hear about.
I also like to have a casual dev text chat going throughout the day so you can post things like "Why isn't customer history appearing on this page?" "That page uses a one-off modified version of that query that doesn't grab history because we don't need to display it there. It used to increase load time by 30%."
Sometimes the flow of this is just easier in person, and a dedicated short meeting where everyone speaks up about their own work doesn't feel as much like backseat accusations.
It does require people actually feel comfortable asking for help, and it requires people to volunteer their guidance.
As I see more and more devs and different work places, I can't believe how common it is to just sit in your corner and struggle while refusing to ask for help and refusing to speak up when someone on your team is actually asking for help.
Is this communication failure the norm at your places of work? What's the deal?
I also like to have a casual dev text chat going throughout the day so you can post things like "Why isn't customer history appearing on this page?" "That page uses a one-off modified version of that query that doesn't grab history because we don't need to display it there. It used to increase load time by 30%."
Sometimes the flow of this is just easier in person, and a dedicated short meeting where everyone speaks up about their own work doesn't feel as much like backseat accusations.
It does require people actually feel comfortable asking for help, and it requires people to volunteer their guidance.
As I see more and more devs and different work places, I can't believe how common it is to just sit in your corner and struggle while refusing to ask for help and refusing to speak up when someone on your team is actually asking for help.
Is this communication failure the norm at your places of work? What's the deal?
You are not doing it wrong.
Standups can be traced back to the Scrum practice Daily Scrum. The Daily Scrum is a short (max 15 minute) synchronisation meeting for developers. It is explicitly not a status meeting for PMs. It eventually became known as a standup because people figured out that it was easier to keep the meeting short when you were not sitting down.
Scrum became popular, but it didn’t really make room for traditional project managers. So what to do with all the PMs? Teach them to be Scrum Masters.
This is where things started to go downhill. Most PMs just kept doing what they had always done, just using different names.
And so standups became hour long status meetings, inspect and adapt, sustainable pace and other good things were replaced with micromanagement and death marches. Dark Scrum was born.
This is of course greatly simplified. Agile Consultants and certification peddlers are also to blame.
Standups can be traced back to the Scrum practice Daily Scrum. The Daily Scrum is a short (max 15 minute) synchronisation meeting for developers. It is explicitly not a status meeting for PMs. It eventually became known as a standup because people figured out that it was easier to keep the meeting short when you were not sitting down.
Scrum became popular, but it didn’t really make room for traditional project managers. So what to do with all the PMs? Teach them to be Scrum Masters.
This is where things started to go downhill. Most PMs just kept doing what they had always done, just using different names.
And so standups became hour long status meetings, inspect and adapt, sustainable pace and other good things were replaced with micromanagement and death marches. Dark Scrum was born.
This is of course greatly simplified. Agile Consultants and certification peddlers are also to blame.
> I'm probably doing standups wrong, but I find it useful for devs to (briefly) talk about what they're working on.
I agree, regular communication within a team is healthy, but the way stand ups tend to manifest themselves is a meeting every single day where people feel compelled to share a status update. It would be rare for an individual to be blocked every single day, and thus this becomes a wasteful ceremony of going through the motions of giving status updates.
If team communication is healthy, there really isn't a need of daily stand ups. Individual team members will know when to escalate being blocked, and loop in the right people at the right time. If you are inheriting a dysfunctional team, daily stand ups can be a way to get the team back on track. For new members of the team, having a mentor to do frequent, even twice daily check ins, can be helpful on getting them up to speed.
But for high performance teams who have been operating together for years, daily stand ups are often a waste of time, and a needless addition to the calendar.
I agree, regular communication within a team is healthy, but the way stand ups tend to manifest themselves is a meeting every single day where people feel compelled to share a status update. It would be rare for an individual to be blocked every single day, and thus this becomes a wasteful ceremony of going through the motions of giving status updates.
If team communication is healthy, there really isn't a need of daily stand ups. Individual team members will know when to escalate being blocked, and loop in the right people at the right time. If you are inheriting a dysfunctional team, daily stand ups can be a way to get the team back on track. For new members of the team, having a mentor to do frequent, even twice daily check ins, can be helpful on getting them up to speed.
But for high performance teams who have been operating together for years, daily stand ups are often a waste of time, and a needless addition to the calendar.
I'm probably doing standups wrong...
And then you describe some of the healthiest standup culture I've seen...
And then you describe some of the healthiest standup culture I've seen...
[deleted]
Are you getting value from those meetings? Are you willing to try new things if someone has a suggestion that might make it better? If so you are doing it right..regardless of what anyone else says.
I can't believe anyone thinks a daily reportorial meeting by everyone to everyone is a good idea.
(Please don't bother telling me that's not what scrum and agile is supposed to be. I know, I got the training. Maybe you can instead suggest a way a daily standup doesn't devolve into that pretty quickly no matter what anyone says at first.)
One thing I've noticed is that so many people attempting to run software development projects are literally blind to information flow. They simply cannot conceive of the constraints of how information needs to flow... who would need to know what and when and where that information could come from. Any rational way of organizing this just moves straight to ball-of-mud, where everyone needs to know everything from everyone else. Any single gap impacts almost everything. I wonder why the velocity metric is so low!
(Please don't bother telling me that's not what scrum and agile is supposed to be. I know, I got the training. Maybe you can instead suggest a way a daily standup doesn't devolve into that pretty quickly no matter what anyone says at first.)
One thing I've noticed is that so many people attempting to run software development projects are literally blind to information flow. They simply cannot conceive of the constraints of how information needs to flow... who would need to know what and when and where that information could come from. Any rational way of organizing this just moves straight to ball-of-mud, where everyone needs to know everything from everyone else. Any single gap impacts almost everything. I wonder why the velocity metric is so low!
It's basically a shitty way to push people to communicate. When people mention "well just get rid of it and talk asynchronously", one of the counterarguments tends to be "but X may not communicate".
Of course, no one bothers to answer the question "why does an adult need a daily reminder to speak?", and no one considers the repercussions of such a ritual (people will start hoarding questions until the daily, which makes the daily longer, which.. you get the point).
That's the entire problem with Scrum anyway. It expects a very specific environment and immediately risks becoming redundant in such an environment (based on team preferences). Outside of that environment, it fails to do anything.
Of course, no one bothers to answer the question "why does an adult need a daily reminder to speak?", and no one considers the repercussions of such a ritual (people will start hoarding questions until the daily, which makes the daily longer, which.. you get the point).
That's the entire problem with Scrum anyway. It expects a very specific environment and immediately risks becoming redundant in such an environment (based on team preferences). Outside of that environment, it fails to do anything.
I'm on a remote team and we do a video call standup once a week and the other days we just post our updates to slack at the same time every day. Folks do tend to read each other's updates and add comments when they have input. It works reasonably well for us.
I feel bad for all the folks in this thread who have to deal with the manager's version of optimizing scrum/agile to the point where everyone hates it.
At my company, we enforce a 'little a agile' culture where we take the spirit of iteration and short-term planning, but we don't do certain ceremonies because we have to. Our standups take 15 minutes, we have a quick banter and then update on what we're working on and any blockers. Our retros/sprint planning are an hour each two weeks. We share responsibilities so that we take turns running retro and tie in themes and silly things to make it more bearable. My team is engaged and gives feedback on the process when it's annoying, which we take and apply as much as we can if the team agrees.
Managers (like me) need to learn that agile isn't for them to get a status report every day on what their reports are doing. It's a set of tools for engineering to be effective. Hire good people and get out of the way. Let engineers tell you how to do their jobs effectively, your job is to clarify company goals and support them to reach those goals.
At my company, we enforce a 'little a agile' culture where we take the spirit of iteration and short-term planning, but we don't do certain ceremonies because we have to. Our standups take 15 minutes, we have a quick banter and then update on what we're working on and any blockers. Our retros/sprint planning are an hour each two weeks. We share responsibilities so that we take turns running retro and tie in themes and silly things to make it more bearable. My team is engaged and gives feedback on the process when it's annoying, which we take and apply as much as we can if the team agrees.
Managers (like me) need to learn that agile isn't for them to get a status report every day on what their reports are doing. It's a set of tools for engineering to be effective. Hire good people and get out of the way. Let engineers tell you how to do their jobs effectively, your job is to clarify company goals and support them to reach those goals.
>>Hire good people and get out of the way.
If you hire good people, it won't matter what framework they use, is my position. Give me a good team and I will deliver a good product agile/scrum/kanban/SAFe/waterfall - doesn't matter - thats all window dressing if you don't have a good team.
If you hire good people, it won't matter what framework they use, is my position. Give me a good team and I will deliver a good product agile/scrum/kanban/SAFe/waterfall - doesn't matter - thats all window dressing if you don't have a good team.
<<we enforce a 'little a agile'>>
The word enforce here is a marker that shows that you failed to do Agile. You do something that is not the Agile as in "Agile Manifesto" and brand it like that.
Because in the original agile concept, that is the team itself that can "self-organize" to what fits them the best. If management impose an organization, like mandatory meetings and co, it is not anymore Agile.
The word enforce here is a marker that shows that you failed to do Agile. You do something that is not the Agile as in "Agile Manifesto" and brand it like that.
Because in the original agile concept, that is the team itself that can "self-organize" to what fits them the best. If management impose an organization, like mandatory meetings and co, it is not anymore Agile.
I read it similar to enforcing free speech; that doesn't mean making people talk, it means protecting it from violations. Enforcement of little "a" agile implies preventing more pomp and circumstance and growing into capital "A" Agile.
Seems like you interpreted my use of 'enforce' quite heavily which isn't a good representation of our work culture. "We practice" would have been better phrasing.
If you read the rest of my comment, I mention that we regularly solicit and apply feedback to our process which gives the team the opportunity to "self-organize", as you say.
If you read the rest of my comment, I mention that we regularly solicit and apply feedback to our process which gives the team the opportunity to "self-organize", as you say.
Truly self organizing team is pure hell. I have worked in that setup and never again. Management in fact have position and responsibility to set up culture and basic rules.
Also, "team" is an abstraction and cant organize nothing. Team members push and organize. "Self organizing team" is just euphemism for "micromanagement by most aggressive jerk" or "the one non passive person don't get recognized" or whatever dysfunction currently runs on unchecked.
Also, "team" is an abstraction and cant organize nothing. Team members push and organize. "Self organizing team" is just euphemism for "micromanagement by most aggressive jerk" or "the one non passive person don't get recognized" or whatever dysfunction currently runs on unchecked.
'little a agile' is explicitly saying it's not the proper noun 'Agile'. Which is the point.
Exactly this, it’s always funny in a depressing way when micromanagement overrides most of the point of agile.
“We enforce agile” is just a huge red flag and and an indication that the organisation is “doing Agile” instead of being agile.
“We enforce agile” is just a huge red flag and and an indication that the organisation is “doing Agile” instead of being agile.
Agile and Scrum are not the same thing, and I think that's probably the most important idea to understand about Scrum.
With Agile, if you can't draw a clear, bright line from some ritual you're doing to meaningful value, you need to drop that ritual immediately. With scrum, it tends to be "all-or-nothing", even if it's not quite meant to be.
Even something as "fundamental" as stand-ups or sprints need to have clear value for your team[1], or you need to drop them, and I think a lot of leaders are afraid of doing so lest they lose the "magic" of Agile.
[1] FWIW I do think stand-ups are usually valuable, but only if, "Nothing to report." is a 100% allowed thing to say. As a lead, I like to do this myself a bunch early on to show its acceptability.
With Agile, if you can't draw a clear, bright line from some ritual you're doing to meaningful value, you need to drop that ritual immediately. With scrum, it tends to be "all-or-nothing", even if it's not quite meant to be.
Even something as "fundamental" as stand-ups or sprints need to have clear value for your team[1], or you need to drop them, and I think a lot of leaders are afraid of doing so lest they lose the "magic" of Agile.
[1] FWIW I do think stand-ups are usually valuable, but only if, "Nothing to report." is a 100% allowed thing to say. As a lead, I like to do this myself a bunch early on to show its acceptability.
> The problem with Scrum is that it usually works
Aaaand right off the bat you've lost me.
Define "works". If you mean it is a process and can be followed, sure, I guess?
I would rather define it as "bullshit that keeps non technical people happy and in control". Despite the derogatory tone, I think that can have it's place. For example, engineers are generally terrible at selling their product, and knowing what end users actually want -- with non technical applications. So having "business people" run the show there is probably a good idea.
Where it becomes unbearably moronic however, is when that happens at a supposedly tech company.
Aaaand right off the bat you've lost me.
Define "works". If you mean it is a process and can be followed, sure, I guess?
I would rather define it as "bullshit that keeps non technical people happy and in control". Despite the derogatory tone, I think that can have it's place. For example, engineers are generally terrible at selling their product, and knowing what end users actually want -- with non technical applications. So having "business people" run the show there is probably a good idea.
Where it becomes unbearably moronic however, is when that happens at a supposedly tech company.
Scrum is explicitly about giving control to the developers. This is why it's not used "correctly" (read: rigorously) in a lot of businesses, it's fundamentally incompatible with the micromanaging approach that control freak managers tend to use.
I came to dislike standup at Amazon.
Everyday we had one to start the day, and people never talked about their blockers. Some folks would give a super brief overview of what they did and will do. This was fine, but not really interesting to have 5 days a week. But then other folks would give a play-by-play of what they did and how, and what they will do next and how they will do it.
It's like sounding busy was more important than the rest of team's time and sanity.
Personally, I think it's more helpful to just have a daily team 30 minutes scheduled to discuss any important topics, vs specifically to have a status updates. The actual standup function where people prefer updates can happen >= 1 day a week && < 5 days a week
Everyday we had one to start the day, and people never talked about their blockers. Some folks would give a super brief overview of what they did and will do. This was fine, but not really interesting to have 5 days a week. But then other folks would give a play-by-play of what they did and how, and what they will do next and how they will do it.
It's like sounding busy was more important than the rest of team's time and sanity.
Personally, I think it's more helpful to just have a daily team 30 minutes scheduled to discuss any important topics, vs specifically to have a status updates. The actual standup function where people prefer updates can happen >= 1 day a week && < 5 days a week
It's a slippery slope. If there's one guy that gives a 3 minute update, he'll look more productive than the guy that gives 30 second update. So the next day 30s guy will fill his update with unnecessary details to look as productive.
The cure is constantly being aware of that bias. And remembering that main audience for standups is not your manager, it's your peers. Talk about things you want them to know.
There's a lot of subtle tricks that people don't even use/remember at this point. Like doing standups while actually physically standing. This creates a negative feedback loop instead of positive: if someone talks too much, the whole team will pushback.
The cure is constantly being aware of that bias. And remembering that main audience for standups is not your manager, it's your peers. Talk about things you want them to know.
There's a lot of subtle tricks that people don't even use/remember at this point. Like doing standups while actually physically standing. This creates a negative feedback loop instead of positive: if someone talks too much, the whole team will pushback.
we combatted the bias factor by having managerless standups, and a designated (rotating) person just takes notes and forwards them to the manager.
Its actually fine. Management has repeatedly admitted they get little out of standups when there isn't a managerial level blocker (IE, we need them to interface with a team) and the concise written note updates allow them to see patterns of issues and address them more holistically.
For engineers, it got rid of the implicit bias talked about here.
Our standups are like 5 minutes or less now, and blockers / collaboration on blockers is way more common.
This also made the stakeholder check in every two weeks way more productive, people I think shifted their look what I did and how I did it energies to that meeting, where its 100% more appropriate.
Its actually fine. Management has repeatedly admitted they get little out of standups when there isn't a managerial level blocker (IE, we need them to interface with a team) and the concise written note updates allow them to see patterns of issues and address them more holistically.
For engineers, it got rid of the implicit bias talked about here.
Our standups are like 5 minutes or less now, and blockers / collaboration on blockers is way more common.
This also made the stakeholder check in every two weeks way more productive, people I think shifted their look what I did and how I did it energies to that meeting, where its 100% more appropriate.
I really like that.
Having management present can subconsciously push people to turn standups into a productivity contest.
Having management present can subconsciously push people to turn standups into a productivity contest.
in the notes, is there information about who did what or not?
I hesitate to broadly interpret this, but notes are not meant or used to "keep score", and if things can be explained without naming people they are, for sure, but
"person A is going to help person B to unblock them because of x y z" is about as detailed as one needs to be, usually.
Can you clarify what exactly you mean here?
"person A is going to help person B to unblock them because of x y z" is about as detailed as one needs to be, usually.
Can you clarify what exactly you mean here?
You actually answered my question, thanks. I was/am just curious about which person has the decision power about who works on which part. But I guess it goes something like: person A tries to solve X. If he can't solve it, he asks the team and someone in the team will try helping. If the problem cannot be solved within a reasonable timeframe, then someday management will ask what's going on.
No manager in the meeting. No one to impress. Everybody stands. Light banter at the beginning because we're a team. One person leads the standup, round robin each time. Standup leader takes notes to paste in chat after, hurries people the f up if they're going on and on. Lastly, if you are late to standup even by 1 minute, you have to sing a song of Standup Leader's choice.
Yeah. "Let's take that offline/out of the meeting" when someone talks longer than 1 minute (longer than 30 seconds if it's a larger team).
By the way, I was at a place that did XP, and one of the rules was that if there was a meeting, there had to be food. What that did is, if someone was talking too much, someone would ask them "Are you going to eat that?" That, um, gently if not subtly told them to stop talking so much. Also, it meant that we got to snack.
By the way, I was at a place that did XP, and one of the rules was that if there was a meeting, there had to be food. What that did is, if someone was talking too much, someone would ask them "Are you going to eat that?" That, um, gently if not subtly told them to stop talking so much. Also, it meant that we got to snack.
we used to call ‘parking lot’ as in ‘Let’s take this outside’. Then when the standup ended, those that wanted to get in on the topics on the parking lot would stick around.
And for every minute you ran late, you had to do a push up.
And for every minute you ran late, you had to do a push up.
It's not supposed to be a slippery slope. This is where a functioning "Scrum Master" is supposed to tell that person to stop talking and move on to the next person. That never actually happens though, so the next best scenario is light shaming of the guy who talks too long. If you have bad managers or too many people with management anxiety then it can be good to kick them out of the meeting.
I understand that this is how it is supposed to work in theory. But realistically most startups don't (and dare I say shouldn't) have the luxury of a dedicated Scrum Master.
Another thing I don't like is that it relies on humans to do a good job. How do you hire a good Scrum Master if you've never been one yourself? Hires like that are usually hit or miss. What if you need to hire ten of those?
Another thing I don't like is that it relies on humans to do a good job. How do you hire a good Scrum Master if you've never been one yourself? Hires like that are usually hit or miss. What if you need to hire ten of those?
> But then other folks would give a play-by-play of what they did and how, and what they will do next and how they will do it.
Saw a principal engineer do that. He would take what could be summarized in a sentence or two and spend 5+ minutes describing it.
Same guy once rejected a PR and made me initialize a field to null instead of empty string, his rationalization is that he's been both a DBA and a developer over his 7 year career, so he knows better. than apparently the entire industry that's been moving away from code like that for the last 10+ years.
yes, you read that right. 7 years, not all of it in software dev, working as a principal engineer.
politics are a bitch sometimes.
Saw a principal engineer do that. He would take what could be summarized in a sentence or two and spend 5+ minutes describing it.
Same guy once rejected a PR and made me initialize a field to null instead of empty string, his rationalization is that he's been both a DBA and a developer over his 7 year career, so he knows better. than apparently the entire industry that's been moving away from code like that for the last 10+ years.
yes, you read that right. 7 years, not all of it in software dev, working as a principal engineer.
politics are a bitch sometimes.
> take what could be summarized in a sentence or two and spend 5+ minutes describing it
Don't hate the player, hate the game. I had a job that required weekly status updates by e-mail (cc-ed to the entire team for some reason). My updates went on for pages. If somebody asked me to look at something and it took more than 10 minutes, that went on my status report: "Worked with so-and-so to do such-and-such"). My boss confided in me that could tell what I was doing and he appreciated it. Why? Because he summarized those statuses into a big, long (the longer the better) update e-mail to his boss.
If you incentivize stupidity, you're going to get stupidity, even from smart people. Especially from smart people.
Don't hate the player, hate the game. I had a job that required weekly status updates by e-mail (cc-ed to the entire team for some reason). My updates went on for pages. If somebody asked me to look at something and it took more than 10 minutes, that went on my status report: "Worked with so-and-so to do such-and-such"). My boss confided in me that could tell what I was doing and he appreciated it. Why? Because he summarized those statuses into a big, long (the longer the better) update e-mail to his boss.
If you incentivize stupidity, you're going to get stupidity, even from smart people. Especially from smart people.
> If you incentivize stupidity, you're going to get stupidity
that's the essence of the Agile™, Scrum® and SAFe©
that's the essence of the Agile™, Scrum® and SAFe©
Has anyone here had experience with daily standups done exclusively over Slack (or similar service)?
To me it seems like it would mitigate some of the downsides like people talking too much. And being asynchronous and in written form is a big plus to me. I can just skim through it quickly rather than sit through a monotonous daily meeting.
To me it seems like it would mitigate some of the downsides like people talking too much. And being asynchronous and in written form is a big plus to me. I can just skim through it quickly rather than sit through a monotonous daily meeting.
at one company we did a project wide daily standup on irc. all teams, about 50 people would report all at once at a specific time of day. there was a bot that would track that everyone has reported, and that was it. as a developer i would look at the report log to see if anyone was touching issues that i was working on, and if so possibly talk to that person later to see if there was anything we needed to coordinate. likewise i'd look if anyone reported blockers where i could help.
Forcing introverts to get out of the comfort zone and talk to each other has lots of benefits.
Async Slack gives everyone the opportunity to tune out, which they definitely will.
A blocker can be resolved either on the standup or during a quick follow-up call that happens right after. Going async risks that the same blocker will be resolved in 1-2 days.
I strongly recommend against it.
Async Slack gives everyone the opportunity to tune out, which they definitely will.
A blocker can be resolved either on the standup or during a quick follow-up call that happens right after. Going async risks that the same blocker will be resolved in 1-2 days.
I strongly recommend against it.
I am so bitter about agile at this point it actually feels abit refreshing that someone still defends Scrum.
> You’ll know you have successfully ruined your standups when they’re taking thirty or more minutes
The author is an order of magnitude off here. The despair sets in way earlier.
> You’ll know you have successfully ruined your standups when they’re taking thirty or more minutes
The author is an order of magnitude off here. The despair sets in way earlier.
60 seconds per member of the team. 15 minutes hard limit.
If there are issues, you handle them outside of the daily scrum, it's not a troubleshooting session, it's a status update.
If there are issues, you handle them outside of the daily scrum, it's not a troubleshooting session, it's a status update.
then you'll also have folks who would say "if your daily standup is a 'status update', you're doing it wrong". and they're probably right.
scrum.org - "The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours."
Most "daily standups" I've been at are performative song-and-dance with non-dev stakeholders running the meetings. They're definitionally just status meetings. There's no internal 'dev-only' talk, or identifying problems to work through, or sharing knowledge. Nope, it's just 'all non-devs need to know the status of every issue in a jira board, daily'. Why they can't just ... you know... look at the jira board they're forcing us to use, and see the status there... I dunno. Half the time when I'd update something there, I'd repeat in a meeting "all this is in jira". "Oh, I don't have time to comb through all that - it's too slow". OK... but if I DIDN'T update jira tickets... that was slowing down the team because "now people can't tell where you're at". So... there was no way to 'win' there...
scrum.org - "The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours."
Most "daily standups" I've been at are performative song-and-dance with non-dev stakeholders running the meetings. They're definitionally just status meetings. There's no internal 'dev-only' talk, or identifying problems to work through, or sharing knowledge. Nope, it's just 'all non-devs need to know the status of every issue in a jira board, daily'. Why they can't just ... you know... look at the jira board they're forcing us to use, and see the status there... I dunno. Half the time when I'd update something there, I'd repeat in a meeting "all this is in jira". "Oh, I don't have time to comb through all that - it's too slow". OK... but if I DIDN'T update jira tickets... that was slowing down the team because "now people can't tell where you're at". So... there was no way to 'win' there...
the whole Jira thing really pisses me off. I hate Jira almost more than this scrum/agile nonsense. If no one wants to look at the damn board, why are we doing this??
> with non-dev stakeholders running the meetings
9 out of 10 standups I'm in have zero of the stakeholders necessary to unblock the work. I'm announcing my blockers to other devs that zoned out 10 minutes ago and the scrum master that will say something hollow and silly such as "keep working on that" or "make sure to ping so-and-so." Thanks. Want to come to the restroom with me and hold my pee pee so I don't fuck that up too?
We are all infants.
Also. Allllllso. Scrum Master. Scrum. Master. Shouldn't you people be Scrum Main? Or Scrum Primary? Or did you not get that memo? They are literally keeping their developer minions in check. It's a bit... how do I say this? On the nose? Much more in a way than a branch name of git ever was.
> with non-dev stakeholders running the meetings
9 out of 10 standups I'm in have zero of the stakeholders necessary to unblock the work. I'm announcing my blockers to other devs that zoned out 10 minutes ago and the scrum master that will say something hollow and silly such as "keep working on that" or "make sure to ping so-and-so." Thanks. Want to come to the restroom with me and hold my pee pee so I don't fuck that up too?
We are all infants.
Also. Allllllso. Scrum Master. Scrum. Master. Shouldn't you people be Scrum Main? Or Scrum Primary? Or did you not get that memo? They are literally keeping their developer minions in check. It's a bit... how do I say this? On the nose? Much more in a way than a branch name of git ever was.
> 60 seconds per member of the team.
Ye, on average. Most people should ideally, in my mind, say "same old, same old" and let the next person speak.
I don't like the concept of dailies, but if there has to be one, three per week is a good deal. I understand how managers would want one in somewhat messy places.
Ye, on average. Most people should ideally, in my mind, say "same old, same old" and let the next person speak.
I don't like the concept of dailies, but if there has to be one, three per week is a good deal. I understand how managers would want one in somewhat messy places.
Yea, for a self-directing team three is perfectly fine. Monday, Wednesday and Friday.
Agile is very different than Scrum. Agile actually has very good SWE principles. Scrum is one heavy-handed approach to following them.
This was an excellent read. I worked at a company that did almost all of these. An absolute fanatical focus on velocity to the exclusion of everything else coupled with complete disconnect between story points and the time to actually implement the ticket. Total and complete failure to deliver almost every sprint. Every developer had to deliver a minimum of 10 points a week. Each sprint was 1 week. If you did not deliver 10 points you were written up. Jr. or Sr. and the points were estimated by the Sr. Devs. So the only way for a Jr. to hit their 10 points was to work 70 hours for months and years on end.
I left a couple years ago but when I left the system was absolute garbage and every week leadership was astounded that progress was not being made while only focusing on the number of points closed. Company is publicly traded and will potentially go out of business in 6 months. I was written up at the start of covid for hitting 8 points 2 weeks in a row. Right when everything shut down, schools closed etc.
When I quit, every Sr. engineer left within 6 months, ~50% of the engineering staff.
I left a couple years ago but when I left the system was absolute garbage and every week leadership was astounded that progress was not being made while only focusing on the number of points closed. Company is publicly traded and will potentially go out of business in 6 months. I was written up at the start of covid for hitting 8 points 2 weeks in a row. Right when everything shut down, schools closed etc.
When I quit, every Sr. engineer left within 6 months, ~50% of the engineering staff.
Wow, that's crazy. Is it possible to find this out while interviewing? My worry is some company might be willing to pay high salaries to new hires to recover from situations like these, but it would suck for me to join such a place.
I always ask my potential peers how they feel. Are you stressed, relaxed, happy, sad, mad, excited, ambivalent. What works great, what needs improvement. Ask them directly: are you happy with your scrum/agile process? Be careful though as just the words might trigger some ;) If they won't let you talk to your peers and instead you only get to talk to the manager and team lead, be wary: they might be trying to escape & say anything to hire new people. And if they say they are very very excited to have you on board, I'd say that's worrying too, unless you are some kinda rockstar. Also check out Glassdoor and other review sites.
I wonder how many articles, blogs, conferences, certifications, books, talks, soliloquies, consultants, etc. it will take to tell us we're all doing it wrong to make "Agile" and "Scrum" actually work.
Honestly I’m not sure management will ever acknowledge or admit they’ve totally distorted agile from what it was meant to be in the manifesto into Big Agile™ with its optional add-ons Scrum® and SAFe© especially with “Agile Delivery Consultants” and other nonsense titles. They’ve started replacing scrum masters with those now too.
At least until the next big thing comes along and they will declare agile to be just as bad as waterfall.
At least until the next big thing comes along and they will declare agile to be just as bad as waterfall.
Scrum works fine if you implement it by the book and then start tailoring slowly it based on team retros. Problem arises when PM or other manager goes rogue and starts implementing own ideas to scrum or just presures more stuff to sprint.
That’s part of my point. How many companies do I need to work for such that that works, because every company that has used Agile or Scrum say that exact thing about tailoring it to the team from some base level.
It seems to me that if everyone does it wrong, then it is not a good fit for how people actually work.
It seems to me that if everyone does it wrong, then it is not a good fit for how people actually work.
I'm facing the opposite challenge right now. I've recently joined in as the CTO of a small company and the team is in love with Scrum. They love it and they love Jira as well. Sometimes it seems that they spend more time using Jira than using their IDEs.
This wouldn't be so much of a problem, but the team is SLOW. Every little feature and adjustment drags for many 2-weeks sprints. Every task gets broken down to its atoms.
And what's tiresome to me is that, whenever I try to reduce the overhead and get them more time to do useful work, they push back strongly and they start to pile up minor nitpicks and corner cases of what might go wrong in the future if we do change.
I'd love to get some ideas on how to improve things without straining the relationship with top-down maneuvers.
This wouldn't be so much of a problem, but the team is SLOW. Every little feature and adjustment drags for many 2-weeks sprints. Every task gets broken down to its atoms.
And what's tiresome to me is that, whenever I try to reduce the overhead and get them more time to do useful work, they push back strongly and they start to pile up minor nitpicks and corner cases of what might go wrong in the future if we do change.
I'd love to get some ideas on how to improve things without straining the relationship with top-down maneuvers.
They probably don't love the process, they just use it as an excuse to slack off and they're probably quiet quitting.
Most of the industry is like this, so most small companies don't have a chance at being able to afford productive people.
My personal solution to this problem is relying on expensive agencies in cheap countries. I consult with mid-large companies and they all have the same problems: unmotivated developers who don't own the product, product managers that spend all their time in meetings and parrots what PM at Google say. Nothing gets done so what I do is advise the CTO to start moving projects to outside agencies, to teams that are actually productive.
I don't think non-tech focused companies can build product efficiently but they're excellent places for slacking developers to work in. I worked in agencies as a youngster and it was 10x more challenging than working in a product company. There was also way less bullshit and I could make decisions without having to organise a company wide meeting on how we do X.
Startups are a special case: when people are paid in equity they tend to care more about the company and things can work.
I have a bias: I'm planning to start an agency at some point in the next 5 years (albeit I'm a throwaway so you can't reach me)
Most of the industry is like this, so most small companies don't have a chance at being able to afford productive people.
My personal solution to this problem is relying on expensive agencies in cheap countries. I consult with mid-large companies and they all have the same problems: unmotivated developers who don't own the product, product managers that spend all their time in meetings and parrots what PM at Google say. Nothing gets done so what I do is advise the CTO to start moving projects to outside agencies, to teams that are actually productive.
I don't think non-tech focused companies can build product efficiently but they're excellent places for slacking developers to work in. I worked in agencies as a youngster and it was 10x more challenging than working in a product company. There was also way less bullshit and I could make decisions without having to organise a company wide meeting on how we do X.
Startups are a special case: when people are paid in equity they tend to care more about the company and things can work.
I have a bias: I'm planning to start an agency at some point in the next 5 years (albeit I'm a throwaway so you can't reach me)
This hit home to me. The part about parrot PMs is also an issue here that's been hard to deal with.
It gets back to what does the team value. If you can get the team to agree on what the core values are, it will help them take their eyes off the trees and focus on the forest. You'll need to meet with them apart from whatever scrum processes are going on.
Once the team values are more aligned, the retrospectives can start to be fruitful. At the retrospective, pick one or two items that seem misaligned with the values. Try to have longer term (at least a quarter) view, with incremental progress.
YMMV. I ended up leaving a team that functioned the way you describe. I'm sure your team is driving people away. At another team, I was able to take the approach above and the team became must better over 2 years.
Once the team values are more aligned, the retrospectives can start to be fruitful. At the retrospective, pick one or two items that seem misaligned with the values. Try to have longer term (at least a quarter) view, with incremental progress.
YMMV. I ended up leaving a team that functioned the way you describe. I'm sure your team is driving people away. At another team, I was able to take the approach above and the team became must better over 2 years.
Yes, it is driving people away. I lose one dev every two or tree weeks.
I've been on a similar team. The three original people devised some rituals they fell in love with and they tried to onboard their next 6-7 hires (myself included) in them.
Worked out horribly badly. Almost everybody left. Only one guy liked the endless meetings during which they played council of elders and every legitimate problem was shot down with "this is not the topic of this meeting, let's have a GitHub discussion and then schedule another meeting" (you can guess how well that worked out but hint: anemic discussions, nobody agrees to next meeting day/hour and the entire thing is forgotten and then weeks later you are at fault for not pursuing it aggressively enough. Yeah...)
You should start some tough conversations, like yesterday. I deliberately chose not to engage in any position that requires a lot of diplomacy (I am 42 and been offered a PM / managerial / VP of Eng position no less than 6 times in the last 5 years) and can't advise you on what exact brand of perfumed language to use but the main message should be:
"I realize that you, X, has been instrumental in the initial company's success and everyone around appreciates that. Things did however change and our approach must change as well. Are you open to start doing things a little differently? If not, why not? Did the legal team crucify you for not providing enough written details in the past? Let's work through the initial problem and solve it, please."
...or some such.
We are people and we LOVE rituals and we love stability and we especially love when we are in a tribe of like-minded people. But this has a steep cost when a team scales beyond a certain size -- as you yourself are finding out.
At one point management has to pick between the inner core of calcified programmers, or everyone else, because it seems they don't mix that well.
Again, I can't give you an advice how exactly you should present that to the relevant people that you must raise the issue to. But from my experience I can guarantee to you that entrenched old-time developers in a company (namely those who were there when it all started) tend to become way too self-important and with illusions of grandeur. This gets in the way more and more with time.
Uncomfortable conversations at work, exactly like in intimate relationships, must be done early. Seems you're already a bit late to the party but still -- the second best time is tomorrow.
Don't delay this. Or if you find yourself unwilling to tackle the problem you better start looking for another job because culture is one of the hardest things to change in any community.
Worked out horribly badly. Almost everybody left. Only one guy liked the endless meetings during which they played council of elders and every legitimate problem was shot down with "this is not the topic of this meeting, let's have a GitHub discussion and then schedule another meeting" (you can guess how well that worked out but hint: anemic discussions, nobody agrees to next meeting day/hour and the entire thing is forgotten and then weeks later you are at fault for not pursuing it aggressively enough. Yeah...)
You should start some tough conversations, like yesterday. I deliberately chose not to engage in any position that requires a lot of diplomacy (I am 42 and been offered a PM / managerial / VP of Eng position no less than 6 times in the last 5 years) and can't advise you on what exact brand of perfumed language to use but the main message should be:
"I realize that you, X, has been instrumental in the initial company's success and everyone around appreciates that. Things did however change and our approach must change as well. Are you open to start doing things a little differently? If not, why not? Did the legal team crucify you for not providing enough written details in the past? Let's work through the initial problem and solve it, please."
...or some such.
We are people and we LOVE rituals and we love stability and we especially love when we are in a tribe of like-minded people. But this has a steep cost when a team scales beyond a certain size -- as you yourself are finding out.
At one point management has to pick between the inner core of calcified programmers, or everyone else, because it seems they don't mix that well.
Again, I can't give you an advice how exactly you should present that to the relevant people that you must raise the issue to. But from my experience I can guarantee to you that entrenched old-time developers in a company (namely those who were there when it all started) tend to become way too self-important and with illusions of grandeur. This gets in the way more and more with time.
Uncomfortable conversations at work, exactly like in intimate relationships, must be done early. Seems you're already a bit late to the party but still -- the second best time is tomorrow.
Don't delay this. Or if you find yourself unwilling to tackle the problem you better start looking for another job because culture is one of the hardest things to change in any community.
Thanks a lot for this. I'll have a lot to think this weekend.
Anytime. I feel HN over-represents the too-optimistic and always-assume-good-faith point of view and I believe that is harmful for having an objective and multi-dimensional discourse.
99% of all people are indeed not actively malicious by default but they can be so wrongly incentivized that the end result mimics malice very closely anyway.
Understand the problematic people's motivation if you can. It will help you devise a strategy. If not then maybe it's time for some good old top-bottom management with "you are here to obey orders, bucko".
99% of all people are indeed not actively malicious by default but they can be so wrongly incentivized that the end result mimics malice very closely anyway.
Understand the problematic people's motivation if you can. It will help you devise a strategy. If not then maybe it's time for some good old top-bottom management with "you are here to obey orders, bucko".
Problem of wrong incentives is that they put same pressures on everybody. So if those aren't cleared next batch of devs, just didn't spoil yet :(
So looking at incentives first is good place to start. Those experienced devs can be great asset if they can feel they can change behavior now.
So looking at incentives first is good place to start. Those experienced devs can be great asset if they can feel they can change behavior now.
> Every little feature and adjustment drags for many 2-weeks sprints. Every task gets broken down to its atoms.
Can you provide some examples so readers can get a sense of whether we think your perception is accurate?
It might be that you have very high expectations or it might be that they really are slow, maybe so slow they should be replaced. But without examples it’s not possible to get a sense of which is the case.
Can you provide some examples so readers can get a sense of whether we think your perception is accurate?
It might be that you have very high expectations or it might be that they really are slow, maybe so slow they should be replaced. But without examples it’s not possible to get a sense of which is the case.
They are mostly developing an internal admin system meant for business operators. This system has the Lawsuit as its main entity. They spent two months to make a buggy screen that would aggregate several lawsuits into a single Deal (a new entity). This is an Angular + .NET project.
They need more training and there is a lot of tech debt that's slowing them down, but how am I supposed to tackle tech debt without speeding up their processes first? Genuine doubt in my mind :)
They need more training and there is a lot of tech debt that's slowing them down, but how am I supposed to tackle tech debt without speeding up their processes first? Genuine doubt in my mind :)
Sounds like you need a better tech team.
Tech-centric positions don't have enough sympathy for email job people. If there aren't meetings all day, then what do they do? They run out of email eventually. To correct poorly set meetings, including "scrum", have someone take notes and review those notes after. If there was constantly nothing to gain, then that meeting is 86'd and whoever set up that meeting gets their meeting setup privileges suspended.
> The problem with Scrum is that it usually works. In tech, we hate that. What we like is to give talks, prepare slide decks, and, most importantly, to invent things ourselves.
I've never seen Scrum works well in the last 10 years since I've heard of it.
No amount of BS scrum consultants is enough to make it work.
I've never seen Scrum works well in the last 10 years since I've heard of it.
No amount of BS scrum consultants is enough to make it work.
I read the title as: "How to distort Scrum until it actually works". At least that's been my experience over the past 15 years.
Agile requires trust to work. Without it, the process will quickly devolve.
Low trust is the problem, not scrum.
Trying to be agile without trust is like trying to bake bread without yeast. You go through all the same motions, but in the end all you have is a dense, sticky mess.
Low trust is the problem, not scrum.
Trying to be agile without trust is like trying to bake bread without yeast. You go through all the same motions, but in the end all you have is a dense, sticky mess.
If you have not yet read the Scrum Guide, please read it. It does not tell you in detail how to do Scrum, but the framework is there. https://scrumguides.org/scrum-guide.html
My favorite method of story pointing is throwing some chicken bones at a grease stain on the wall. It's as accurate as anything else.
My favorite method of story pointing is throwing some chicken bones at a grease stain on the wall. It's as accurate as anything else.
My overarching experience with 'agile story points' (paraphrased combination between multiple teams/projects).
"If it's not a 3, then it might be a 5. But if it's not a 5, that would mean it's an 8, and we can't have 8s. 8s are too much. You have to break it down more".
"What is 'too much'?"
"That's too many days of work".
"But I thought points weren't an estimate of time/hours/days, just a level of effort or complexity.".
"8s are too big"
"But... 8 is the best notion at this point. It's a complex problem. Maybe after working through the ticket, a natural break point will present itself and we can chunk it and make a second ticket with follow on work later. But right now, I can't see any split point".
"Well... you have to break it down first. Make this in to multiple tickets. The sprint starts tomorrow and we can't have 8s".
"If it's not a 3, then it might be a 5. But if it's not a 5, that would mean it's an 8, and we can't have 8s. 8s are too much. You have to break it down more".
"What is 'too much'?"
"That's too many days of work".
"But I thought points weren't an estimate of time/hours/days, just a level of effort or complexity.".
"8s are too big"
"But... 8 is the best notion at this point. It's a complex problem. Maybe after working through the ticket, a natural break point will present itself and we can chunk it and make a second ticket with follow on work later. But right now, I can't see any split point".
"Well... you have to break it down first. Make this in to multiple tickets. The sprint starts tomorrow and we can't have 8s".
I experienced similar at a previous company. Everything was a 1, 2, or 3. If it was a 5, the "scrum master" got a frowny-face. "Guys, can we break this down more??" Then a 15 minute discussion would ensue. That was literally the person's only contribution.
(If you suggested an 8, they'd look at you crazy and it would get back logged.)
The entire engineering org was measured on velocity. Every 2 weeks, at end of sprint, there would be a huge Slack posting with various stats for something like 6 or 7 teams. "85% completion! 5% are still in review. 10% of tasks were not even started!!"
Some managers would game the system. If a task wasn't done, they'd just mark it complete and open a ticket to finish it up next sprint (typically "integration testing for feature X" or "QA feature X".) One guy must've dragged his original 3 point ticket out for 4 sprints doing this. The "velocity" was meaningless.
(If you suggested an 8, they'd look at you crazy and it would get back logged.)
The entire engineering org was measured on velocity. Every 2 weeks, at end of sprint, there would be a huge Slack posting with various stats for something like 6 or 7 teams. "85% completion! 5% are still in review. 10% of tasks were not even started!!"
Some managers would game the system. If a task wasn't done, they'd just mark it complete and open a ticket to finish it up next sprint (typically "integration testing for feature X" or "QA feature X".) One guy must've dragged his original 3 point ticket out for 4 sprints doing this. The "velocity" was meaningless.
> "You have to break it down more"
"How much time do I have to do the analysis to break it down?"
"None"
"How much time do I have to do the analysis to break it down?"
"None"
And every ticket is complex, and the PM is annoyed that every ticket is being faithfully marked as such. But they balk at taking the time to try to plan out that high level goal to enough extend that we can break the ticket apart into smaller pieces that make sense, or just make it an epic because it is one and add tickets to it as we figure out how we're going to implement $todays_insanity_from_higher_up…
I remember reading the agile manifesto around '99 or so (back then it was called XP, "extreme progrmming") and then, after having worked in software for going on 10 years, it was a breath of fresh air. I couldn't believe that logical, rational, sane principles of software development were not just being proposed by influential voices but were actually being considered by managers.
It took about a year for disillusionment to settle in. Everybody seemed to come away from that document with a completely different interpretation and in most cases that interpretation was, "do exactly what we've always been doing that never worked, but add even more meetings on top of it."
One thing that no big-A "Agile" document has ever spelled out clearly is that the sort of agility can't work with fixed delivery dates. (Nor can any other software design methodology, but that won't stop "stakeholders" from insisting that because fixed delivery dates are Very Important, they're not just achievable but easy and you're just stupid).
It took about a year for disillusionment to settle in. Everybody seemed to come away from that document with a completely different interpretation and in most cases that interpretation was, "do exactly what we've always been doing that never worked, but add even more meetings on top of it."
One thing that no big-A "Agile" document has ever spelled out clearly is that the sort of agility can't work with fixed delivery dates. (Nor can any other software design methodology, but that won't stop "stakeholders" from insisting that because fixed delivery dates are Very Important, they're not just achievable but easy and you're just stupid).
I mean, Agile just can't work at all, because it conceives of only one part of a business without considering all the other parts.
I would prefer we popularized Deming's 14 points. That at least is achievable, and considers the whole business.
I would prefer we popularized Deming's 14 points. That at least is achievable, and considers the whole business.
[deleted]
I wrote an article on a specific part of scrum/agile: estimation and why most organisations are ruining team morale.
https://www.lloydatkinson.net/posts/2022/one-teams-eight-poi...
https://www.lloydatkinson.net/posts/2022/one-teams-eight-poi...
Something I don’t understand about standups.
Why should anyone wait until the standup itself to reveal blockers?
In my experience the team reveals blockers as they arise and someone usually finds a solution for them within 30-60 mins. There’s rarely an instance where there are pending blockers during the standup.
Why should anyone wait until the standup itself to reveal blockers?
In my experience the team reveals blockers as they arise and someone usually finds a solution for them within 30-60 mins. There’s rarely an instance where there are pending blockers during the standup.
Can someone explain to me the point of a sprint? How about "there is some work available to do, and you do it as you become ready"?
Am I supposed to be working longer than 40 hours this week to finish the work arbitrarily assinged to this sprint, because if so you are absolutely fucking off your rocker.
Am I supposed to be working longer than 40 hours this week to finish the work arbitrarily assinged to this sprint, because if so you are absolutely fucking off your rocker.
The point of having sprints is to trade off some utilisation for predictable delivery.
I.e. everything should be easily deliverable within a given sprint, to the point that almost everyone is idle (or working on non-sprint activities) by the end of it.
In practice successful scrum teams might get 90% of their tasks done a sprint - if that's not happening you need to commit to less each sprint (fewer points or fewer estimated days) until it does.
I.e. everything should be easily deliverable within a given sprint, to the point that almost everyone is idle (or working on non-sprint activities) by the end of it.
In practice successful scrum teams might get 90% of their tasks done a sprint - if that's not happening you need to commit to less each sprint (fewer points or fewer estimated days) until it does.
[deleted]
This is a weird article. There's a lot of rhetoric, and I especially take offense to the framing:
> creating your own version of Scrum is a rite of passage for engineering managers [...] usually result[ing] in catastrophic failure
The whole point of a framework is to adapt it to the specific context in which it is applied. This reads like a scrum apologetic, proclaiming that if your scrum is not working, you're not doing True Scrum.
Then the second part of the article is "pointless" practices of Scrum. Which is it--should we create our own version of Scrum, or should we not?
There's no hard data or evidence. Not even anecdotes.
Overall, it looks like someone applied a light layer of css over
["part I like about scrum", "parts I don't like about scrum"]
> creating your own version of Scrum is a rite of passage for engineering managers [...] usually result[ing] in catastrophic failure
The whole point of a framework is to adapt it to the specific context in which it is applied. This reads like a scrum apologetic, proclaiming that if your scrum is not working, you're not doing True Scrum.
Then the second part of the article is "pointless" practices of Scrum. Which is it--should we create our own version of Scrum, or should we not?
There's no hard data or evidence. Not even anecdotes.
Overall, it looks like someone applied a light layer of css over
["part I like about scrum", "parts I don't like about scrum"]
I talked to my supervisor because we're supposed to be doing Scrum but we're not doing the most important parts, namely sprint planning or retros. It's amazing to witness, coming from a team that did Scrum perfectly and functioned like clockwork.
That's very funny!
I've seen and participated in both unsuccessful and successful Scrum projects.
A lot of time it's susscess comes down to company culture and the combination of filling the role of Scrum Master, Product Owner, and Solution Architect supporting the team.
I've seen and participated in both unsuccessful and successful Scrum projects.
A lot of time it's susscess comes down to company culture and the combination of filling the role of Scrum Master, Product Owner, and Solution Architect supporting the team.
So far I have learned that Scrum can work, but only if the CEO personally wants it to and they have someone spending time with them explaining what every level has to do differently and expect differently for it to work. Partial successes can be won from the bottom up approach, but they are far less impactful.
This part of the essay admits that everyone tends to have their own interpretation of what Scrum means, and success actually comes down to whether you have the correct interpretation:
"Creating your own version of Scrum is a rite of passage for engineering managers. Both cases usually result in catastrophic failure, followed by tears and despair."
I've seen a variety of Agile approaches work well for some project managers but fail miserably with other project managers, which leaves thinking that it comes down to the person in charge -- if something only works when a certain person does it, maybe the observed effect comes from that particular person, and not the formal methodology that was nominally adopted for the project?
I've spent many years doing high level consulting, with multiple startups, which has been a great education for me because I've had a chance to observe a large number of different development methodologies. And while I've seen success with many of these methodologies, I've also seen failures, and the difference always seems to come down to who is charge, which makes me think the success or failure really depends on the leader and not the development methodology.
To put that differently, I have not seen any methodology that reliably leads to success, but I have seen certain project managers who reliably deliver success, and I suspect they could switch to different development methodologies and still deliver success. Therefore the development methodology doesn't seem to matter much.
I've only seen one rule that has consistently been true, and which grants a certain flexibility and agility to the development process:
"Small meetings are more productive than large meetings, and one-on-one meetings are the most productive of all."
I wrote about this here:
"Truly Agile development revolves around one-on-one meetings, not daily standups"
http://www.smashcompany.com/business/truly-agile-development...
"Creating your own version of Scrum is a rite of passage for engineering managers. Both cases usually result in catastrophic failure, followed by tears and despair."
I've seen a variety of Agile approaches work well for some project managers but fail miserably with other project managers, which leaves thinking that it comes down to the person in charge -- if something only works when a certain person does it, maybe the observed effect comes from that particular person, and not the formal methodology that was nominally adopted for the project?
I've spent many years doing high level consulting, with multiple startups, which has been a great education for me because I've had a chance to observe a large number of different development methodologies. And while I've seen success with many of these methodologies, I've also seen failures, and the difference always seems to come down to who is charge, which makes me think the success or failure really depends on the leader and not the development methodology.
To put that differently, I have not seen any methodology that reliably leads to success, but I have seen certain project managers who reliably deliver success, and I suspect they could switch to different development methodologies and still deliver success. Therefore the development methodology doesn't seem to matter much.
I've only seen one rule that has consistently been true, and which grants a certain flexibility and agility to the development process:
"Small meetings are more productive than large meetings, and one-on-one meetings are the most productive of all."
I wrote about this here:
"Truly Agile development revolves around one-on-one meetings, not daily standups"
http://www.smashcompany.com/business/truly-agile-development...
By pdf certified scrum masters who have nothing else to do but bastardise agile.
I don't think you need to distort Scrum for it not to work.
I've been working in Scrum based frameworks for the past 8 years in different jobs. Learned from the teams practices and Scrum Masters.
Only this year did I decide to actually read the Scrum Guide. I was never in a team that practiced it like that. All of them had stuff changed and reading the guide I was confused because the changes seemed for the worse. I feel like this is mostly the experience for people when they describe Scrum.
Only this year did I decide to actually read the Scrum Guide. I was never in a team that practiced it like that. All of them had stuff changed and reading the guide I was confused because the changes seemed for the worse. I feel like this is mostly the experience for people when they describe Scrum.
> Just like creating your own front-end framework is a rite of passage for web developers, creating your own version of Scrum is a rite of passage for engineering managers.
Excuse me, what? I've worked in web development for years and I personally know 0 people who have written a front end framework like React, View.js, etc.
Excuse me, what? I've worked in web development for years and I personally know 0 people who have written a front end framework like React, View.js, etc.
I don't see any evidence that Scrum works. All the proclaimed good parts (standups, sprints, retros) can be done asynchronously on as required basis instead of synchronously/periodically and a decent manager is able to coach/remind people to do so. Making them synchronous is often very distracting.
The benefits of Scrum is not really Scrum itself, it's to have a standard by which to measure oneself. If you can say "this way is better than Scrum", great! But if you don't know any kind of methodology and are just winging it, you would be better off with Scrum 99% of the time, because it does, at the very least, enforce discipline through routine. Companies who don't have a measuring stick are likely to spend wayyy too much time on procedure tweaking. Speaking from experience.
Having this standard also allows you to tell stakeholders "actually, this is normal for this industry and I can prove it", which is invaluable when they're not very technically minded.
Having this standard also allows you to tell stakeholders "actually, this is normal for this industry and I can prove it", which is invaluable when they're not very technically minded.
You're not really addressing the claim, which is whether or not Scrum actually works, i.e. is an improvement over any other method. I am not aware of any empirical, experimental or theoretical justification.
Anything you currently practice can be used as a yardstick. However, I don't think that practitioners should be spending time on this research. That IMHO leads to exact problems that the article whines about.
The idea that retrospectives are akin to scientific method is laughable. Maybe in 18th century that would fly, but there is lot more to scientific research than "continue doing what works and change what doesn't" (at the very least, following observations without theory leads to cargo-culting, which actually sums up the overall Scrum experiences pretty well).
Anything you currently practice can be used as a yardstick. However, I don't think that practitioners should be spending time on this research. That IMHO leads to exact problems that the article whines about.
The idea that retrospectives are akin to scientific method is laughable. Maybe in 18th century that would fly, but there is lot more to scientific research than "continue doing what works and change what doesn't" (at the very least, following observations without theory leads to cargo-culting, which actually sums up the overall Scrum experiences pretty well).
I'm not addressing your claim because I suspect it's not the main reason people use Scrum, in practice. I'm saying it's a political tool, and any debates around its "effectiveness" are pointless as the real benefit is keeping management away. The efficiency gains that you discuss would be pennies on the dollar in comparison.
There is no evidence that Scrum is better than informal SDLC. If it was possible[1] to scientifically compare them, my guess is that Scrum will be net negative.
--
[1] unfortunately it's either impossible, or very expensive. I've seen cases at large companies when the same project was handled to two different teams as a competition, but in that case they used different technologies, not different SDLC methodologies.
--
[1] unfortunately it's either impossible, or very expensive. I've seen cases at large companies when the same project was handled to two different teams as a competition, but in that case they used different technologies, not different SDLC methodologies.
Every time someone criticizes scrum/agile, "No true Scotsman" is the most common response.
https://en.wikipedia.org/wiki/No_true_Scotsman
There’s two good things about agile/scrum: breaking work up into manageable chunks; and having daily check-ins to make sure people aren’t doing the wrong thing for months on end. The rest can be ignored.
> You’ll know you have successfully ruined your standups when they’re taking thirty or more minutes, and your whole team hates them to the point they won’t do it if you’re not present.
(Involuntarily shudders due to flashbacks.)
(Involuntarily shudders due to flashbacks.)
> The problem with Scrum is that it usually works
This was the first line of the article, and I immediately closed the tab because that is a dead-wrong claim. Is the rest of the article as ridiculous, or does it become worth reading?
This was the first line of the article, and I immediately closed the tab because that is a dead-wrong claim. Is the rest of the article as ridiculous, or does it become worth reading?
Using it at prescribed is all you need to do.
you know what's even better? just talking to who you need to to get your job done. and if you're responsible for the group and someone looks like they are dropping off the map...just synch up with them
I think this point is missed in the implementation of these systems.
Give the people doing the work the responsibility for the work and the authority to chase down and "demand" answers they need to get the work done. If that can't be achieved, then maybe you need a meeting where the manager is involved. No need for daily meetings with reports of "same as yesterday". No need to to wait for a meeting before getting advice on how to unblock something. Just get on with what needs to be done.
Give the people doing the work the responsibility for the work and the authority to chase down and "demand" answers they need to get the work done. If that can't be achieved, then maybe you need a meeting where the manager is involved. No need for daily meetings with reports of "same as yesterday". No need to to wait for a meeting before getting advice on how to unblock something. Just get on with what needs to be done.
I actually cant understand the point the author is trying to make. For instance: what is his stance on retros?
A: Use Scrum
What’s a good alternative to Scrum?
1. Shape Up method, for feature delivery at a small product-led company (e.g. SaaS startup)
2. mini-Waterfall: design -> plan -> build (iterate) -> ship - for platform/infra, or any other heavy engineering work
3. informal SDLC combining modern best practices in SW Engineering
4. Kanban for reactive work (bug-fixes, maintenance, QA, support, ops, etc.)
5. RUP (Rational Unified Process) for Mission/Safety critical systems
6. GROWS method - more like a collection of patterns / best practices
7. The GIST framework (Goals, Ideas, Steps, Tasks) - mostly about product management, but can be combined with Kanban
There are many others, but they're either lacking communities (i.e. used by a single company only, no books/courses), and/or IMO not very good.
2. mini-Waterfall: design -> plan -> build (iterate) -> ship - for platform/infra, or any other heavy engineering work
3. informal SDLC combining modern best practices in SW Engineering
4. Kanban for reactive work (bug-fixes, maintenance, QA, support, ops, etc.)
5. RUP (Rational Unified Process) for Mission/Safety critical systems
6. GROWS method - more like a collection of patterns / best practices
7. The GIST framework (Goals, Ideas, Steps, Tasks) - mostly about product management, but can be combined with Kanban
There are many others, but they're either lacking communities (i.e. used by a single company only, no books/courses), and/or IMO not very good.
:))))
Dailys take 1 Hs, where people try to show off. Retros take 3Hs and is all about finding "who is guilty". PI plannings take 2 day, and consistently in the first week after planning we realise the whole planning cannot be realised for whatever reason. Backlog is always 100+ entries, that we leave there "just in case". PO does not work in the team, he is just the BOSS. We goes every day behind you pushing that you fill in the status of the task in our Track-n-release. The track and release tool is there to supervise the work being done, so there are very specific guidelines on how to fill the comments and when. The "velocity" is used to evaluate the people.
Great place to work!!!