How to distort Scrum until it no longer works
lucasfcosta.com
lucasfcosta.com
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!!!
* 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.
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}
1) it was RUP, not waterfall (RUP is basically many waterfalls in parallel)
2) they were dead fucking serious.
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...
Just look at the acronym itself!
It tells those managers at Big Corp that it is finally safe to implement Agile!
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.
And it's a competitive sport. It might not be healthy, but that's how you win.
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.
Hell, in this analogy even the marathon organizers don't know the destination. Or much care.
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.
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
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?
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.
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" ;)
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.
You could measure engagement, conversion, churn, or any other meaningful metric. The main point is shortening feedback cycle.
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.
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.)
Why's it have to be a marathon in your mind? Any race - doesn't have to be that literal.
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.)
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 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)
> 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.
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?
And then you describe some of the healthiest standup culture I've seen...
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 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.
(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!
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.
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.
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.
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.
“We enforce agile” is just a huge red flag and and an indication that the organisation is “doing Agile” instead of being agile.
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.
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.
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.
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.
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
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.
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.
Having management present can subconsciously push people to turn standups into a productivity contest.
"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?
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.
And for every minute you ran late, you had to do a push up.
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?
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.
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.
that's the essence of the Agile™, Scrum® and SAFe©
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.
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.
> 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.
If there are issues, you handle them outside of the daily scrum, it's not a troubleshooting session, it's a status update.
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...
> 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.
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.
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.
At least until the next big thing comes along and they will declare agile to be just as bad as waterfall.
It seems to me that if everyone does it wrong, then it is not a good fit for how people actually work.
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.
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 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 :)
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.
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.
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".
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.
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)
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.
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.
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.
"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".
"How much time do I have to do the analysis to break it down?"
"None"
(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.
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 would prefer we popularized Deming's 14 points. That at least is achievable, and considers the whole business.
https://www.lloydatkinson.net/posts/2022/one-teams-eight-poi...
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.
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.
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.
> 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'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.
"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...
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.
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.
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.
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).
--
[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.
(Involuntarily shudders due to flashbacks.)
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?
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.
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.