We moved from sprints back to work queues for exactly this reason. Output is exactly the same but no one is cutting corners to "finish" the sprint. We still use a kanban and do estimation the same exact way, but rather than arbitrary deadlines, devs are trained and encouraged to communicate on their velocity in a way that is far more effective than a daily standup.
Scrum was an idea that had its time, but after like...15 years the limitations are apparent.
The main value of stressing about sprint goals and what's "in" a sprint and finishing it is the very specific situation of there being a bunch of people who want to feed in a large amount of work to a team (usually bugs/support requests/operational work) and it results in constant prioritization issues.
If you don't have that situation, you probably don't need to be really careful about what's in a sprint.
Kanban lets you prioritize exactly the same way, except it doesn't have to fit into a sprint schedule. You also have to make good stories, which are independent, have a meaningful thing that gets delivered and are of a reasonable size. Then important bugs can get moved to the top of the to-do column, and get done quickly as possible without interrupting any in-progress work.
Problems with Scrum: It's nice that you did your planning poker, but all these tasks need to be ready by the end of the month regardless.
Problems with Kanban: It's nice that you set priorities to the tasks, but all of them need to be ready by the end of the month regardless.
Conclusion: If there is more work than people can realistically do, and it all needs to be done no matter what, it doesn't matter what process you use; people will be stressed and burned out.
> do estimation the same exact way, but rather than arbitrary deadlines,
The core problem with that is that effort - consciously or not - gets immediately turned into (start day + estimate) => deadline which only works when you consider spherical cows, not accounting for the hard true practical fact that reality is messy.
And it is quite messy, by the very nature of the work which is to do something that has not been done before (otherwise by the very nature of software you'd just reuse it) and thus carries unknown unknowns. Everyone has experienced this "one-line fix, should be done tomorrow" that turns into a bind-mending multi-week hunt down the rabbit hole; replace "fix" with "feature" at your discretion; replace rabbit hole with "that very urgent task preempting anything else".
The second-order problem is that deadlines are used to schedule higher level dependencies between teams, all the way up to product, and possibly customers, and then it becomes the coupling interface and everything falls apart when there's a delay that inevitably trickles up with rippling consequences, because the system is not designed to handle such a failure mode, having this deadline dependency as its core interface between all the parts.
If you're not convinced of that, "follow the money": the consistent metric across the software industry to evaluate an employee's performance boils down to "deliver on time". Three months down the road, the rational explanation to delays of mandatory rabbit holes and very legit preempting tasks is forgotten, even when acknowledged by management. You're told to factor all that in, but estimating unknown unknowns is by definition impossible (best case you go statistical, with deadly outliers around the corner, which amounts to say it's a bet). Experience reduces these unknowns but they're still around, everywhere. Overall, you tried telling the hard truth with absolute candor were left helpless when it backfired.
Ultimately, whatever the process, the stark reality is that to get shit done you have to take part in the make-believe dance and lie - white lies, because soon enough one realises that the other kind of lies also backfires very quickly - in a way that still communicates some form of deeper truth: "progress is being made, it'll be done (when it's done)". Inflate some numbers, tune wording when reporting, steal time by bleeding some for task X (reported or skunkworks) into task Y. All the reporting meetings and documents entirely become smoke and mirrors, but are somehow important as they're oil to the whole machinery. Two parallel universes emerge and graciously evolve in parallel.
This sleigh of hand is the missing buffer catering for the lack of acknowledgment that producing software is entirely different in nature than producing hardware in a factory. It is in essence more of a creative act, albeit a strangely misleading one because of its technical component. Lots would be amazed as to how much closer it is to advanced drawing or musical composition than it is to more "material world" engineering (although the rigorous process of the latter certainly helps for technical aspects), and taking classes of the former would probably do a lot of good.
I've learned to hate software process. If you have team sizes set sanely and empower devs to do what they need to do in order to accomplish the goal, they'll be fine without the management overhead of arbitrarily imposed productivity flow. Agile et al, along with 99% of the features in ticketing systems, exist to make managers feel like they are justifying their paycheck.
If you are a manager and this makes you angry, you're one of the bad ones.
Just keep in mind that a lot of people equate Agile with Scrum, which is incorrect. Agile is about exactly what you said: empowering devs to get shit done. None of the extra “keep managers happy” crap that Scrum introduces is in any way covered by the Agile manifesto.
Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff.
As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we don’t deal with any of the above shit. Which of course is sure to change as the company grows, as that seems to happen often.
Our current way of working (remote company, 4 people):
- 2 calls a week, which tend to last about an hour.
- We discuss work for upcoming week or future stuff.
- We try to deliver every week on whatever was agreed upon at start of week.
Actually, previous company I worked at, was a bit bigger (35 people), but also very little rituals, at least for devs. There was a support department that did the JIRA related stuff. And we had like 2 day-long meetings every year to discuss personal goals/work for next half year. But afterwards just a short weekly meeting for team (sometimes lasting only 10 minutes), no stand-ups and such.
The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship.
Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to have them requested by my teams. Who knew.
As a developer, I find retros most useful when EMs (and probably PMs, depends on how things are configured organizationally) aren't present, as it should give a chance to talk freely about challenges you or the team face, which often are organizational in nature and may involve one's management chain. My current role doesn't adhere to this, and it makes retro often really painful.
I would agree with you. I never want my manager there. As an EM, I never want to be there. And yet, as the years go by, when I have an EM role I find my presence is requested. Again, who knew?
I don't know, at least for my current team a lot of the stuff we complain about in the retro is beyond the team level: coordination between teams, infrastructure issues, ... The intra team issues are usually talked about before (e.g. during standup, or just asynchronously).
If the EM is not there, those are not actionable. What we try to do is: do the retro by ourselves, and invite the EM at the end of there is stuff for them. Usually they are not available though...
Retros all too often focus on the last thing that happened and risk turning into a complaint session.
I've told my team anyone is welcome to ask for a retro whenever for any reason, but we don't make them recurring meetings because there is too much of a temptation to find something wrong to fill the time.
This is exactly why I hate retros. It's just a venting session. We're going to whine about some things, of which we have absolutely no power to change, and somehow that changes the future.
But people seem to love them.
I'd prefer to spend that time putting my head down and grinding through whatever sucky thing people were otherwise whining about.
Best retro I ever had, on a small team of seniors: we all sat down, looked at each other, agreed that a sprint happened and we couldn't think of anything that was good or bad about it. Then we called in our manager, who also acted as scrum master, so we could do planning for our next sprint. I thought this was reasonable enough - ostensibly we'd do retro and then planning back to back, and none of us minded the chance to take a few minutes and reflect if we had anything we should discuss.
By contrast, I've worked with scrum masters who were strict about the process and insisted _every_ retro needed to have at least one improvmenet or action item out of it, preferably more. I found this pointless and I've rarely seen them actually followed up on.
When I started at my current job, I naively looked at the bugs and tasks assigned to me, and started picking and fixing the highest priority tickets.
Then I was informed, "Oh no, that's not how we do things here. Don't look at the priority, just work on what is assigned to you in the current sprint."
I had never heard of sprints before.
More recently, I had a conversation with my manager and asked, "Do we really need sprints? I've been in this business a long time. 10, 20, 30 years ago we didn't have sprints and somehow still managed to produce great software."
The reply was "But if we didn't have sprints, how could we possibly measure the team's productivity and individual productivity?"
I knew I wouldn't win this debate, so I politely let it drop. I just wanted to sow some seeds of doubt.
In all fairness, my manager is a very reasonable person. But when this devotion to sprints is ingrained in the entire company, it is hard to question it or get away from it.
That's normal nowadays, even in the most ridiculous of situations.
I once found that a system was getting a little expensive. As, AWS was billing us a million a month expensive. I figured this out, and came up with a plan that would cut it down to 80 thousand by spending 4 days: You know, a mild, 11 million a year of savings. Management insisted that the work had to go through scheduling, and intake, a process that would involve zero developers looking at anything, but would delay doing the task a month and a half.
And no, nothing the team was working on came even remotely close to that ROI. Following the process just cost an extra 1.5 million dollars.
Good points, and eye-rolling stuff for teams thaqt don't understand the intricacies. For instance:
- burn-down / velocity charts: Teams use this at standups to make sure their sprint isn't drifting. That's why a burn-down should be tracked in hours and not points. With points, the data isn't actionable in a reasonable amount of time. The the team sees a problem, they might make use of a pre-determined emergency procedure to address it.
- retrospectives: Yeah most retrospectives are horrible. Retros should be like post rocket test - examine your telemetry deltas to see what changed (edge cases, governance,compliance, desgn, etc.) These conversations are not forced, but good teams always repeat the same data analysis unless they intentionally change it.
- poker sessions: Yeah this is totally misunderstood. Pointing stories is about snap reactions to comparing difficulties and complexity, and that's it, move on. Teams will tighten up estimates when they do an implementation plan in sprint planning. So they don't sweat estimates.
- daily stand-ups: The whole team is responsible for the sprint backlog, nothing is assigned, everything is volunteered. So if you're working on something that is going south, or you have some extra capacity, let your team know about it. The team will work together to scale capacity to get things done, which is how they can disappear on Friday afternoons.
- user stories and related tickets (eg in JIRA): Well yeah, Jira sucks. So do all the other major backlog tools. Jira gets addins, but the fundamental approach to backlog development hasn't changed in a decade. (I'm working on a soln from scratch, btw).
Also, user stories are meant to be work-items with enough signal so they can be executed with certainty in a sprint. So that means a lot of refinement to the left of the story must occur to get rid of the noise (epics to features to stories to tasks). Once a team says a story meets their definition of ready, that story can be scheduled for a (timely) sprint. Team members may be doing hard-core story refinement because of some technical hurdles, so their time outside of development during sprint can be pinned down with the team's capacity plan. BTW, capacity plans and implementation plans belong solely to the team. They're nobody else's business, including managers to CEOs.
Sure, comes from a prevailing view that estimating is bad. But it's only because estimating is treated like the answer, then we just go with that answer.
The best scrum teams I've worked with maintain a very important survival notion: We don't know the full minimum survivable solution today, but that's ok because we do know enough to get to tomorrow at least. We survived another day. Point is, estimating was never meant to be an answer. It was just meant to kick off discovery. And that's a great way to start because humans tend to be exceptionally good at quickly comparing things for difficulty and complexity. It's an instinctive survival skill.
Ultimately, well after estimating this scrum team will do an implementation (tasking) plan in hours if needed during sprint planning. They will compare that plan against their team capacity plan in hours. If the implementation plan blows out the cap plan by say, 30% then that's a warning sign and they'll tell the PO they need to drop a story for the upcoming sprint. If the cap plan compared against the imp plan shows a 30% surplus, then they will pull in a stretch story and bump their velocity, or won't tell the PO and maybe go play golf at the end of the sprint.
So the story pointing exercise just gets the team some data that helps them get to the next day (survival speak). There's still a lot of story refinement to be done, before they will tell their PO a story is ready to be pulled into one of their sprints.
When teams pull in stories to their sprint backlog, the team is committing to get that story done, so they need immediately actionable data on what's going on at every standup. If the burndown was done in points, the graph ends up looking like a straight line for days with sudden dropoffs toward the end of the sprint - that hides problems. So a sharp team will use task hours instead. Makes the plot a lot more actionable from day to day.
No, the prevailing view is estimating in hours is bad, hence the push for estimating in t-shirt sizes or other stand-ins for task complexity.
The survival terminology is really off-putting. And what’s the obsession with golf? This doesn’t sound like any scrum team I’ve worked with or would want to be a part of.
Well, a rather xor response, but that's ok. Let's go a different route: Someone is using a diet change (fixed), and the elliptical machine to lose weight. This person has no exercise background. The elliptical routine is basic - same program, one hour a day, 8 weeks. BF test is done at the end of each week. Graph the results. What do you think the plot will look like? Why did the subject's weight loss stall out?
Estimations are meant to be exactly that, estimations. Don't try to make them anything else. They offer a grey answer, so use the best tools you have to deliver that grey answer. In this case, it's simply comparing challenges for size, complexity, etc. Don't try to do estimations in a different way just because you want an immediate answer. Estimations are meant to be a starting point to get to a minimum survivable solution. That's how humans use instinctive tools that use the least amount of energy to get to a point that they can survive a challenge. Think about the elliptical example.
In scrum, estimations are the conscious way to get this discovery kicked off; they aren't meant to be an answer, because you don't have enough data yet for a solution. They are meant to be a starting point. Iterate to the solution. When you think you have enough signal for a solution (the sprint), do your final check and balance, which is a tasking plan in hours, during sprint planning.
Another example: The year is 1929, and you're asked to guess the weight of the Empire State Bldg before construction has even begun (1931). What answer delivers more survival information? 180,000 tons, or this: "Well, we know each floor is going to have x concrete, y steel, but not sure about the other construction materials. So it will be something like (x+y+?)*#floors. If your life depended on it, which answer would you go with?
You are looking for a number, and that's why people don't understand what estimating is about. The incorrect approach is like, "Well these estimations are crap, so let's change the estimation methodology." Yeah but it's still and estimation, and you already have a great instinctive tool to make those estimations via relative size comparison, which can be done so quickly, it could literally save your life. Instinctively, we accept that, conscoiusly we don't, so we turn into ill tempered Veruca Salt.
Regarding the golf reference, I'm from Florida. Sorry if the attempt at levity was weak.
You need some coarse odometer to know where the finish line is. Burn-up charts are a reasonable input to that and can be very low effort. Just knowing where you hit the inflection point between new-issues added to a milestone vs. issues resolved is useful. If you can replace a burn up chart with tangible test results matrix or similar - even better.
> retrospectives
I have never found per-sprint retros useful, either. I guide teams to do a retro when the issues raised in the previous retro are resolved. WIP control FTW.
> poker sessions
In my experience, planning sessions are one of the most impactful parts of the stereotypical scrum process for three reasons: (a) Planning creates a consensus within the team about what the story actually means; (b) Planning often leads to someone proposing a good 80/20 trade-off or raising an important point that avoids future re-work or unexpected tech debt. (c) Breaking big tasks into actionable, independently useful, small tasks is one of the hardest things for junior developers to learn. A lot of mentorship and teaching happens in good planning meetings. I encourage teams to try planning for the benefits of the process and not worry at all about fine grained points - "trivial", "medium", "unknown" is typically enough. Lots of mature teams will plan ad-hoc as they are ready for new work. This is my personal preference. But teaching teams how to plan effectively in a weekly planning meeting is often a good starting point.
> daily stand-ups
Standups that are control points for managers and expensive status gathering shortcuts are horrible. standups that are self-organizing, especially for teams that have ops + dev responsibilities, can be really useful. Nothing wrong with making a plan for the day - it should just take 10m.
> user stories and related tickets (eg in JIRA)
You should write down what you want to do somewhere and a few checklists go a long ways towards improving quality management.
I have never found scrum to be a good process (like the article, I find it very grinding) and I strongly agree with the posted article. But a good dev process likely includes all of these elements in some shape.
Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of work will always get done, without any free time being wasted.
A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent on these ceremonies (sprint planning 1 hr, sprint retro 1 hour, daily standup 15-30 minutes. Plus whatever prep is needed and the interruption time.) For many companies this is a 20% or more overhead that's mainly busywork because you still need the additional meetings to understand what you're working on.
This may sound like a no true Scotsman argument, when our company was trained by one of the scrum founders about 18 years ago, they were very clear that the daily standup was only for the team members, and the scrum master. (The scrum master could be a team member, and rotate btw). Managers were not allowed or invited to these. The only thing product managers and engineering managers would participate in and give feedback was in Sprint demos, and the beginning of planning meetings to answer any questions on upcoming stories.
At the time it was incredibly freeing and fixed a pretty awful and behind waterfall project. I was (briefly) at a startup a couple years ago that said they "did Scrum" and what a clusterfuck that was - all the managers meeting daily with devs to see if they were behind and scold them if they were. See ya.
But Managers as the center of the scrum is how many, many tech companies the outside world wouldn't call crappy run things. They also use Jira, mostly because they want reports that let people two or three levels up think they have any control over anything.
One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another.
In practice, I don't think I've seen scrum run without a manager in standup, ever.
> Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status.
The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.
That's hard to imagine. In big tech it's the team manager who decides that standups should happen and when (maybe this is an expectation from higher-ups). He always joins unless running late.
Be that as it may, if the scrum guide explicitly says they shouldn't then it isn't really fair to blame scrum for that.
Honestly, the recurring complaints with scrum, agile, etc basically boil down to this: shitty organizations can make any system miserable. People generally are blaming the intermediate cause (how we do scrum sucks) rather than the root cause (our company sucks and nothing would work).
Man, I agree with your specific criticism of the "No True Scotsman" refrain and with the larger criticisms of scrum, but this is an example of scrum prescribing X and companies doing !X, the literal opposite.
How could scrum, the product, possibly be to blame for that even if it sucks? Or, at what point is it reasonable to blame the PM/leader for actively and knowingly practicing !$scrum while pretending it's $scrum?
Companies try prescribing X, but as developers have no reason to care X doesn't happen without strict oversight by management, thus leading to !X to keep them in line.
Is the gun with a 180º bend in the barrel, with a caution label that says "WARNING: Don't shoot yourself in the face", that sees everyone who tries using it shoot themselves in the face the user's fault, or could we say that the product is faulty?
If a product relies on weasel words to try and pass its flaws off as being the user's fault, at what point is the product to blame? If one person uses it wrong, perhaps you can say that one person was doing something out of the ordinary, but when every person uses it wrong...?
To be fair, it probably also works in practice, but by very definition post-scarcity is a necessary precondition. And that is still an ongoing effort that has never been realized. Granted, the UN has declared food to have achieved post-scarcity status so clear progress is being made, but we still have more work to do.
I've lived the first 14 years of my life under the Romanian communist dictatorship so no.
Let's put it this way. If it's the property of the people it's not everyone's in practice, it's no one's. So you're free to slack, cheat and steal from your "property of the people", you're cheating "no one".
> post-scarcity is a necessary precondition
There is no post scarcity. The goalposts for scarcity just move up.
> I've lived the first 14 years of my life under the Romanian communist dictatorship so no.
That doesn't make any sense. Communism's defining feature is that there is no longer a state. How can you recognize Romania, and especially a Romanian dictatorship, without there being a state?
Perhaps you're confusing communism with rule by the Communist Party?
- Communism is a work of science fiction that imagines what life is like in a post-scarcity world – indeed, science fiction that some people would like to see become reality. Star Trek is a more modern adaptation on the same basic idea, which you may be more familiar with.
- The Communist Party is a political group that, at least on paper, is focused on achieving post-scarcity through capturing the means of production. It was once theorized in a certain Manifesto about Communism that post-scarcity would not be achievable through capitalism as the capitalists would set up barriers to seeing it through, and that the way to protect against that was the bring the means of production into social hands. Hence why the Communist Party is so-named.
But that would be like saying that democracy doesn't work because you don't like what the political party known as the Democrats are doing in the USA. Or that workers don't work because you don't like what the National Socialist German Workers' Party (Nazi) did.
> There is no post scarcity. The goalposts for scarcity just move up.
Perhaps. But it remains that communism cannot exist without having achieved post-scarcity. How could it?
Yes. Communism's key attributes are that it is classless, stateless, and moneyless.
> Who takes all the resources and allocates them "according to each person's need" then?
We'd need to know more about how post-scarcity is achieved in order to answer that question. Star Trek says the replicator is responsible, although that seems unlikely outside of the imagined Star Trek universe. Based on what we can see today, I'd guess robots. But this is all speculative as we don't really know what post-scarcity truly looks like, or if it is achievable at all.
> Communism predates the idea of post scarcity by a hundred years or more AFAIK.
Are you referring to what is oft referred to as primitive communism?
Although I find it hard to believe that humans have ever not thought about post-scarcity. It seems like the first thought/dream anyone would have when first faced with scarcity constraints.
> Did communist utopians realize it doesn't work so now they're adding "post scarcity" to it to make it work?
Did TV fanatics realize that Star Trek doesn't work? What does this even mean? Communism isn't something real, it is a work of science fiction that details an imagined world after post-scarcity. Always has been, probably always will be.
Hell, even if we actually do reach post-scarcity some day, the chances of going the communism route are about as likely as us going the Star Trek route. Reality has a way of turning out quite different to what you envision. There is effectively no chance of communism becoming more than science fiction.
Is that what you mean by "doesn't work"? That it will never be more than science fiction? In the same way aliens, time travel, etc. "don't work"? Fair, I suppose, but that makes your communism obsession rather bizarre.
> "Based on what we can see today, I'd guess robots." Oh yea, "AI" is next.
How do you foresee AI being useful? Robotics is by and large how we've achieved post-scarcity in food production. If we were to achieve full-on post-scarcity, chances are we would do so by finding additional robot applications. We're not that creative as species. But who knows.
Are you struggling to say that Cuba will blame AI for allowing the USA to beat them to their post-scarcity goals? Perhaps. American innovation is unquestionably leading the way to communism right now.
If communism ever is realized as more than science fiction, it will almost certainly be because of the USA's efforts. There is no chance Cuba will get us there. Of course, their official claim of seeking post-scarcity is only for pretend to keep up political appearances. The USA, in contrast, is actually trying. You might say ironically, but I'd say that Marx just got it wrong and that capitalism, not socialism, is the most likely path to communism.
In my experience, if the PM isn't part of it, the standup doesn't happen, because no one else cares that much. If someone gets stuck on something or needs help we just send a slack message, no need to wait for a fixed meeting.
I said in another post that I hated all the ceremonies, including standup. And it goes without saying that means long standups.
But, one team I was one, we had long ass standup and it was perfect. It was very dev-driven, we were facing hard problems, and that was our time of the day to really nerd out. The PM would get bored after about 15-20 minutes and then we'd be working out how to deal with the issues that faced us. Sure, it could have happened at any point of the day, but that was our designated time where we were all in the office (this was pre-pandemic)
That seems unproductive. You end up having a room full of people discussing problems that should be solved by one or two people outside of the standup. That's contrary to what a stand up meeting should be. Don't do that.
Because in real world people play with the hand they are dealt with. Team hasn't quit because there are no better jobs with empowered developers are waiting.
The real question is why is the team putting up with this? They should be complaining about the PM and wasted time every chance they get, at the "retro", team meetings, and 1:1's... Complain, complain, complain.
That's the issue where the PM has so much power. In our company the engineering team dictates their process. They can do however they like as long as they ship the products on time.
> It may be explicitly stated, but I’ve never had a scrum meeting without all managers and project managers.
This, this, this and a thousand times this.
It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".
It's like when discussing communism with some diehard fans - when you point out the flaws, the response is always "well that wasn't real communism that's why it failed".
Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
That similarity is superficial. It is observing that no ideology perfectly survives implementation - which is true, but there is no alternative option so it isn't a useful observation.
We don't have any successful countries that use communist ideologies because central planning is destructive and the abolishment of private property is catastrophic. Calling for communism is tantamount to wishing for death and destruction. The path to success through communism is something like China where they eventually learned to do the opposite of communism and got great results.
We do have lots of successful companies using Scrum. They hire Scrum masters. They see Scrum as adding value. The scrum ideal is generally a bit of a compass towards higher value add. So scrum as an ideology seems to be net-successful even if implemented wrong.
>So scrum as an ideology seems to be net-successful even if implemented wrong.
How do you get to this conclusion? I haven't seen any implementation of scrum that didn't slow down development speed, due to unnecessary meetings and micromanagement.
This might be that I've only seen 8 or so "implementations". If there's any evidence that scrum is a key net positive I'd like to see it at this point.
Kanban IME can work well if the manager understood the core principle: Limit amount of concurrent work, use daily standup to prioritize work and unblock people hitting the multitasking limit.
Sadly this concept which is the core tenet of Kanban and can be explained in one sentence was still too much to grasp for some managers, but I've at least seen most Kanban implementations be either a net positive, or neutral.
I might be biased by my own experience, but I still need to see a Scrum implementation that doesn't grind productivity to a halt.
The company isn't optimising for fastest development speed. They typically optimise for low variance, consistent value in support of existing processes.
Interestingly, if you want highest value then for software it is best to use a high-variance strategy. But that is never going to come out of a company large enough to need professional management because it is pointless to manage large numbers of people to a high variance strategy. Google is an interesting case study where they tried that and, by and large, flopped. It makes more sense to spin out separate companies VC-style. I assume programmers occasionally quit companies, build something and sell it back to the company at extortionate prices which would be the right way to do fast development.
That isn't to say professional management is bad - large companies need it. It is just a fact that large companies aren't good at development and something like scrum elevates them from total failure to unproductive but fumbling in a good direction.
The funny thing is that "communism" is a highly overloaded term, with several very precise definitions, one of what is so successful that about every country currently implements and people that dismiss it are ignored and considered radical. (But then, nobody calls that one "communism" nowadays, the the people pushing the others will really hate you if you talk about it.)
While "scrum" is a proper name with a single definition that anybody can look that is absolutely not precise enough for anybody to follow. By definition you can't really do scrum right.
>It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".
Yeah, that would be the correct response. If we were discussing communism, and you started complaining that under communism everyone has to stand on one leg and hop up and down, a communist would correctly point out that hopping on one leg is not communism.
>Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
This is like saying that exercise isn't useful because most people who attempt it don't stick with it. Doing actual scrum is hard (particularly for managers), so a lot of teams can't stick with it. That doesn't mean it isn't useful.
> It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".
Scrum is a victim of semantic drift. The vast majority of people "doing scrum" have never read the guide and are just doing things that other people have told them is Scrum.
It's not Scrum's fault that people have hijacked its name for something completely different. It happens often.
What people call Scrum isn't really Scrum. What people call REST isn't really REST. What people call DevOps isn't really DevOps.
People using the wrong word for something doesn't mean the original definition of the word is invalid.
It's fairly different from the Communism situation in that people discussing Communism are generally talking about the same concepts and the debate is whether or not they're feasible. With the other terms I used above, people are using the same words to talk about completely different concepts with different definitions.
> People using the wrong word for something doesn't mean the original definition of the word is invalid.
It doesn't make the original definition invalid, but words mean what society uses them to mean, which changes over time.
So agile & scrum do in fact today mean constant status meetings, treating professional developers as mindless cogs and keep everyone in line with a constant stream of tickets chosen by someone else.
Perhaps it's not what it meant in some idealistic manifesto lost to history, but it is what it means to developers employed in the industry today.
Scrum (or agile) done wrong is a unimaginable nightmare (I actually do have first-hand experience with that). But, overwhelmingly, my experience with scrum has been nothing but sweetness and light. When it is done right, all the stress melts away. Seriously. Just an absolute joy.
Are those who have toxic experiences with scrum actually a majority, or are they just a vocal minority? I'm curious if there's any data on that.
> Scrum (or agile) done wrong is a unimaginable nightmare
I agree. The issue is that I have literally never seen it done "right". It doesn't practically matter what agile is theoretically supposed to be, it matters what it actually is.
> It's not Scrum's fault that people have hijacked its name for something completely different. It happens often.
Scrum contains so many pitfalls that it's inevitable to get it wrong. Oh, the Sprint Review is NOT a report to management? Please do tell me where this then happens instead. If a manager can attend a 1 hour meeting to summarize the 2-3 weeks that the sprint was about, it will be abused.
> People using the wrong word for something doesn't mean the original definition of the word is invalid.
Yeah, it's literally the worse thing you can do. I mean, not for the original definition of literally, but the new definition of literally, which is literally not literally, and actually literally in the dictionary with the definition of "not literally".
Just saying, at some point, the definition everyone uses becomes _the_ definition. And yes, I'm not a fan either.
I have seen teams actually do the Scrum-according-to-the-textbook, but those are rare. Most companies are just doing whatever their managers think is a good idea, and they call it "Scrum".
Ironically, the last time my team was doing Scrum-according-to-the-textbook, it was a decision of the developers... and then the higher management told us to stop, because the entire company decided to switch to "Scrum" (as in: endless meetings with managers present, no retrospective, but we call it "Scrum" because it sounds like we know what we are doing), so basically we had to abandon Scrum in the name of "Scrum".
My conclusion from this experience is that Scrum-according-to-the-textbook never happens as a top-down decision. The managers have strong ideas about how things are supposed to work, and they are unwilling to change their ideas, although they may agree to rename them to "Scrum".
I actually get the real-communism-has-never-been-tried vibe from people who say "scrum sucks, agile is the good idea". Scrum is simply what happens when Agile meets corporate reality. Make "agile" a popular buzzword among the managers... and soon you will see people complaining that agile in practice means endless meetings etc.
> It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".
Well, you are.
Give this shitty process you’re being forced to follow some other name and stop blaming Scrum.
Do Scrum properly and you’ll see why it’s actually fairly good.
> if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
You can’t say that as you’ve not actually done the thing.
The main problem is that most managers and senior company people feel like they want more control that scrum allows them to have, and their use their power to overrule it. That’s their problem and not the fault of the Scrum system.
You may be onto something with communism. It’s definitely not resiliant to the kinds of paychopaths that end up dictators for life. I wish I knew why. Probably something to do with threats of violence.
>It's like when discussing communism with some diehard fans - when you point out the flaws, the response is always "well that wasn't real communism that's why it failed".
Nitpicking, but the Soviet Union, for example, never claimed they were already a communist state. They were the "Union of Soviet Socialist Republics", not "Communist Republics". Their idea was that, to have communism, you must have a transitional form of government first, "socialist government". The USSR even once had a motto, "we will build communism by 1980".
It's like if someone said they were following some other development process which would eventually lead them to Scrum. But no one does that and just calls it Scrum :)
> Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
If your process to trim the hedges is much faster than normal, but also involves juggling chainsaws at the same time; it's possible your process is bad, because most people will fail to do it the way you've laid out.
(I'm agreeing with you, if that wasn't obvious... it's a pretty bad analogy, to be fair)
As someone who works in a hard-tech startup, where daily standups in production manufacturing teams are part of the daily culture.
1) Anything longer than 15 minutes is insane
2) What do you even talk about for an hour?
3) Why do you even do standups for design work? What "blockers" could you possibly have that require daily, 15 minute tagups with the entire crew?
On #2, nothing. People stay an hour trying to look busy because somebody on the meeting expect them to be busy and the meeting to be important. So they spend an hour talking about nothing.
On #3, blockers exist more on design than on operation. But the idea of a daily meeting to solve blockers is crazy-stupid. Imagine if operations did this, every time somebody's work get a wrong input, you'd stop their line until the next morning. That's why operations dailies aren't about blockers, and instead about information sharing. But design work doesn't have separate teams that need to share information, so they invent a bullshit reason to still have the meeting.
We once had 1 hour long standups. The reasons were:
1) large team
2) many devs loved to go into detail about their work, and no one stopped them
3) the expectation was that a standup must be about describing what you did yesterday, in detail
What we did:
1) split the team into subteams where each team has their own standup (down to 5-15 min)
2) the standup's facilitator now stops devs from going into too much detail, "you guys can discuss it further after the standup"
3) now the expectation is that a standup should be about checking the project status and if there are any blockers, and that's it, you don't have to recount your whole yesterday in great detail
> 2) the standup's facilitator now stops devs from going into too much detail, "you guys can discuss it further after the standup"
I said this in another comment, but a standup I'm part of tables these until the end of the call; and then anyone not involved in that conversation can drop off. It seems like a reasonable compromise to balance the need to get people together to discuss something against the need to not keep people tied up. It helps mitigate the issue of people not wanting to plan a meeting to just "talk about" something (when that's actually what is needed).
So I think one thing that seems to pop up in people’s anecdotes is “well someone wanted to just talk about what they did yesterday.”
Which I suspect comes from the manager/PM going “so what’d you do yesterday?”
I’ve been taught, and I teach others, that in the standup you drive the questions. Usually along this framework:
1) I assigned you Task A yesterday. Did you finish Task A?
2) If yes, awesome. I have Task B for you. Or, go help Bob with Task C.
3) If no, cool. Why? What happened? Is there anyone in this circle that can help you? How can I help you.
4) Open Ended Questions/Comments that we need to circle up on later
5) General Announcements
15 - 30 minutes depending on the size of the team, scope complexity, etc. No one should be talking for more than two minutes. If whatever they need takes longer than 2 minutes, that’s taken offline and a flag something is wrong.
If you’re going to treat the software development like a factory, you must assign and manage work like a factory.
If you’re going to treat it like magazine publishing, you must assign and manage work like a publication.
Pick one. And stop having hour long standups y’all are crazy.
> If you’re going to treat the software development like a factory, you must assign and manage work like a factory.
What you described above is more like kindergarten, which is why any sufficiently seasoned developer hates Scrum with all the passion they have. It is mostly belittling, humiliating, and not even very productive at the end.
Interestingly, Scrum almost always ends up like being in the kindergarten, instead of addressing the real pain points, as it should be (eg. involve the business in the development process). But that takes real effort, which is hard, and therefore no PM or manager is interested in.
>What you described above is more like kindergarten
You ever try organizing and managing the work of multiple skilled tradesmen that feed into a single integrated product on tight deadlines? Do you know what works really well in that kind of environment?
Telling people what to do and then checking in on them to see if they’re doing well.
Is this kindergarten? I don’t remember being a skilled tradesmen working on building components for complex assemblies on tight deadlines in Kindergarten.
I concede that I am unfamiliar with what a normal “scrum” session looks like outside of what is said in the Agile manifesto and the many anecdotes floating around. I do know that Scrum took a lot of cues from TPS/Lean of the 80s and tried to feed it to Software.
And as far as I can see, it’s not working because the profession and the products do not fit this factory model.
What everyone seems to yearn for seems to match more closely to the model followed by magazines and other such publications. Product Management the profession mirrors more the Editor than the Production Manager, SWEs mirror writers/editors-at-large, etc.
Self respecting writers in any newsroom would balk at being subjected to daily scrums that take away from precious research/writing time. And to put some kind of regular pace on progress, metrics, etc. to what really is very bursty, deep focus work is also ridiculous. Whether it takes you 5 hours or 5 days to write the piece, so long as it is of quality and meets the deadline what does it matter. And even if you miss the deadline, you could alway be slotted into the next issue unless the piece was a cornerstone piece to the issue, in which case a good editor would have assigned it with ample time or given it to the best writer on the roster.
Hell I like this analogy. Might spend more time thinking about it and talking to SWE friends about it. Feel free to expand. Maybe this will free everyone from the shackles of Scrum.
One of the projects I'm on has a standup every day, and it generally lasts less than 15 minutes. Sometimes, a topic comes up that needs more discuss and it's tabled until the end of the call. At the end, anyone that doesn't need (or want, sometimes it's useful to just listen in) to be part of the additional discussion drops off and it turns from standup to technical discussion. It works pretty well.
Our PM quit a month ago and now we have stand-ups without any managers. I think it made the developers more responsible and involved: every stand-up a new dev gets the role of a facilitator. Previously, it was a one-man show. The stand-ups have become slightly shorter, too.
2 years ago we had 1 hour long dailies because the team was too large. We split into 3 subteams, each has their own stand-up. Now it's down to 15 minutes max.
Right. So in one team I worked in, the team leader had to take notes during stand-ups of what everyone is doing to deliver them to managers so they can browse at their leisure.
I interviewed at a place whose sprint planning took a full week and was reportedly incredibly stressful. Customers participated. Their product was a website that agile teams used to track their process.
There are a lot of things better than scrum, but mostly these are all wrong ways to implement it.
Daily: should average at 10 min, 15 min is really the maximum. Including prep. So 5-15 min. No status updates! The daily is about getting people unstuck with their current tasks and quickly aligning on what to do next. If it is not useful for the team, the implementation is wrong. Doesn't mean it always has to be useful and interesting to you, there's a difference. Management stays out of the daily.
Sprint planning: the sprints are the compromise to management so we can have some sense of progress, so this is of course the one meeting that is useless to the team getting work done and can hamper productivity. Just make it quick.
Retro: you should do a retro about if you think the retro is useful and why/why not. If the team doesn't think it is, either change it until it works or make this the very last one. Management stays out of the retro. ("But are you then not doing scrum anymore?" "So what, save the pedantry for writing out the functional and technical requirements please")
Thing is, you do need to understand what you are working on, and it needs to be more or less the same as what your team members think they are working on. If you are 100% efficient at building the wrong thing, your 0% overhead amounts to exactly nothing, and the 80% efficient scrum team is infinitely more efficient. Though these extreme cases are usually a problem from higher up, without any way to align your work you will usually not be efficient. And if you are, then good for you, don't follow scrum like its some cult. But most teams need a little coordination.
Basically if anybody feels a meeting (or anything, really) is a waste of time, there is a problem that needs addressing. And the problem is not the feeling, but what is causing that sense of waste. Take it seriously, it is almost always signaling a flaw in the process. Learn how to talk about this in the retro and get to the bottom of it.
The retro is about debugging anything that isn't working optimal in the team. If you cannot find any bugs and fix them, then you are either perfect or just not good at debugging, and I know which one to bet one to be the most likely. One sure sign a team isn't very capable is when there is a lot of blaming involved. Usually external factors or tools get the blame, but in very dysfunctional teams people blame each other.
If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.
If I build a manual transmission car, and you insist on driving it like an automatic, it's not going to work for you, even though it's an amazing car. There are steps and processes that you must follow in order for the thing to work for you. If you don't, it won't. Simple as that.
Put another way, if you enter the olympics for breakdancing, and then just move your body around in a floppy way, you will not win the gold medal.
But people DO do the thing right. As a loose guideline, I think you can reasonably infer that anyone who is telling "you are doing Agile wrong" has first-hand experience with an agile process that is working reasonably well. So take that as a starting point.
And the reason they are telling you that: because an agile process that is working well is like night and day to all the crazy processes that preceded it. When it works, it is amazing!
> If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.
Huh, this is same for all employers I have known or worked at. Maybe on some distant planet it is done right.
> The daily is about getting people unstuck with their current tasks
This I don't understand. Why do people need a daily to "get unstuck"? Are they not talking to each other? If I have a problem, I can proactively work on it, and contact whoever necessary. Unless you are very junior, this should not be a problem.
Without a lot of the project reports, the manager would honestly just have no idea what's going on. I recently moved into management, and one of the challenges I'm trying to balance is how to be aware of my team's progress without wasting their time or being a bottleneck for them. It's a legitimate problem which is often tackled poorly.
regardless of "process", work items should be tracked (in the problem solving record for our future selves sense, not time keeping sense), so you can follow those. If you're a non-technical manager, then either a) the implementation goes super smoothly and the estimate the dev team initially gave you is all the progress update you need, or b) it doesn't go super-smoothly and you should be involved in any discussions that arise. If you find yourself asking "when is it ready?" you've likely gone astray.
At least in the case of software development, which seems to be what Scrum is targeted at, you get the project reports for free by way of the commit log.
That said, the 12 Principles of the Agile Manifesto offers another solution: Get rid of management entirely. It states that developers are best to work with the rest of the business collaboratively. Which is the irony of Scrum claiming to be Agile: Only management wants to use it, defying Agile to its fundamental core.
Burn down charts, team velocity, and story points.
They all exist to give software development the illusion of predictability, but saying that a project should take “x sprints” is just setting a deadline with extra steps.
There is nothing wrong with burndown charts but story points and team velocity are poison.
The way you get good at estimating is looking at your database of experience. “I did a task similar to this in 8 days”. Calendar time is real and punchclock time is real, either can be measured. Story points are not real and not measurable and they leave you lost at sea thinking that estimation is impossible, a scam, etc.
Agreed. Team velocity is a poison number. But entirely necessary in order to provide a data-driven approach to converting story points into time predictions (with appropriate disclaimer of risk) that people outside the team need. Data driven! How could that possibly be a bad thing?
Maybe best to just treat it as a classified secret that nobody actually needs to know. People inside the team just need to know that their stories are arranged in correct order of priority. People outside the team actually do need time axes on their burndown chart. But they don't need to actually know the toxic voodoo that was performed to produce the conversion.
:-P
But actually seriously. Nobody needs to know that number.
Right. So you don't do that. No development process ever has provided bulletproof predictability. Your job as a project manager is not to provide bullet-proof predictions; it's to manage risk, and expectations, and make sure that development work is correctly prioritized. And of course to keep your development team protected from external insanity, because happy, stress free development teams are productive development teams. (But that's a separate issue).
Here's the feature list; here is where on the list we'll definitely get to, here's where on the list we definitely won't get to, and everything else is some shade of inbetween. Now, would you like to adjust the priorities of any of those features, or would you like to change the deadline?
I don't know if this is properly part of scrum, but it is how I've seen it implemented on every team I've been on where scrum was implemented.
Sprints end with some kind of demo, retrospective, and sprint planning designed almost entirely to keep PMs and managers in the loop and happy. Reports are generated, spreadsheets with a few quarters worth of tasks are updated, and PMs or managers get to run that further up the chain, presumably to make it clear that great progress is being made under their supervision and well run scrum methodology.
There are no PMs in actual Scrum. Scrum Teams are self-managing, so there's no need for a PM.
There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum. Scrum is iterative, by design. It's supposed to evolve with the CLient's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that."
In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key.
When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic.
When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
I could have been more clear there, "PM" has many different meanings these days.
I've never been on a team using scrum that didn't have a project manager or product manager as part of scrum (or both). Most often they have been my scrum leader.
Scrum is supposed to be self-guided, but I have never seen it implemented on a team of any scale.
I also wouldn't expect a team without PMs, whether that's project managers or product managers, to be very effective. Someone needs to be focused on keeping the project moving, and often the skills needed for a scrum leader/master overlap greatly with project managers. Someone also needs to be focused on the product and how the team's efforts fit into the longer term product goals. If that isn't anyone with a PM title it will be someone else playing that role with everything but the title.
And by "devs having to be agile" you mean "devs having to be interruptible during managers hours and flexible in doing their work after all the bs office hours are over".
it's not poor, it's clever. that marketing is what made agile the dominant paradigm nowadays. remember agile was adopted in entreprise despite IBM pushing RUP
From experience i haven’t come across any “agile” organization that runs true to the manifesto.
There’s been plenty of discussions why the “what could have been” got buried in certain people jumping in, creating weird layers and interpretations of some process for their own profit and ego.
I worked at a small startup that actually handled that distinction well for a while.
We did 2 week sprints, but that really was more to keep a remote team regularly in touch and updated. Sprint work was very much up to each dev, and at the end of the sprint anything that changed or slipped was just chalked up to lessons for future work.
That did change eventually, both as the team grew a bit more and funding started to run low. Eventually we had the worst of both worlds mentioned in the article, sprints with more rigid goals leading to a quarterly goal driven more by marketing goals than anything else. Throw in the fact that the still rather small company ended up with one person making product, marketing, and even technical decisions and we devolved into glorified code monkeys pretty quickly.
My team works in an agile fashion. I simply stay out of their way and every week they finish what they promised to finish. The team is high-quality and hasn't missed targets or estimates. Most of our "ceremonies" are purely for socialization, as decided by the team.
But this is extremely fragile, because it takes a lot of energy to fight external people (often product people) who want to remove the self-management aspect.
Unless this is in the DNA of the company, you can't have agile or real Scrum, because it threatens those kinds of power-grabs. For this to work, you literally need someone threatening to fire people who attempt to micromanage others.
We use Agile at our company and let me tell you, it sucks. Maybe straight up scrum would be worse, but honestly agile is invasive and just feels like you’re being babysat and forcing people to give BS updates at standups because they’re afraid of sounding unproductive.
I find Agile is like democracy. It does suck, but it’s better than everything else.
What would you prefer besides agile?
I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Everyone should just work on things until they are done. He argued this earnestly and didn’t recognize that there are opportunity costs and conflicting priorities and the need to choose what to do. He earnestly argued that every single user story should be worked on in order of entry until it was completed. It would have been precious how clueless this suggestion was if he didn’t spent 20-40 minutes a week arguing this as an explanation for why his items weren’t done and why he was civil disobediencing to refuse to estimate or report time on tasks.
> I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate.
Plenty of learned people have made defenses for having no estimates. If you want to make the opposite claim, you don't need to use a junior dev as a strawman.
I never understood this point of view. It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification.
I have personally only ever had success with estimates that were "is this a project, or is this a task that belongs to a project". Perhaps stretching to t-shirt sizing of S, M and L. Anything beyond that, say, comparing two projects to be able to prioritize and see the opportunity cost etc etc is a fool's errand.
From The Black Swan by Nassim Taleb:
[Critics say that] the maps we had were better than having no maps. [...] This is the strangest of errors.
I know few people who would board a plane heading for La Guardia airport in New York City with a pilot who was using a map of Atlanta’s airport “because there is nothing else.”
> It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification.
It is, however, possible to provide more information than "whatever" about how long it will take to achieve a goal. I have had goals I've worked on that were summarized with things like
- Could take anywhere between 2 days and 2 weeks, depending on factors
- Has an external dependency on X, and we don't have any insight into when X will be available
- May have other external dependencies, but we won't know until we're a few days into the work
- Not sure yet what the complexity of using <this API we need> is, so we'll need to check back in with more information once we have some time to experiment with it
- Expectation is about 5 days, on this, but it could be as short as 1.5, and could be as long as 3 weeks, depending on some factors
All of those things are more information than you had before, and allow the people that make decisions (which may be you and your team, or may be someone higher up the chain) to make _better_ decisions (or at least, better informed decisions)
And if you're working on something that you literally have no information on what's required for it, what the complexities might be, what the unknowns might be, etc... then perhaps the task you should be working on is "Identifying the work required to achieve <goal>", not "<goal>".
There is very little chance that what you are working on has never been done before. Most likely, you are writing simple code to do simple things. These things can be broken down into simple tasks, and these simple tasks can be estimated.
Unless you are working on ChatGPT-6, i assure you, you can definitely estimate how long things will take. your estimates will not be perfect, but they will be good approximations for guiding development.
Even OpenAI by now probably is pretty good at estimating how long the next ChatGPT version will take to develop, since they've done it 4-5 times already.
Alway always distrust someone who says "we are doing things that have never been done before". At the very bleeding edge (OpenAI, SpaceX), you are iterating on something that has been done many times before, but with a small innovation.
I don't think the folks that say this usually mean "never done before" in the way that you are saying.
"never done before" in my experience usually translates to "this combination of things doesn't have precedence internally [to the team or company], so I have to figure out how to glue all of these parts I don't understand together".
Code is infinitely copyable. If it has been done before it can just be copied, hence the time it takes is 0. If it takes more than 0 then what you are doing is actually something else entirely, like gluing said code to something else for the first time.
If it is not the first time, then you already have the code and hence the time it takes is 0.
There are cases where code is similar to code you've written before or you cannot just copy the old one due to licensing constraints. In this case estimation is easy, somewhere between an hour to a day or two.
Anything larger can be broken down to hour to day or two chunks since it has been done before.
All great, except this last case simply doesn't exist for the type of work that I do. And that is true for many people, software is extremely unpredictable because the stuff you need to build on top of might as well be quicksand.
S/M/L is about as good as it gets. I’ve tried using story points but I think the point isn’t to have exact estimates but to figure out if 1) it’s too big for the spring and if so break it down into smaller; 2) is this someone a single person can do or it takes multiple; 3) can I do a couple of these in a single sprint (M) or it’s the only thing (L) or it’s just “5 minutes” (S and usually a day or two because nothing is 5 minutes).
I’m a fan of Taleb, but also a fan of using good maps. Note that Taleb isn’t advocating no maps at all, just that it’s stupid to use the wrong map just because it exists.
I agree that I’d rather have no estimate than a bad estimate, but it’s not like those are the only two options. I want a good estimate or at least a useful estimate over nothing or bad.
You need to break work up into tasks that take less than two weeks.
Beyond that, you’re metagaming and that is going to end up either not being worth the energy invested or a net negative. I say energy not time because there are only so many niggling arguments you can have with coworkers before they push you into traffic. Each petty little argument that could have been about something more important just runs down the clock.
I disagree as when you have a team of 8 people understanding whether something is one day of work or 10 is a big difference.
I don’t think you need precise estimation down to the hour, but knowing if someone can do 4 things in a sprint or just 1 is really important because people have interdependencies.
I don’t think I’ve ever had arguments about estimates and it’s usually a really quick exercise of “I think this is a couple days” and others saying “ok.”
I've been encountering fewer and fewer small point stories of late. There's a certain amount of overhead for one story, both on the creation side and the deployment side, and that bookkeeping starts to overshadow.
And on a larger team, a lot of these little things that need to be done could just be tasks rolled up into a maintenance story.
Of course when I was on a team doing Kanban none of this bullshit mattered. You just put it at the top of the backlog and it got done. Quick win, instant gratification, next story please.
And that right there is one of the biggest reasons Scrum is showing its age. It came into a world where quarterly milestones were the only time you found out how fucked the project is, and only then if you had a good bullshit detector. Otherwise it would be next quarter when you figured it out. It pushed that world down to two week resolution, one month to see past the BS. But it struggles to make good on reducing past 2 weeks. One week has more overhead, and forget about anything shorter than that.
Also I've never encountered anyone who followed Ken's advice to run sprints from Wednesday to Wednesday, so we always get the worst version of Scrum.
For any tasks that depend on it. If I need you to do something and I can’t start until you’re done, it’s useful to know if you think you’ll be done tomorrow or next week. That lets me plan my upcoming days.
Would you feel it fair, when you require an estimate, to have to say what decision you'll make with it?
Usually, when someone insists on getting estimates, that's my way to make sure that they really need it. besides, it also helps making an estimate that won't be useless in the context of the decision to be made.
The lesson I learned from asking that is 1) many people ask for estimates without a clue about what they'll do with the info, and 2) when a decision actually needs to be made, the actual question is never "will it take 1 or 10 days", but rather "will that project be done by regulatory limit", or "will it cost 50k or 5 millions". And for the 2nd point, sizing every small task and adding up usually compounds uncertainty in unpredictable ways.
I’m talking about particular user stories, not the overall estimate.
For projects it’s almost always a budget issue “how much money and time does it need?” And that’s important because, like money is hard to get and $1 is different than $2M. I think the time is usually related to money due to revenue and costs and whatnot.
My example was about estimating “how long to add a revert button to 5 pages” and that requires “db crud to revert stuff” so how long the latter takes affects when the former can start and if they can both make it into the same sprint. Etc etc
I've never been in a situation where adding db crud was its own user story. Usually, we group this and the button (and the metrics necessary to trask feature use) in a single item, and pair people so it can be shipped in one go.
It's common in corporate implementations of Agile (tm) but it isn't actually some commandment or prescribed feature of Agile itself. It's actually prescribed by Scrum:
There isn’t anything in the agile manifesto on how to do anything. It’s a statement of preferences and values.
Business demands process for people in functions to follow. Scrum outlines meetings for programmers to attend, and specific process outputs like user stories to produce and close. Scrum is agile in business because business cannot do agile.
Right, so when someone says they are doing Agile instead of Scrum but don't like it because of the invasive status meetings, they're probably actually doing some form of Scrum whether or not they realize it.
Agreed. But Kanban also often incorporates some of the processes from Scrum like daily standups that aren't prescribed anywhere in Agile.
Personally I find it more useful to organize things around useful product milestones that are actually usable and demo-able. Those might take a week, or three weeks, but probably not two months because that's a long time to go without a demo and getting feedback. Sticking to a rigid 2-week sprint with an expectation of demo-able progress after each sprint doesn't feel particularly realistic or useful to me.
The business has a need for a regular status update from everyone. You can call it a standup or not. You can call it not agile, but in the end the business has needs and you cannot ignore those needs.
The business needs to know when something will be done as they need to make promises to customers. The business also needs to know when things will be done as that is a proxy for cost - they need to make sure they are not spending more creating a thing than it will deliver (this is a hard problem as some sales will not happen until it is done and there is typically a competitor customers could go with). That is nearly impossible to say how long engineering will take doesn't mean we don't need to know how long it will take!
Sure. I'm not saying there shouldn't be status updates. I'm just saying that those status updates aren't because they are "doing Agile."
There isn't really any such thing as "doing Agile", it isn't a prescribed process to follow.
And saying that you use Agile instead of Scrum but dislike the invasive status meetings isn't actually congruent with the actual definitions of Agile or Scrum.
Agile is meant to be a collaborative process with a user or customer to discover the truly desired objective. Baked into agile is the notion of changing courses. A business that wants a deliverable by a certain date wants a contract - not Agile. How can a route be predictable look with a process that explicitly seeks to regularly change course.
We could also get into the theory of whether it is actually possible to say how long software will take at all. Business might bevroutineky asking for the impossible using the wrong methodology for what they think they want
Software with business utility is never "finished" unless the business is finished.
Trying to estimate when software is finished is tantamount to asking when the last light will be turned off forever in the warehouse.
I keep trying to tell PMs that around the release date is when developers are the most busy, including afterwards. It's not some magic deadline after which developers are no longer needed.
It's been a long time since I last read it, and it's interesting how times changed.
On daily standups, from he manifesto:
> Business people and developers must work
together daily throughout the project.
> The most efficient and effective method of
conveying information to and within a development team is face-to-face conversation.
The "standup" theatrical part isn't in it, but that begs for daily meetings in the same physical place really.
Also...no. Verbal communication isn't effective or efficient. It's fast and natural, and perhaps comfortable to many.
In our current corporate environment, effectiveness (providing the right info in the right form) and efficiency (minimizing back and forth) will probably be better achieved with documents and open chat with all the parties involved, even if (in particular if?) it means slower throughput and more deliberate communication.
The stand-up is an opportunity to call out things that are blocking you, not for giving status updates. I got Scrum certified for resume padding, and thought it was gonna be easy, but I was blown away by the things I "knew had to be part of Scrum" that actually weren't.
It’s an opportunity to call out things four business hours after they happened. We have Slack now. Or Teams. If you’re stuck, tell people. Don’t wait until tomorrow morning.
> The stand-up is an opportunity to call out things that are blocking you, not for giving status updates.
I find it very useful for allowing everyone on the team to have a general idea what everyone else is working on. You can call out to ask for help at any time [1]. But having a 15 minute meeting each day to make sure everyone has a view of all the pieces in movement is handy.
[1] Though the standup does give a place for people that aren't comfortable calling out when they're having issues.. to do so because it's expected there.
> Though the standup does give a place for people that aren't comfortable calling out when they're having issues
In my experience, standups are the worst places for such people. If they aren't comfortable calling out when they're having issues, they're even less comfortable calling out that they're having issues in front of the entire class.
"Keep managers happy" isn't part of Scrum, either. If you read any of the Scrum books by the creators of Scrum, you'll find that the way 95% of companies implement Scrum is nothing like what Scrum was intended to be. They mess it up, essentially in the name of marketing, and not wanting to truly change their ways.
> Agile is about exactly what you said: empowering devs to get shit done.
Sure, that's the goal. In reality, though, that's very nearly never what it does in practice. That's why I have come to view "agile" shops with an extremely skeptical eye.
But what does it mean to "empower devs". Do you give them requirements and say I'll check in on deadline day in 6 months?
Presumably you would still use iterations to track progress, Epics/Features to break down requirements, some kind of estimation to track if you're ahead/behind schedule?
I certainly wouldn't go back to Waterfall days, but I suspect many current devs never experienced that.
There’s a world of difference between checking back in 6 months and daily standup meetings + a host of weekly meetings.
If you don’t trust your team to be productive for 2 weeks without communication something is deeply wrong. Individuals should be in constant communication, but few things need to be said to everyone. Scrum style management may be useful for highly dysfunctional teams, but it frequently adds a great deal of unnecessary overhead.
- One on Ones to discuss roadblocks and thoughts every week.
- Issue tracking as a common place to describe what needs to be done and thoughts / details on how it is solved. Something lightweight like Trello is ideal
- A Kanban board so people have an organised way to pick up new issues when low on work
- A weekly showoff meeting where there are few 5 minute presentations and a 30 minute "I did something really cool or learned something really cool"
- 6 month task split into 1 month ish deliverables, with a flexible deadline for each. Presentation of finished work each deliverable.
This is basically how my team does it. I love it. My manager spends much of her time figuring out how to help remove our roadblocks and planning the 6 month to 1 year horizon (with our input). I lead the weekly meeting where we do the showing off, PSAs, or light brainstorming on issues with broad relevance.
Two scheduled meetings per week = tons of dev time and freedom to explore / innovate! (Ok, three weekly meetings if you count the product-wide meeting, which is usually a waste of N-5 people's time, and I usually have it on the background while I continue working.)
We are remote, so ideally there's also one in person gathering per year to do the big vision casting and major high level brainstorming.
We still have room to improve, especially in the area of ad-hoc dev-dev communication. Always interested to hear how others do it!
That’s no easy feat and often oversimplifies the challenge of building competent teams. I think it’s achievable if you have a large budget to hire only senior/experienced devs and a mature hiring process/team. Plus, if your company has strong tech branding, it becomes easier to attract top talent too.
But if you’re at a startup with limited funding and possibly no branding at all, you’ll likely face this situation:
- Hire inexperienced but honest, motivated people with the potential to grow, and invest in mentoring them.
I do not disagree with anything you said at all! Though chances of success diminish here.
If you have to introduce some "process" - whatever that "process" is - because you do not have competent people and you feel like "process" will fix it, your chance of succeeding are a lot smaller IMO...
Pizza sized teams that can directly interact with customers don't need management. Management is playing telephone with someone in the middle with their own interpretation of everything which is 99% wrong.
It sounds like you've had bad management (like we all have). Good EMs will unblock you, deal with conflicting priorities from stakeholders, provide you with air cover to have focus time, and help manage your career growth (among other things). If your EM isn't doing that, find another one.
> Good EMs will unblock you, deal with conflicting priorities from stakeholders, provide you with air cover to have focus time, and help manage your career growth (among other things).
Those don't really seem like things you'd want to outsource, no matter how good the outsourcee is.
Sounds like you mix up management with product people.
Product people are not management at least not where I worked.
I see how it might be a problem if your manager is talking to the customers.
Product people are or should be equal to dev, engineering. They should indicate priorities but should not in any way evaluate engineers especially if they have no technical expertise.
The reality is even good devs tend to work hard on the wrong thing. Accountability comes from your peers as much as your manager. If this makes you angry you are one of the bad ones.
Everyone tends to work hard on the wrong thing if it what they like to do most currently. Everyone. A conversation is all that is needed to remind them of the team priority, non need to create a creativity carcan with processes.
Give good devs a direct line to the customer and they're apt to always work on the right thing, but will spend a lot more time dealing with the customer and a lot less time in development in order to do so.
Leave good devs to play telephone through a middle-man, what we call the manager, and they almost certainly will work on the wrong things, but will have a lot more time to do it.
I wonder which is actually more productive? Agile (of the Manifesto kind) posits that the former is most productive, but Agile (of the fake kind) seems to always want to revolve around the latter. The general sentiment is that fake Agile is the one that gets it wrong, so presumably cutting out the manager is what is most productive, but more data is welcome.
Disagree. The customer often has tunnel-vision on their needs, and doesn't know what's possible, and might have trouble even describing it except that their manager told them that their foo task was a problem.
The devs have the opposite problem, they can imagine all sorts of new technology that would be fun to use (for them) in helping the customer solve their problems with doing foo, and even if they understand foo from the customer's business perspective they they may not have a great understanding of how big a problem it is in the grand scheme of things and what commitment of resources and expenses are justifed in solving it.
Managers talking to managers can (in theory) draw some boxes around scope and priorities and get the right development problems solved at the right time. They may talk and realize that doing foo isn't even really a great idea and they should be doing bar intstead. Line-level employees working directly with developers will not be as likely to realize that.
Developers can fall into the trap of thinking that because they are smart (mostly) at building software they are automatically smart about all the business processes and problems and goals of the company. They should certainly be informed about those things, but they are not experts in everything.
If we were talking about developers in general, perhaps, but we're specifically talking about good developers. They exist at the intersection of understanding the business, what customers are actually saying, and understanding the technology. Without that, what would make them good?
Very very few of these people exist. They like to think that because they are very good at writing and understanding code and technology that they are automatically the smartest person in the room with every other aspect of the business. And I'm not talking exclusively about software developers, you'll find the same issues with anyone who is deeply smart and experienced at any one thing, thinking they must be smart about everything else too.
There are a few polymaths out there, yes. But only a few.
Well, yeah, that's why they're considered good. Why they get a special title not given to everyone else. It would be nonsensical for "good dev" to refer to everyone who touches software development. "dev" would already communicate everything you need to know. The addition of “good” implies being set apart from what is typical.
> You generally don't want to act on customer feedback directly.
Obviously not literally. What they want hasn't been invented yet, which means the words to accurately describe what they want also haven't been invented yet. But ultimately you do want to act on what they really, truly are trying to tell you. Indeed, figuring them out is a hard job all on its own.
> is a full time job.
Sure. That's the tradeoff. You can spend most of your time figuring them out, and then the small few remaining units of time you have for development will be on point. Or you can play telephone and have all kinds of time for development, but will more often than not go down the wrong path.
It's not really clear which is more productive at the end of the day. But we do know that Agile (of the Manifesto kind) pushes the former, while Agile (of the fake kind) pushes the latter. People seem to hate fake Agile more than they hate Manifesto Agile, so that does suggest that not playing telephone is more productive.
I've heard a lot of push back against all kinds of process on this forum, and it always surprises me.
But reading the article made something click: it is not about the specific process, the (lack of) autonomy is what really matters. I guess I got lucky to work a lot in teams where we largely controlled our own process, so even if we used bits and pieces of scrum, kanban or other methodologies, it was always of our collective choosing and when it didn't work, we changed it.
I did like to have rules, principles and process. A simple playbook for a daily meeting that made us not forget important things and sped up the meeting. Making things in small increments meant that I didn't have to review thousands of lines of code. Having a visual overview of work neatly spelled out means I don't have to re-think every time I pick up a new item to work on. This also prevents useless work because one of your teammates decides to work on the same thing as you without telling it. All these things make me happier and more productive working together on some big thing.
The key is that the team should be in control of the process, not some manager who isn't part of the team and affected by the process. You need to have a stake in it. The only other factor that undermines this is 'process for the sake of process'. Every part of the process needs to earn the inevitable cost its implementation is bringing. Some people seem to be happy paying the pricing without getting the value.
It seems we go astray when we start defining and evangelizing things that may have worked for some group of people to push them on others.
Somewhere in all this process stuff, I see maybe what some teams were doing but I doubt it was as rigid and I doubt they indulged in it when it made no sense. Once these teams or people are asked what they're doing right - it eventually gets defined into rules and then evangelized to people made to feel they can't deviate or improvise when the framework makes no sense. "Trust the process."
So people start wasting their time going through the process rather than using the process as a framework/tool for getting things done, they 'do' the process.
Their job is standup, their job is scrum, tickets, and points, and as a result their job is only marginally to do the things that need doing.
Company's might take more issue with this inefficiency if the workforce didn't double as something to manipulate pre and post head/tailwind to make the stock rise.
All of these methodologies (and most formal software architectures as well) have as a their main sales pitch the idea that you can hire average/entry-level developers and build good software with reduced defects and on a defined schedule if you only follow these magic guidelines.
It refuses to learn from The Mythical Man-Month and recognize that building software has an essential complexity that cannot be avoided. You need smart people to implement and manage it, and you'll have to pay them what the market says they are worth.
Building software that's more complicated than a standalone CRUD system is hard, it will always be hard, and unpredictable, and to some degree stressful. No methodology will ever make it anything else because the methodology used doesn't change the nature of the problem.
My first and second experiences with Scrum couldn't be more different. And they were successive. Actually, they happened on the same team, same people, same project.
Before: the team had internally decided to use Scrum. Other teams were not using it, and inter-team coordination used traditional project management methods. It was fantastic; the team worked like a well-oiled machine and I really did feel more productive. We never had crunch time. I did not feel the "end-of-sprint mini crunch" that this post describes; instead the norm was that, by the last couple days of the sprint, people were starting to finish up whatever tickets they had taken and pivoting to helping teammates get the rest of the work done. Oftentimes we'd close out all the user stories a day or so before the end of the sprint, and have all that time for tidying up the codebase, fixing small technical debt items, experimenting with new tools, or planning ahead for the next sprint. So, if anything, it was the opposite of what the article describes: the last few days of every sprint were downright relaxing.
After: The executives got wind of Scrum, and decided to standardize the whole company on it. We stopped work for a week so that we could have a famous Agile coach do an all-hands Scrum workshop. Which was fun, but the middle and senior managers were conspicuously absent. And then, after that, things kind of went to heck. The way our team did Scrum rapidly started to change as our team manager started getting explicit instructions on how to do things. We also started experiencing pressure to keep or maintain velocity. We started getting questions about why our velocity was so much different from other teams'. We could explain that the story point scale is team-specific and you can't compare story points across teams, but that didn't go anywhere. As I said, the middle and upper managers skipped the Scrum training. They weren't interested in being lectured about what I'm sure they perceived as pedantic little bullshit details.
I left that company and went to another where leadership didn't mandate any Agile methodology. My team did a homegrown Kanban-like thing. A team I collaborated closely with used Scrum. It also seemed to work pretty great. Again, possibly because we chose it for ourselves. I don't think the other team would have done as well on Kanban. Scrum wouldn't have worked so well for our team. I didn't see a problem with that. We each had different business domains that warranted very different "rules of engagement" with our stakeholders and ways of organizing the work.
Since then it's been a couple more companies where "Agile" was mandated from the top, and, apologies to Tolstoy, but they were both miserable in the same way that the first one was after the Scrum mandate got handed down from above.
One of my soft requirements for engineering roles is "no agile". Usually if a hiring manager tells me that team is an agile one it's a very clear sign that I don't want to work there.
Of course, this pickiness is only if I'm in a situation where I don't need to move. I can think of plenty of cases, for example being laid off, where I'd take a role in a scrum team.
We don't do agile, scrum, standups, etc. We meet 1x week to review where we're at and establish/re-establish priorities for the week if needed, use a ticket system for tasks to track progress, a high-level "weekly goals" shared doc, communicate on Slack as needed, and let the devs actually do the f'ing work the way they know best. If someone can't self-manage and produce without a manager over them, or reach out if they've hit a blocker (due to their own limitations or someone else's) they are not the right fit for us.
IMO, if you're a SWE/dev and spending more time doing other stuff (meetings, TPS reports, etc.) than coding (coding includes the time needed to research, experiment and think of good solutions, not just actual coding), then something is wrong.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
It's kinda nuts how many capital-A Agile processes (and consultants!) produce situations that are diametrically opposed to the original ideas. Notably, Scrum is often processes and tools over individuals and interactions.
I feel like in a lot places the ultimate purpose of sprints is to let executives think they can see data that represents the amount of work getting done down to a fine level.
Indeed. Which is backwards. The goal shouldn't be giving execs a warm fuzzy feeling. It should be identifying issues and risks that execs can help fix. I.e. handle exceptions to the norm.
Exactly right. I've seen it first-hand. It's all about the data. It's also neatly separated from the real operating context in a way that presents it as highly misleading.
Incidentally, if you criticize the data (such as asking "Where does this data show the effort that people who spent time mentoring/pairing but didn't do the actual 'commit'? Where does the data show the effort spent code reviewing?), you should know that it won't be received well. The emperor really does not want to hear that he's not wearing clothes.
I think back to the early 2000's, and there are other factors in play as well. Back then, I worked with a team of engineers that stayed together for over 4 years. In that time, we did not have Project Managers telling us to do daily standups. We met as an engineering team.
We often would go days without having a formal meeting.
But, software was different then as well. Everything is interconnected now. One team dropping the ball affects countless other teams. Deployments were whenever we felt a new one was due or at a multi month cadence. Did this introduce problems, yes, but at the same time, they came in controlled release cycles.
Nothing against CI/CD and continuous delivery, but the hamster wheel has gotten to a point where we have to release all the time. Corners are cut on everything, and testing is given lip service.
At this point, I am a manager, and SCRUM stresses me out. Either let us work from a queue, or give us a project with a deadline. Give me back a stupid gant or pert chart. At least then it was, is this done to allow XYZ, not we are going to accomplish this in the next 2 (arbitrary) weeks.
ex manager here. managers are in an even worse wheel. biz demands managers show up to even _dumber_, less organized meetings than devs think they have to deal with. eng to eng meetings tend to be fine, but the rest of company culture at BigCorp weren’t trained in structured problem solving. it’s negotiating with goldfish half of the time (generally friendly goldfish), and no one actually practices any formalisms or larger cohesive pjm. “just give me a gantt” like the author says would be an absolutely monumental improvement from how i see things get done
With software you have a situation with two problems.
First is the "gap" between those doing the work, and those writing the checks. (When it's the same person, this problem disappears.)
The guy editing the checks likes to understand progress is being made, and that the project both has an end and will be successfully completed.
The second problem is that by it's nature software "never ends" and many (dare I say most?) projects fail and are simply abandoned.
The moment the check writer is not the direct manager of the development you have an intractable problem. The person in-between (quite literally middle management), is often not technical. But he has to convince the bean-counters that this project is "on time and on budget".
He can't help but feel sometimes that he's herding cats. He's an irritant to those who are "doing the work" so they treat interactions with him as a waste of time. Inevitably he starts trying to measure things. (And we all know what that means.)
His job is hard. He's stuck between developers who don't want anything to do with him and higher-ups who want reassurance, bit don't really trust what he's saying.
The miracle is not that this process sometimes fails. The miracle is that it ever works at all.
And sure, you may not like your meetings, but at least understanding the game might help you understand why his job is the crappiest of all of them.
No, alas no material to refer to, other than my own experiences at several places in the food chain.
At the moment I'm having fun developing again, but I have had experience of management as well.
Obviously my experience does not speak to all cases, and I'm fortunate that most middle managers I've dealt with are competant.
I am in the fortunate position of being able to "speak truth to power" though, and generally been able to dispassionate translate technobabble into managerspeak, and help all the layers understand each other better.
I've found that when both sides understand (as much as they able) the complex demands being encountered, more realistic expectations and demands are made (and usually achieved.)
But I've been lucky. I've had good dev teams, good middle management, and good product owners. Who have all been pulling together to make projects successful. When one group is pulling the other way, things get tougher.
It's beyond software: any domain that requires oversight of non-trivial work should really have leadership from the ranks so they are able to ground their observations.
Managers with no domain knowledge are just an extra layer of indirection and overhead without any of the benefits. Would any IC want their career gated by someone who has zero insight into the team's day to day duties, doubly so if it's at a supposed "tech" company?
Trust and rapport are gained in time, often in short order. Small artifacts of evidence should generally prove to the bean counter that they are cutting checks for something!
> at least understanding the game might help you understand why his job is the crappiest of all of them.
Well, sure, but that's what the daily standup is for. So that the problem solvers on the team can understand the process, the problems it faces, and, importantly, find ways to optimize it.
But it seems, for how crappy you claim it to be, those in that position don't want to talk about it in fear that it will get optimized away. Job protectionism trumps all, I suppose.
The meetings between engineers are rather unstructured. I hadn't really thought about what meetings between business types would be like. Decisions get made in those that affect whether the company is a viable going concern. That makes for a very uncomfortable line of reasoning.
In the nearly 30 years of doing this, I’ve had more success delivering good quality software that meets business requirements under waterfall than any of the SCRUM implementations I’ve worked with, and I am saying that without disagreeing that waterfall has its problems. In the agile space, kanban is the only one I’ve felt is productive, but it has trouble scaling to multiple teams.
In my experience, waterfall forces business to think more about the project and plan accordingly. They have to think about how this feature interacts with this other feature. Business also usually has a better understanding of how the software will work because of the planning phase.
In my experience, with 2 week sprints, the business doesn't really have to think about anything outside of bite sized chunks or even how those bite sized chunks affect later bite sized chunks. They can make a snap decision without thinking about it because it can be rectified in the next sprint. Almost no-one has a "big picture," view of the software.
Before agile, we essentially did 4 releases a month (this was back on the burn a CD days), 2 major releases and 2 minor patch releases. It worked really well and we didn't get the burnout as much by sprinting a marathon. With sprints, I always feel burned out. No sense of accomplishment, no letup, working hard just gets you more work. It's like laying bricks one at a time on a wall with unlimited length.
> No sense of accomplishment, no letup, working hard just gets you more work. It's like laying bricks one at a time on a wall with unlimited length.
Also feeling bad every 2 weeks because planning was really bad and now you need to say you're sorry the task has to roll over the next sprint and your manager has to explain to their manager, etc, etc.
Waterfall forces management to get it's act together. These processes are all about giving management more power and less accountability.
Product Management has fallen a tremendous distance from where it used to be. PMs who have come up completely under Scrum seem to think stories and epics barely require more than 1-2 sentences and the developers should have to figure everything out from there.
Even senior people in their early 40s have completely forgotten how to specify or document anything well.
It makes me wish I worked on something that involved physical products. The whole thing with agile/scrum is that management can change their mind at any time for any reason and the process gives them justification. It works in pure software, it doesn't work in anything physical because they had to sign the POs to buy materials and parts.
> Nothing against CI/CD and continuous delivery, but the hamster wheel has gotten to a point where we have to release all the time. Corners are cut on everything, and testing is given lip service.
Just to call it out: Having CI/CD doesn't mean you have to do all these things, or do scrum. It's imho just good engineering practice. I have it in my side projects, and I've had it at work on a Kanban-driven team (as well as on scrum).
It removes disputes over build process (eg, nobody can ever say "well, it complies on my machine"). It is a form of build/deploy documentation. It removes bottlenecks ("only Tom knows how to deploy that service, but he's on vacation") and stupid mistakes ("whoever deployed this last did it wrong and left a bunch of old files around").
I also have found deploying regularly is stress-reducing. For one, with CD the development environment is running the same steps, and we know it works because we do it dozens of times a week. The longer it's been since last prod deploy, the less confident we can be it'll go smoothly, whereas when it gets deployed every few days it becomes a non-event.
When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.
None of this means you have to release everything on a regular schedule (like a sprint). You can still do long running branches or feature-flag things off, Just try not to go too long without deploying something.
> When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.
This is, by far, the most important reason to practice continuous deployment. I've been part of enough of these fire fighting sessions following big releases to see that it's not a sustainable way to deploy software. And yet, I've never been able to convince any boss I've ever had to adopt CD because they're worried it'll introduce more regressions into production.
The way I’ve explained this before is “would you rather small issues that we can fix one by one until anyone really notices or would you rather we hit all those issues in one big go?” Your mileage may vary.
It's one reason I'm really thankful to work in a certified/regulated industry. It's mandated to effectively prove your work to get the sign off. And since you can't really sell too well in the area without that cert, it's a big part of development.
But holy hell is it still hard to get specific people to test their work. They just don't even think about it.
Work queues are themselves an issue. Instead you should have ways of documenting things that need doing that is adaptive. For example a groomed page about all the PDF bugs > 56 Jira tickers going back 10 years, some will take a day work to even fathom. It is a big time waste. For customer communication have case tickets. But a JIRA ticket is like body fat. You burn calories just to maintain it.
Yes. And it doesn’t work very well. Lots of late deliveries or reduced project scopes (often still late and over budget, but mot as bad).
Increasingly, iterative models are used and those are much better. For some reason since it isn’t Scrum people still insist they do Waterfall even though they do nothing like it.
Planes fall from the sky far less than, say, some agile/scrum-based web app shitting itself constantly, which happens all the time. Maybe waterfall has its place.
Eh. Waterfall adds risk to iterative approaches, not value. Wait 3 years to do integration testing because that’s what the schedule says. The smart projects get better quality and use iterative models.
Additionally, there are other iterative models than Scrum. That's pretty much the worst one out there and its only value is to inexperienced teams needing training wheels or overbearing management that doesn't trust the team.
Even worse. When I worked in that sector, the government simultaneously mandated that we use agile methodologies, and also that we do waterfall things. Doing agilefall like that was the dumbest possible thing, because we got the benefits of neither and the weaknesses of both.
We don't do scrum. We release major versions once a month, and bugfixes daily. New features go into the next major version when done, bugfixes gets released as soon as they're done.
We use Kanban boards to get an overview and prioritize work. Apart from that devs mostly manage their own work.
We're a small shop though, perhaps that's why it works well.
But is it? Everything is the same if you squint hard enough.
We do not have anything like a SCRUM master.
We don't do stand-ups, we usually don't have a per-release target for features. For example, for the past three months I've had a target of October 1st for a feature, but no specific sub-deliverables for the realeases before that. This is typical.
We don't have a separate sprint retrospective meeting. We discuss such things during our weekly meeting, even between releases (ie we don't wait).
It doesn't feel like what I've been taught and have read about SCRUM. But sure I'll agree it's closer to SCRUM than to the waterfall method.
Many engineering orgs just give lip service to scrum, which is as good as not doing it, which is good and works better. Meaning, in my experience: You work in a priority queue, that priority queue is re-synced with stakeholders (at least) once every two weeks, retros may be there as an opportunity to get other business verticals into the room to see what engineering finished recently, and the concept of "a ticket going over to the next sprint" doesn't raise blood pressure, because the system is designed for this and sprints aren't deadlines. Features might have deadlines, absolutely, but that's independent of the sprint.
I've worked at ~three places that operated similar to this; "minimum viable scrum" is a good name, or even better, "emergent scrum" because it isn't a process that's designed, its the process that emerges when someone toggles the "agile/scrum" button in Jira, but no one really cares one way or the other. Its a good process.
I've worked in one environment that was hard scrum, had scrum masters, extremely strict. To be honest: I felt almost no stress, but the company also delivered very little. There was a lot of "we can't get to swapping the color on that button until Sprint 18 in three months, but we'll schedule it for then". Missing a sprint was life or death, so every estimate got padded like crazy. When you took vacation, it was common knowledge that you needed to leave halfway through a sprint and come back halfway through another, sprint planning would basically forget about you. That (public tech) company doesn't exist anymore, and it radicalized me against agile/scrum: The entropic end-state of perfectly executed agile/scrum is an extremely well-lubricated machine that actually does very little.
There are plenty. All you need is a competent team that trusts each others.
I work for a huge corporation. My team plans and commits to quarterly OKRs and has a team meeting once a week to check in on how folks are doing. There are no sprints and no 2-week deadlines. Once a month or so we update the progress scoring on the OKRs.
Love this. I’ve had anxiety about agile and how I’ve never seen it work well, and the “before days” was in some of the most enjoyable and productive projects until agile came along
The secret purpose of Scrum is to get rid of managers and empower the engineering team. Most "scrum" is simply taught wrong because it was sold to companies as a way to squeeze workers.
Evolution of a manager and scrum team achieving high-performance together:
Team: "We are having trouble with Bob."
Manager: "Ok I'll talk to him."
Team:"We are having trouble with Bob."
Manager: "Don't come to me, you guys need to deal with that in your retro."
Team: "We voted Bob off the island."
Manager: 'Ok, I'll forward to HR."
Autonomous teams get more done because they have eliminated management as a wait state and will proactively scale with other autonomous teams to maximize the amount of work not done. 21st century managers need to re-focus on flow efficiencies (as business engineers), and not people. 20th century managers won't have a job in 5 years.
Sure, maybe optimize further. Why have managers? The CD pipeline goes throughout the whole value stream, not just at delivery. Just like delivery automation (eliminate intervention of humans), there's also human automation (helping people get out of their own way). So I could see a use case where managers are just eliminated. You need people who can eliminate the noise and replace with enough signal that delivery teams can execute. POs and stakeholders can do that; managers not needed.
I think what you bring up though is an interesting point: maybe managers needs to transition to business engineering roles.
This all will play out in the 21st century. 20th century management is a legacy artifact at this point. Best example is F500s, which are generally mediocre in their execution. If a SpaceX type org (14k employees, private) gets into their space, they're screwed. Even with politicians in their pockets, I don't see how rock swallowing dinosaurs like Boeing (170k employees, public) will make it. Just the energy they have to expend to get anything done compared to SpaceX is massive, due in part to their giant management bureaucracy.
We have a woman at my company whose job is to update Jira ticket statuses.
Instead of allowing the developers to update the statuses themselves, she will often prematurely update statuses from "In Development" to "Ready for QA" before any code is merged. Or she'll update a ticket that isn't yet being worked on to "In Development". It repeatedly causes a lot of confusion.
I think she feels the need to be so hands on with updating the statuses in order to justify her job, which, in my opinion, shouldn't exist.
"We have a non-binary, genderqueer, genderfluid, agender, bigender, demiboy, demigirl, two-spirit, androgynous, neutrois, third gender, polygender, maverique, hijra, kathoey, fa'afafine, man, or woman at my company whose job is to update Jira ticket statuses."
My actual job was to make sure the tickets were clear, relevant and ready to work on (as opposed to a stream-of-consciousness wishlist from managers). I gathered requirements, represented the devs in planning meetings, cleared their hurdles and QA'd their work. I was basically a prep cook for the devs.
I work with someone who has that job. The stream of consciousness is much preferable. I need to know the big picture, not some distilled set of requirements. Give requirements and I will spend half my time trying to "reverse engineer" the big picture from them, which is a big waste. And an even bigger waste if I get it wrong. Not sure why our industry is so obsessed with obscuring information.
Although I appreciate having someone to move boxes around for me. I cry a little every time I have to go near that horrid UX.
Sorry to hear that, and please have it attended to sooner rather than later. The recovery times can be worlds apart depending on how far burnout is allowed to progress.
I imagine it's still not that every development process stresses you out equally though, so it's still worthwhile considering how much stress the environment adds and why.
> The business side just can’t help itself. ("We have to market things!" "We need to inform customers about what's coming!" "We have to make promises at conventions!" "That's just the reality!")
Then shortly after:
> Treat [developers] as respected peers, not replaceable cogs in a machine.
Yes, it’s hard to know understand the (oft-maligned) “Business Side” doesn’t bow and genuflect when they enter a room full of programmers.
nobody has ever done "waterfall", it's a strawman created to explain why traditional project management doesn't work in software development. The fact that the article starts with "in the good old days of waterfall" takes away every expectation that I'll read anything intelligent in the article, I believe this post doesn't deserve your time and definitely doesn't deserve mine.
I’m not sure why the above comment is being downvoted:
I was reading The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, and I came across this quote:
Royce’s 1970 paper, which is credited with “inventing” the model, actually identifies it so Royce can criticize it and suggest improvements. He wrote it is “risky and invites failure” because “design iterations are never confined to the successive step.” What Royce suggests as an alternative is similar to what we now call Agile. Sadly, multiple generations of software developers have had to suffer through waterfall projects thanks to people who, we can only assume, didn’t read the entire paper (Pfeiffer 2012) [p. 175].
Early in my career (mid-90s) I worked for a defense contractor working on avionics for the F-22 and for GE working on a real-time automation OS. Both used waterfall exclusively. The defense contractor had a multi-year plan with monthly deadlines that could not be missed and the same was true for GE but the deadlines were more delivery based. At GE there were 400 engineers working on the overall project and we had a 40 foot long wall where the GANTT chart for the project, generated by MS Project, was taped to the wall - it was about 4 feet high.
I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement.
Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance.
I’m not sure what planet the OP is from, but this will never change. If you have a small team with a simple codebase, kanban is probably sufficient. In larger teams or complex solutions, the reporting just needs to happen.
I don't feel anything you've said is logical. The deliverable is, in the best case, what communicates progress and success. Short of that, tickets can do that, which is also not what the article is complaining about. The article also specifically attacks Agile/Scrum; Kanban is different and quite explicitly sidesteps a lot of the stress problems the article outlines.
> Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In the agile teams I've been on it's been to produce success. Getting good and useful software fast.
Of course, just like there are hundreds of wildly different Christian sub-religions, there are now any number of "agile" interpretations. In the end belief systems can be pushed to do most anything you want.
The post is fundamentally about all the performance of making stories, assigning points, allocating work and doing standups all the time. None of that is required to actually create software.
If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
>> None of that is required to actually create software.
Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.)
>> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress, the existence of "intractable problems", work going unfinished creates significant stress up the ladder.
In a perfect world the dev team is given a perfect spec, and a reasonable time to do it in, and after being "left alone" they deliver the finished product on time.
Given that that world doesn't exist, given that the "money we're spending" may turn out to be completely wasted (because the spec was wrong, or because the problem us much harder than anticipated), the ideal case seems unlikely to happen.
I say this not as a defense of crappy management processes, or even less as a defense of crappy managers, but rather in the spirit that understanding the problem goes a long way to solving it.
And yes, many places have bad processes and bad middle managers. I don't envy you that. But finding a way to better solve the manager's problem typically improves the relationship.
I think ones that are against scrum are loud about it on the internet.
When it comes to have their salary paid out they will not speak up for themselves to push back against shitty management.
Like accepting ever increasing velocity until they burn out or accepting bad requirements because business is sayin “it needs to be done now” and working blind only to be scolded they did bad but requirements were bad in the first place.
> Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
The stress at the bottom is there by design. If you start meeting the deadlines too reliably, the higher-ups will probably conclude that there are needlessly many people in the team, and will try to remove one and see what happens. Repeat until things start cracking apart.
In one of my previous jobs, I worked on a software project that frequently got the following two kinds of comments from the managers:
"Wow, this is the only project in our company that works reliably. There are no major bugs ever; and all the small bugs are fixed within a day or two. I wish other projects worked like that."
"You have five developers working on one project? Isn't that too much?"
Seemingly none of them was able to connect the dots and conclude that maaaaaybe these two things are somehow related. That maybe the fact that we are not understaffed somehow allows us to write automated tests, refactor when necessary, etc., so we can keep adding new features as required and the project keeps working ok.
So they started removing the developers one by one, moving them to other projects. The last guy left on the project felt overloaded and quit.
The project still worked okay for a few years without new updates, and was gradually replaced by several new projects (because it had a lot of functionality). But the new projects only had two developers each on average, so at least the managers didn't feel like they were wasting money.
> Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
Good luck with that because higher-ups have even-higher-ups until you reach the top. The bigger the pay packet, the more inflated the lifestyle and the associated stress of missing on the ever ballooning target. It is self-inflicted and never-ending; sacrifices of the lowly soldier will never quench that thirst.
Hmm, while I get what you are saying, I feel like dealing with that is _literally_ their job.
It'd be nice if we could remove stress from leadership, but I don't think that's a thing that should be my responsibility as a dev. Of course it'd actually improve the life of everyone if did, so it feel like something you should do regardless.
But then I'm taking the managers job in addition to being the developer, and then what's the point of the manager in the first place?
Scrum/Agile is basically an answer for things that went wrong in the past. Building software has a long history of delays, running over time, running out of budgets, etc. As a stakeholder/customer, you need certainties up front: how long is it going to take, what is it going to cost? And if you think this isn't reasonable, just consider, would you hire a contractor to work on your house that can't tell you up front cost and duration?
Anybody doing work needs to be able to estimate duration, progress, risk of delays, etc. Other people's work depends on your deadlines. Go/no go of a project depends on cost and duration.
Insight and tracking is required. None of this was done any better before agile.
What is required is frank conversation with the stakeholder/customer, because there are so many trade offs decision to make. Devs don’t like to estimate tasks because there’s an exploration phase (which cost time an energy) to have the solution and the cost of time and energy for the implementation. And it’s recursive. Agile was basically saying, let the devs do their thing, but have a conversation every once in a while to discuss new directions to the projects based on new evidence found. And unless the team have already built the same project (with the same people involved), it will always be a bet. No amount of tracking or insight will remedy that.
Agile recognizes that software development is a design process with uncertainties and not a repeated tested manufacturing process (product development versus product manufacturing). With the uncertainty of a design process in mind, and the need for estimates, it suggests comparing similar tasks to get an empirical estimate. But since it's just an estimate, you regularly need to validate that the estimate is still considered correct.
Assigning Points = Roughly estimating how long it takes you to implement it
Allocating Work = Well... allocating work
Standups = Talking with your colleagues about the current work and clearing problems
Reviews = Showing your results
None of that seems unreasonable. The only thing that kinda sucks are the rigid sprints, because they just cause artificial stress by setting unnecessary deadlines.
They’re not unreasonable in themselves. What sucks is the process around them, because it impedes progress. Why because each tasks varies, and often it morphs while you’re working on it. So whenever a metric is fixed or something interrupts you repeatedly, it just sucks.
Or worse than impeding progress, everyone adjusts their expectations to only that which can comfortably fit into a sprint. Big gnarly bugs, meaty technical problems, or innovative solutions - too risky. Better just take a few random tickets off the board and keep plodding along.
The direct effect is organizations start systematically ignoring the forest and start obsessing over the trees, simply because trees are easier to measure. And then inevitably wondering aloud "why is velocity AND quality tanking?". Anyone with half a brain can see why - disincentivizing innovation destroys innovation.
Yeah, I totally agree in theory, it doesn't really matter what methodology you use, at the end of the day dev management is just a means to an end.
The real issue comes from middle management folks who conjure up buzzwords whenever they need to justify whatever they think the team should do. Don't know how to structure tasks but want to look like you're in control to the boss's boss? Just throw up a Kanban board with tiny tickets and a burndown chart trending down. Sprinkle in some Agile keywords in the management reports and call it a day. And let's not forget that by 'sprint' they often mean moving unfinished tickets from the last iteration to the current one, plus tacking on surprise urgent tasks that were not planned before because the product owner never shows up to share their vision and priorities.
Unfortunately, we aren't understanding the intricacies of high-performance. I've worked with maybe 150 scrum teams. 99% were mediocre. Remaining 1% understood energy usage, how to limit what they took into a sprint backlog, and how to manage their capacity.
When I asked a manager about a particular team, he said "I don't care if they do fight club in the morning, just let them keep doing what they're doing." To reframe, high-performing scrum teams are actually anti-legacy management, they get more done, are happy (low energy state) and stakeholders were satisfied. So their rolling sprint goal was taking a half day each month and going to Top Golf
. The key is, everybody on the team was a scrum sme, and understood how to work the process as a team to reinforce certainty and stability. They also didn't need a scrum master.
I've got lots of anecdotes from this couple of teams, what kind of work their managers actually did, and the sneaky ways they made the process work for them. There's a lot more to scrum than a certification. Just the teams approach to sprint planning was in a whole different class from what mediocre teams normally did.
As for the other 99% of teams, they were mostly management tools. Scrum had been co-opted, especially in orgs using the SAFe framework. This has been at F250's in my experience btw.
I wonder if this team could have choosen any framework and it would have worked, they just happened to use scrum. With the founder mode discussions recently there was this saying akin to "a successful process is a result of talented people" and not the other way around. It stuck in my head and I feel this is an instance of that. Although you definitely can force a process on a talented team and have their productivity diminish.
Agree. It's just that well understood scrum is a great process for delivering certainty and stability, as proven by lots of teams (provided they did scrum correctly).Just saves energy to thoroughly vet the process before tossing it.
But first principle, this is a physics issue: Whatever way a team comes up with to maximize the amount of work not done to deliver the same or better outcomes, I'm all for it.
This article hit really hard. I’m super stressed with my team’s cadence right now. I often think about what’s pathological in modern-corporate-scaled-agile-abominations and this really hits the nail on the head, but I think for me the main complaint is that if you can only see two weeks into the future, planning can become very difficult.
I also often think of how our scrum process makes me feel like I’m back in grade school doing little busywork projects like coloring a hand-outline turkey or whatever. I really kind of think that’s the point. It’s for people who never escaped the schoolchild mindset. No doubt it works wonderfully well for them. It doesn’t work very well for me.
One of my favorite moments was when my non-developer friend at a tech company asked me what scrum masters did because she could not figure out what the scrum masters did at her company. I told her the answer which is nothing.
Schedule meetings, move tickets around, moderate meetings, call more meetings, scold misbehaviour during meetings, help management with their stuff(secretary/personal assistant?), scold other teams for not helping out in time, question about stale tasks(tickets), act as coordinator of news/requests/demands from other teams, attend all meetings which involve tickets, coerce/seduce other teams to deliver something early because our team has messed up, promote more scrum agile topics. At least that is what I observed at my work. They indeed do a lot of work but often not well defined.
One hill I will utterly die on: Many people (including some in these comments) are fully able and happy to go their entire career mistaking high performing individuals with a high performing work framework.
Because for high performing individuals the framework doesn’t really matter? Most people aren’t high performing, so they’re designed to get the best out of the mediocre ones.
On the contrary, I’d say frameworks can’t set its claws on high performing “politically influential” individuals because they are fairly powerful. In most cases, majority people are high performers but crippled by the frameworks due to power imbalance.
Every post about "Scrum sucks" has comments about how you are doing agile wrong. I don't see any yet so as the devil's advocate:
You're supposed to have autonomous teams who put up their own tasks they want to complete in the sprint, and the sprint length can be more than 2 weeks if the team wants. And if it's tight to get the scrum's tasks done, that's supposed to be feedback to you and the team. You have autonomy in setting sprint goals, you can put less stuff on a sprint so you have the slack you're supposed to between sprints. Or spend more effort refining so you don't get surprises so often. (Or otherwise change things up in how you work)
If you don't have the autonomy and the continuous improvement in your work culture, it's not agile. Scrum is for agile and it doesn't work otherwise. If you do have autonomy you can switch to something else from scrum if you want.
Same goes for the "scrumfall" part of course but that's admitted in the text already.
(I do think scrum is overengineered for agile ideals, has failure modes like in the post, and in 95% of cases you should do something lighter than scrum)
There's truth to the ScrumFall design process which is inevitable for most development processes. It's not just that a tool needs to be marketed, but that it needs to be integrated with work from multiple teams and other processes. What ScrumFall does is provide some level of feedback prior to delivery. In the age of Waterfall, devs would develop until they said they were done, we'd get to delivery and UAT only to find that key features work differently than expected and continually extend the release date by months or years until it finally goes out the door more from frustration than actual completion. That stress level would be pegged at 10 for months until it was completed.
What I dislike about SCRUM specifically is that if you're having a rough week at home, recovering from illness or you just have things to do outside of work, you can't really just have an easy week and make up for it later on. It's a kind of constant grind and we always have a way of "filling up" our sprint. If we don't meet our target, it always feels like a fail. I know it shouldn't feel like that but it's human nature.
Maybe having "easy" sprints would work?
There are benefits too, just that constant grind aspect is why I believe it's mostly a temporary endeavor. After 6-12 months most teams seem to just do something else then come back to it once a new manager joins.
> The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
If what you are doing doesn't match that, then it's not a Scrum stand-up.
> If what you are doing doesn't match that, then it's not a Scrum stand-up.
You must have stopped reading too soon.
"The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work."
It doesn't matter what is written on a random website (even _the_ scrum website) if nobody actually follows what's written there and still calls it scrum. The de-facto definition of scrum is what people make of it.
I just find American corporate culture to be 90% about participation, not really results, but being there, being a "team player" and being really nice to everyone. Not necessarily bad things, but compared to Australian work culture (for example), America is really about "the teaaarrrmm".
Yeah, I worked with a bunch of people in the US a while ago, and I had the impression that they were playing house or something. I'm all for treating each other with respect, but that means something different to me than the constant. virtue signalling going on there.
US people tend to say that Dutch people are very blunt, but it feels like that should just be normal? If you do a bad job I'm not going to tell you that it was nice you tried so hard.
The sprint goal is a team target. If you're sick that shouldn't endanger the sprint goal because anyone in the team can pick up any work. Of course in mediocre or low-performing teams that's almost never the case but still not the fault of a product framework
This seems like a disingenuous answer to me - the rest of the team will take up the slack? And if they can't they must be a low-performing team?
The OP may have some things wrong, but the 'constant grind' aspect of scrum sprints is spot on, there is no slack.
Add to that the 'radical transparency' aspect of scrum. That works great among a tight-knit team, but it can be insidious and actually self-defeating when certain types of manager get involved and weaponize it.
I'm sure there are many people who love programming, but hate being a programmer as a job, and to some extent that has always been true, but scrum seems in many cases to make it much, much worse, IMHO. The attitude displayed here is exactly the problem.
This doesn't apply for pod-based systems though, does it? They were everywhere for years there and are still very common. Basically by definition there's only one or two people that can do each task.
What you say works 100% for trivial CRUD applications. Which is also, where SCRUM is still a bad framework, but at least SCRUM works on this trivial level of software development.
When a project is about non trivial projects, people, especially developers can not be easily replaced, because no one can replace a specialist with several years of experience on the spot. What I can archive in one day and what somebody else can archive on a day highly depends on what it is. Write a field to the database? Works. Write a rule engine? I'll probably be a factor of 10x more productive than an average developer. Write some GUI/CSS? A frontend developer is 10x more productive than me.
> If we don't meet our target, it always feels like a fail. I know it shouldn't feel like that but it's human nature.
It definitely is human nature, and beyond that we're so trained to focus on goals and take them seriously that the "sprint goals" actually feel weaponized to me in order to get people to self-motivate/drive themselves. In the Scrum world engineers are fungible, so if one burns up or stops performing, you just replace them with a new one.
Also that "rough week at home" is going to show up on metrics for a very long time. A good manager understands the ebb and flow, but many do not. It also doesn't help that the Certified ScrumMaster® people will put so much emphasis on smoothness and consistency, and when it doesn't happen there's always someone/something to blame. When you remove the context (like team lead who knows what happened) and put it in a quarterly chart for upper management, you get a lot of bad and counter-productive conclusions.
Out of the 8 companies I've worked at as a product engineer, the most successful framework to deliver tangible results has been Basecamp's Shape Up approach. Engineering managers always ask "how many days" of effort when the real question they should be asking is "how much appetite"/"how long do we want to spend" on the particular product/feature we want to build? The Shape Up framework was the only time I didn't feel constantly stressed and it actually provided time to cooldown between the six week cycles. And the fact is it actually led to very successful product deliveries consistently. For those interested here's a link to it https://basecamp.com/shapeup/0.3-chapter-01.
While I think the part about neglecting support became true at my org, I didn't forget how awesome E V E R Y O N E felt about Scrum when we started. It lasted for 1-2 years. All the devs and everyone loved it. So... then why?
Because it brought a kind of order to the game. Story points worked. They became boring so the teams started to twist them.
I think Scrum loses its advantage when people get bored - like with any other "process".
I remember that as well, but I think scrum lost it's advantage once it was co-opted as a metrics and management tool, and by people looking to make a career out of "managing." That's the point at which it started shifting to being imposed on the team rather than offered as a tool to the team.
447 comments
[ 2.8 ms ] story [ 314 ms ] threadScrum was an idea that had its time, but after like...15 years the limitations are apparent.
If you don't have that situation, you probably don't need to be really careful about what's in a sprint.
Problems with Kanban: It's nice that you set priorities to the tasks, but all of them need to be ready by the end of the month regardless.
Conclusion: If there is more work than people can realistically do, and it all needs to be done no matter what, it doesn't matter what process you use; people will be stressed and burned out.
The core problem with that is that effort - consciously or not - gets immediately turned into (start day + estimate) => deadline which only works when you consider spherical cows, not accounting for the hard true practical fact that reality is messy.
And it is quite messy, by the very nature of the work which is to do something that has not been done before (otherwise by the very nature of software you'd just reuse it) and thus carries unknown unknowns. Everyone has experienced this "one-line fix, should be done tomorrow" that turns into a bind-mending multi-week hunt down the rabbit hole; replace "fix" with "feature" at your discretion; replace rabbit hole with "that very urgent task preempting anything else".
The second-order problem is that deadlines are used to schedule higher level dependencies between teams, all the way up to product, and possibly customers, and then it becomes the coupling interface and everything falls apart when there's a delay that inevitably trickles up with rippling consequences, because the system is not designed to handle such a failure mode, having this deadline dependency as its core interface between all the parts.
If you're not convinced of that, "follow the money": the consistent metric across the software industry to evaluate an employee's performance boils down to "deliver on time". Three months down the road, the rational explanation to delays of mandatory rabbit holes and very legit preempting tasks is forgotten, even when acknowledged by management. You're told to factor all that in, but estimating unknown unknowns is by definition impossible (best case you go statistical, with deadly outliers around the corner, which amounts to say it's a bet). Experience reduces these unknowns but they're still around, everywhere. Overall, you tried telling the hard truth with absolute candor were left helpless when it backfired.
Ultimately, whatever the process, the stark reality is that to get shit done you have to take part in the make-believe dance and lie - white lies, because soon enough one realises that the other kind of lies also backfires very quickly - in a way that still communicates some form of deeper truth: "progress is being made, it'll be done (when it's done)". Inflate some numbers, tune wording when reporting, steal time by bleeding some for task X (reported or skunkworks) into task Y. All the reporting meetings and documents entirely become smoke and mirrors, but are somehow important as they're oil to the whole machinery. Two parallel universes emerge and graciously evolve in parallel.
This sleigh of hand is the missing buffer catering for the lack of acknowledgment that producing software is entirely different in nature than producing hardware in a factory. It is in essence more of a creative act, albeit a strangely misleading one because of its technical component. Lots would be amazed as to how much closer it is to advanced drawing or musical composition than it is to more "material world" engineering (although the rigorous process of the latter certainly helps for technical aspects), and taking classes of the former would probably do a lot of good.
If you are a manager and this makes you angry, you're one of the bad ones.
- burn-down / velocity charts
- retrospectives
- poker sessions
- daily stand-ups
- user stories and related tickets (eg in JIRA)
There’s probably more ...
Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff.
As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we don’t deal with any of the above shit. Which of course is sure to change as the company grows, as that seems to happen often.
Our current way of working (remote company, 4 people):
- 2 calls a week, which tend to last about an hour.
- We discuss work for upcoming week or future stuff.
- We try to deliver every week on whatever was agreed upon at start of week.
Actually, previous company I worked at, was a bit bigger (35 people), but also very little rituals, at least for devs. There was a support department that did the JIRA related stuff. And we had like 2 day-long meetings every year to discuss personal goals/work for next half year. But afterwards just a short weekly meeting for team (sometimes lasting only 10 minutes), no stand-ups and such.
The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship.
Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to have them requested by my teams. Who knew.
If the EM is not there, those are not actionable. What we try to do is: do the retro by ourselves, and invite the EM at the end of there is stuff for them. Usually they are not available though...
I've told my team anyone is welcome to ask for a retro whenever for any reason, but we don't make them recurring meetings because there is too much of a temptation to find something wrong to fill the time.
But people seem to love them.
I'd prefer to spend that time putting my head down and grinding through whatever sucky thing people were otherwise whining about.
By contrast, I've worked with scrum masters who were strict about the process and insisted _every_ retro needed to have at least one improvmenet or action item out of it, preferably more. I found this pointless and I've rarely seen them actually followed up on.
When I started at my current job, I naively looked at the bugs and tasks assigned to me, and started picking and fixing the highest priority tickets.
Then I was informed, "Oh no, that's not how we do things here. Don't look at the priority, just work on what is assigned to you in the current sprint."
I had never heard of sprints before.
More recently, I had a conversation with my manager and asked, "Do we really need sprints? I've been in this business a long time. 10, 20, 30 years ago we didn't have sprints and somehow still managed to produce great software."
The reply was "But if we didn't have sprints, how could we possibly measure the team's productivity and individual productivity?"
I knew I wouldn't win this debate, so I politely let it drop. I just wanted to sow some seeds of doubt.
In all fairness, my manager is a very reasonable person. But when this devotion to sprints is ingrained in the entire company, it is hard to question it or get away from it.
At least we don't do daily standups!
I once found that a system was getting a little expensive. As, AWS was billing us a million a month expensive. I figured this out, and came up with a plan that would cut it down to 80 thousand by spending 4 days: You know, a mild, 11 million a year of savings. Management insisted that the work had to go through scheduling, and intake, a process that would involve zero developers looking at anything, but would delay doing the task a month and a half.
And no, nothing the team was working on came even remotely close to that ROI. Following the process just cost an extra 1.5 million dollars.
I read it as that the opportunity cost would be lower.
"Do you really need to measure that, or perhaps something else is more important?"
A more enlightening question might be what actionable information about productivity they are gaining from the sprint-based metrics.
- burn-down / velocity charts: Teams use this at standups to make sure their sprint isn't drifting. That's why a burn-down should be tracked in hours and not points. With points, the data isn't actionable in a reasonable amount of time. The the team sees a problem, they might make use of a pre-determined emergency procedure to address it.
- retrospectives: Yeah most retrospectives are horrible. Retros should be like post rocket test - examine your telemetry deltas to see what changed (edge cases, governance,compliance, desgn, etc.) These conversations are not forced, but good teams always repeat the same data analysis unless they intentionally change it.
- poker sessions: Yeah this is totally misunderstood. Pointing stories is about snap reactions to comparing difficulties and complexity, and that's it, move on. Teams will tighten up estimates when they do an implementation plan in sprint planning. So they don't sweat estimates.
- daily stand-ups: The whole team is responsible for the sprint backlog, nothing is assigned, everything is volunteered. So if you're working on something that is going south, or you have some extra capacity, let your team know about it. The team will work together to scale capacity to get things done, which is how they can disappear on Friday afternoons.
- user stories and related tickets (eg in JIRA): Well yeah, Jira sucks. So do all the other major backlog tools. Jira gets addins, but the fundamental approach to backlog development hasn't changed in a decade. (I'm working on a soln from scratch, btw).
Also, user stories are meant to be work-items with enough signal so they can be executed with certainty in a sprint. So that means a lot of refinement to the left of the story must occur to get rid of the noise (epics to features to stories to tasks). Once a team says a story meets their definition of ready, that story can be scheduled for a (timely) sprint. Team members may be doing hard-core story refinement because of some technical hurdles, so their time outside of development during sprint can be pinned down with the team's capacity plan. BTW, capacity plans and implementation plans belong solely to the team. They're nobody else's business, including managers to CEOs.
I don’t follow this?
The arguments against estimates in hours are well known as this point.
The best scrum teams I've worked with maintain a very important survival notion: We don't know the full minimum survivable solution today, but that's ok because we do know enough to get to tomorrow at least. We survived another day. Point is, estimating was never meant to be an answer. It was just meant to kick off discovery. And that's a great way to start because humans tend to be exceptionally good at quickly comparing things for difficulty and complexity. It's an instinctive survival skill.
Ultimately, well after estimating this scrum team will do an implementation (tasking) plan in hours if needed during sprint planning. They will compare that plan against their team capacity plan in hours. If the implementation plan blows out the cap plan by say, 30% then that's a warning sign and they'll tell the PO they need to drop a story for the upcoming sprint. If the cap plan compared against the imp plan shows a 30% surplus, then they will pull in a stretch story and bump their velocity, or won't tell the PO and maybe go play golf at the end of the sprint.
So the story pointing exercise just gets the team some data that helps them get to the next day (survival speak). There's still a lot of story refinement to be done, before they will tell their PO a story is ready to be pulled into one of their sprints.
When teams pull in stories to their sprint backlog, the team is committing to get that story done, so they need immediately actionable data on what's going on at every standup. If the burndown was done in points, the graph ends up looking like a straight line for days with sudden dropoffs toward the end of the sprint - that hides problems. So a sharp team will use task hours instead. Makes the plot a lot more actionable from day to day.
Here's a popular presentation I do on estimating, and why we tend to misunderstand its usefulness. "How to do estimating while being chased by a rhinoceros:" https://github.com/jamesksmithiii/Presentations/blob/main/Th...
Also maybe useful: Drawings for what to cover in scrum ceremonies: https://github.com/jamesksmithiii/Presentations/blob/main/Ce...
The survival terminology is really off-putting. And what’s the obsession with golf? This doesn’t sound like any scrum team I’ve worked with or would want to be a part of.
Estimations are meant to be exactly that, estimations. Don't try to make them anything else. They offer a grey answer, so use the best tools you have to deliver that grey answer. In this case, it's simply comparing challenges for size, complexity, etc. Don't try to do estimations in a different way just because you want an immediate answer. Estimations are meant to be a starting point to get to a minimum survivable solution. That's how humans use instinctive tools that use the least amount of energy to get to a point that they can survive a challenge. Think about the elliptical example.
In scrum, estimations are the conscious way to get this discovery kicked off; they aren't meant to be an answer, because you don't have enough data yet for a solution. They are meant to be a starting point. Iterate to the solution. When you think you have enough signal for a solution (the sprint), do your final check and balance, which is a tasking plan in hours, during sprint planning.
Another example: The year is 1929, and you're asked to guess the weight of the Empire State Bldg before construction has even begun (1931). What answer delivers more survival information? 180,000 tons, or this: "Well, we know each floor is going to have x concrete, y steel, but not sure about the other construction materials. So it will be something like (x+y+?)*#floors. If your life depended on it, which answer would you go with?
You are looking for a number, and that's why people don't understand what estimating is about. The incorrect approach is like, "Well these estimations are crap, so let's change the estimation methodology." Yeah but it's still and estimation, and you already have a great instinctive tool to make those estimations via relative size comparison, which can be done so quickly, it could literally save your life. Instinctively, we accept that, conscoiusly we don't, so we turn into ill tempered Veruca Salt.
Regarding the golf reference, I'm from Florida. Sorry if the attempt at levity was weak.
You need some coarse odometer to know where the finish line is. Burn-up charts are a reasonable input to that and can be very low effort. Just knowing where you hit the inflection point between new-issues added to a milestone vs. issues resolved is useful. If you can replace a burn up chart with tangible test results matrix or similar - even better.
> retrospectives
I have never found per-sprint retros useful, either. I guide teams to do a retro when the issues raised in the previous retro are resolved. WIP control FTW.
> poker sessions
In my experience, planning sessions are one of the most impactful parts of the stereotypical scrum process for three reasons: (a) Planning creates a consensus within the team about what the story actually means; (b) Planning often leads to someone proposing a good 80/20 trade-off or raising an important point that avoids future re-work or unexpected tech debt. (c) Breaking big tasks into actionable, independently useful, small tasks is one of the hardest things for junior developers to learn. A lot of mentorship and teaching happens in good planning meetings. I encourage teams to try planning for the benefits of the process and not worry at all about fine grained points - "trivial", "medium", "unknown" is typically enough. Lots of mature teams will plan ad-hoc as they are ready for new work. This is my personal preference. But teaching teams how to plan effectively in a weekly planning meeting is often a good starting point.
> daily stand-ups
Standups that are control points for managers and expensive status gathering shortcuts are horrible. standups that are self-organizing, especially for teams that have ops + dev responsibilities, can be really useful. Nothing wrong with making a plan for the day - it should just take 10m.
> user stories and related tickets (eg in JIRA)
You should write down what you want to do somewhere and a few checklists go a long ways towards improving quality management.
I have never found scrum to be a good process (like the article, I find it very grinding) and I strongly agree with the posted article. But a good dev process likely includes all of these elements in some shape.
A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent on these ceremonies (sprint planning 1 hr, sprint retro 1 hour, daily standup 15-30 minutes. Plus whatever prep is needed and the interruption time.) For many companies this is a 20% or more overhead that's mainly busywork because you still need the additional meetings to understand what you're working on.
At the time it was incredibly freeing and fixed a pretty awful and behind waterfall project. I was (briefly) at a startup a couple years ago that said they "did Scrum" and what a clusterfuck that was - all the managers meeting daily with devs to see if they were behind and scold them if they were. See ya.
One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another.
In practice, I don't think I've seen scrum run without a manager in standup, ever.
I can run a very near standup when allowed to. I also think it’s a waste of time. Just send weekly updates to a group email, or something.
The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.
Honestly, the recurring complaints with scrum, agile, etc basically boil down to this: shitty organizations can make any system miserable. People generally are blaming the intermediate cause (how we do scrum sucks) rather than the root cause (our company sucks and nothing would work).
You haven't truly experienced process misery until you've done a 4 year death march in a waterfall process.
Can anybody (not PM/leader) give 1 example of a company where they saw scrum being done "correctly"?
crickets
I guess scrum is fine and people just don't know how to do it properly.
How could scrum, the product, possibly be to blame for that even if it sucks? Or, at what point is it reasonable to blame the PM/leader for actively and knowingly practicing !$scrum while pretending it's $scrum?
Is the gun with a 180º bend in the barrel, with a caution label that says "WARNING: Don't shoot yourself in the face", that sees everyone who tries using it shoot themselves in the face the user's fault, or could we say that the product is faulty?
If a product relies on weasel words to try and pass its flaws off as being the user's fault, at what point is the product to blame? If one person uses it wrong, perhaps you can say that one person was doing something out of the ordinary, but when every person uses it wrong...?
Then it's not a SCRUM process at all. Case solved.
https://scrumguides.org/scrum-guide.html#scrum-definition
https://scrumguides.org/scrum-guide.html#daily-scrum
Yeah and communism also works in theory :)
I've lived the first 14 years of my life under the Romanian communist dictatorship so no.
Let's put it this way. If it's the property of the people it's not everyone's in practice, it's no one's. So you're free to slack, cheat and steal from your "property of the people", you're cheating "no one".
> post-scarcity is a necessary precondition
There is no post scarcity. The goalposts for scarcity just move up.
That doesn't make any sense. Communism's defining feature is that there is no longer a state. How can you recognize Romania, and especially a Romanian dictatorship, without there being a state?
Perhaps you're confusing communism with rule by the Communist Party?
- Communism is a work of science fiction that imagines what life is like in a post-scarcity world – indeed, science fiction that some people would like to see become reality. Star Trek is a more modern adaptation on the same basic idea, which you may be more familiar with.
- The Communist Party is a political group that, at least on paper, is focused on achieving post-scarcity through capturing the means of production. It was once theorized in a certain Manifesto about Communism that post-scarcity would not be achievable through capitalism as the capitalists would set up barriers to seeing it through, and that the way to protect against that was the bring the means of production into social hands. Hence why the Communist Party is so-named.
But that would be like saying that democracy doesn't work because you don't like what the political party known as the Democrats are doing in the USA. Or that workers don't work because you don't like what the National Socialist German Workers' Party (Nazi) did.
> There is no post scarcity. The goalposts for scarcity just move up.
Perhaps. But it remains that communism cannot exist without having achieved post-scarcity. How could it?
Seriously? Who takes all the resources and allocates them "according to each person's need" then? :)
> But it remains that communism cannot exist without having achieved post-scarcity. How could it?
All the scarce resources are being stolen^H^H^Hshared in common.
Communism predates the idea of post scarcity by a hundred years or more AFAIK.
Yes. Communism's key attributes are that it is classless, stateless, and moneyless.
> Who takes all the resources and allocates them "according to each person's need" then?
We'd need to know more about how post-scarcity is achieved in order to answer that question. Star Trek says the replicator is responsible, although that seems unlikely outside of the imagined Star Trek universe. Based on what we can see today, I'd guess robots. But this is all speculative as we don't really know what post-scarcity truly looks like, or if it is achievable at all.
> Communism predates the idea of post scarcity by a hundred years or more AFAIK.
Are you referring to what is oft referred to as primitive communism?
Although I find it hard to believe that humans have ever not thought about post-scarcity. It seems like the first thought/dream anyone would have when first faced with scarcity constraints.
Did communist utopians realize it doesn't work so now they're adding "post scarcity" to it to make it work?
Will they add "AI" next?
Edit: "Based on what we can see today, I'd guess robots." Oh yea, "AI" is next.
Did TV fanatics realize that Star Trek doesn't work? What does this even mean? Communism isn't something real, it is a work of science fiction that details an imagined world after post-scarcity. Always has been, probably always will be.
Hell, even if we actually do reach post-scarcity some day, the chances of going the communism route are about as likely as us going the Star Trek route. Reality has a way of turning out quite different to what you envision. There is effectively no chance of communism becoming more than science fiction.
Is that what you mean by "doesn't work"? That it will never be more than science fiction? In the same way aliens, time travel, etc. "don't work"? Fair, I suppose, but that makes your communism obsession rather bizarre.
> "Based on what we can see today, I'd guess robots." Oh yea, "AI" is next.
How do you foresee AI being useful? Robotics is by and large how we've achieved post-scarcity in food production. If we were to achieve full-on post-scarcity, chances are we would do so by finding additional robot applications. We're not that creative as species. But who knows.
I suppose in your modern communism they'll blame the "AI".
If communism ever is realized as more than science fiction, it will almost certainly be because of the USA's efforts. There is no chance Cuba will get us there. Of course, their official claim of seeking post-scarcity is only for pretend to keep up political appearances. The USA, in contrast, is actually trying. You might say ironically, but I'd say that Marx just got it wrong and that capitalism, not socialism, is the most likely path to communism.
They also tend to make the stand-ups one hour long.
while it's not quite as bad for us 30min are the norm and it spilling to 40 min not rare and that is with us trying to cut it short
but too many other things are conflicting with short dailies, mainly sure to company structure/size
(I wish I was joking.)
I'm Head of Development in a midsized SaaS company. Another team's PM went for paternity leave and I stepped in to lean in on any needs.
I discovered that the team of 10 people were using close to an hour a day on stand-up. A culture thing, apparently.
I joined he stand-up a few times, slimmed the scope of the conversation to roughly 10-15 minutes.
This worked for all three months of the PM's paternity leave.
PM returns, is pissed over the change and in less than two days, the stand-up is back to almost an hour a day.
I said in another post that I hated all the ceremonies, including standup. And it goes without saying that means long standups.
But, one team I was one, we had long ass standup and it was perfect. It was very dev-driven, we were facing hard problems, and that was our time of the day to really nerd out. The PM would get bored after about 15-20 minutes and then we'd be working out how to deal with the issues that faced us. Sure, it could have happened at any point of the day, but that was our designated time where we were all in the office (this was pre-pandemic)
Hasn’t the team all quit?
This, this, this and a thousand times this.
It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".
It's like when discussing communism with some diehard fans - when you point out the flaws, the response is always "well that wasn't real communism that's why it failed".
Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
We don't have any successful countries that use communist ideologies because central planning is destructive and the abolishment of private property is catastrophic. Calling for communism is tantamount to wishing for death and destruction. The path to success through communism is something like China where they eventually learned to do the opposite of communism and got great results.
We do have lots of successful companies using Scrum. They hire Scrum masters. They see Scrum as adding value. The scrum ideal is generally a bit of a compass towards higher value add. So scrum as an ideology seems to be net-successful even if implemented wrong.
How do you get to this conclusion? I haven't seen any implementation of scrum that didn't slow down development speed, due to unnecessary meetings and micromanagement.
This might be that I've only seen 8 or so "implementations". If there's any evidence that scrum is a key net positive I'd like to see it at this point.
Kanban IME can work well if the manager understood the core principle: Limit amount of concurrent work, use daily standup to prioritize work and unblock people hitting the multitasking limit.
Sadly this concept which is the core tenet of Kanban and can be explained in one sentence was still too much to grasp for some managers, but I've at least seen most Kanban implementations be either a net positive, or neutral.
I might be biased by my own experience, but I still need to see a Scrum implementation that doesn't grind productivity to a halt.
Interestingly, if you want highest value then for software it is best to use a high-variance strategy. But that is never going to come out of a company large enough to need professional management because it is pointless to manage large numbers of people to a high variance strategy. Google is an interesting case study where they tried that and, by and large, flopped. It makes more sense to spin out separate companies VC-style. I assume programmers occasionally quit companies, build something and sell it back to the company at extortionate prices which would be the right way to do fast development.
That isn't to say professional management is bad - large companies need it. It is just a fact that large companies aren't good at development and something like scrum elevates them from total failure to unproductive but fumbling in a good direction.
While "scrum" is a proper name with a single definition that anybody can look that is absolutely not precise enough for anybody to follow. By definition you can't really do scrum right.
Yeah, that would be the correct response. If we were discussing communism, and you started complaining that under communism everyone has to stand on one leg and hop up and down, a communist would correctly point out that hopping on one leg is not communism.
>Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
This is like saying that exercise isn't useful because most people who attempt it don't stick with it. Doing actual scrum is hard (particularly for managers), so a lot of teams can't stick with it. That doesn't mean it isn't useful.
Scrum is a victim of semantic drift. The vast majority of people "doing scrum" have never read the guide and are just doing things that other people have told them is Scrum.
It's not Scrum's fault that people have hijacked its name for something completely different. It happens often.
What people call Scrum isn't really Scrum. What people call REST isn't really REST. What people call DevOps isn't really DevOps.
People using the wrong word for something doesn't mean the original definition of the word is invalid.
It's fairly different from the Communism situation in that people discussing Communism are generally talking about the same concepts and the debate is whether or not they're feasible. With the other terms I used above, people are using the same words to talk about completely different concepts with different definitions.
It doesn't make the original definition invalid, but words mean what society uses them to mean, which changes over time.
So agile & scrum do in fact today mean constant status meetings, treating professional developers as mindless cogs and keep everyone in line with a constant stream of tickets chosen by someone else.
Perhaps it's not what it meant in some idealistic manifesto lost to history, but it is what it means to developers employed in the industry today.
Are those who have toxic experiences with scrum actually a majority, or are they just a vocal minority? I'm curious if there's any data on that.
I agree. The issue is that I have literally never seen it done "right". It doesn't practically matter what agile is theoretically supposed to be, it matters what it actually is.
Scrum contains so many pitfalls that it's inevitable to get it wrong. Oh, the Sprint Review is NOT a report to management? Please do tell me where this then happens instead. If a manager can attend a 1 hour meeting to summarize the 2-3 weeks that the sprint was about, it will be abused.
Yeah, it's literally the worse thing you can do. I mean, not for the original definition of literally, but the new definition of literally, which is literally not literally, and actually literally in the dictionary with the definition of "not literally".
Just saying, at some point, the definition everyone uses becomes _the_ definition. And yes, I'm not a fan either.
Ironically, the last time my team was doing Scrum-according-to-the-textbook, it was a decision of the developers... and then the higher management told us to stop, because the entire company decided to switch to "Scrum" (as in: endless meetings with managers present, no retrospective, but we call it "Scrum" because it sounds like we know what we are doing), so basically we had to abandon Scrum in the name of "Scrum".
My conclusion from this experience is that Scrum-according-to-the-textbook never happens as a top-down decision. The managers have strong ideas about how things are supposed to work, and they are unwilling to change their ideas, although they may agree to rename them to "Scrum".
I actually get the real-communism-has-never-been-tried vibe from people who say "scrum sucks, agile is the good idea". Scrum is simply what happens when Agile meets corporate reality. Make "agile" a popular buzzword among the managers... and soon you will see people complaining that agile in practice means endless meetings etc.
I haven't seen working communism though and never heard about it.
Well, you are.
Give this shitty process you’re being forced to follow some other name and stop blaming Scrum.
Do Scrum properly and you’ll see why it’s actually fairly good.
> if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
You can’t say that as you’ve not actually done the thing.
The main problem is that most managers and senior company people feel like they want more control that scrum allows them to have, and their use their power to overrule it. That’s their problem and not the fault of the Scrum system.
You may be onto something with communism. It’s definitely not resiliant to the kinds of paychopaths that end up dictators for life. I wish I knew why. Probably something to do with threats of violence.
Nitpicking, but the Soviet Union, for example, never claimed they were already a communist state. They were the "Union of Soviet Socialist Republics", not "Communist Republics". Their idea was that, to have communism, you must have a transitional form of government first, "socialist government". The USSR even once had a motto, "we will build communism by 1980".
It's like if someone said they were following some other development process which would eventually lead them to Scrum. But no one does that and just calls it Scrum :)
If your process to trim the hedges is much faster than normal, but also involves juggling chainsaws at the same time; it's possible your process is bad, because most people will fail to do it the way you've laid out.
(I'm agreeing with you, if that wasn't obvious... it's a pretty bad analogy, to be fair)
1) Anything longer than 15 minutes is insane 2) What do you even talk about for an hour? 3) Why do you even do standups for design work? What "blockers" could you possibly have that require daily, 15 minute tagups with the entire crew?
On #3, blockers exist more on design than on operation. But the idea of a daily meeting to solve blockers is crazy-stupid. Imagine if operations did this, every time somebody's work get a wrong input, you'd stop their line until the next morning. That's why operations dailies aren't about blockers, and instead about information sharing. But design work doesn't have separate teams that need to share information, so they invent a bullshit reason to still have the meeting.
We once had 1 hour long standups. The reasons were:
1) large team
2) many devs loved to go into detail about their work, and no one stopped them
3) the expectation was that a standup must be about describing what you did yesterday, in detail
What we did:
1) split the team into subteams where each team has their own standup (down to 5-15 min)
2) the standup's facilitator now stops devs from going into too much detail, "you guys can discuss it further after the standup"
3) now the expectation is that a standup should be about checking the project status and if there are any blockers, and that's it, you don't have to recount your whole yesterday in great detail
I said this in another comment, but a standup I'm part of tables these until the end of the call; and then anyone not involved in that conversation can drop off. It seems like a reasonable compromise to balance the need to get people together to discuss something against the need to not keep people tied up. It helps mitigate the issue of people not wanting to plan a meeting to just "talk about" something (when that's actually what is needed).
Which I suspect comes from the manager/PM going “so what’d you do yesterday?”
I’ve been taught, and I teach others, that in the standup you drive the questions. Usually along this framework:
1) I assigned you Task A yesterday. Did you finish Task A?
2) If yes, awesome. I have Task B for you. Or, go help Bob with Task C.
3) If no, cool. Why? What happened? Is there anyone in this circle that can help you? How can I help you.
4) Open Ended Questions/Comments that we need to circle up on later
5) General Announcements
15 - 30 minutes depending on the size of the team, scope complexity, etc. No one should be talking for more than two minutes. If whatever they need takes longer than 2 minutes, that’s taken offline and a flag something is wrong.
If you’re going to treat the software development like a factory, you must assign and manage work like a factory.
If you’re going to treat it like magazine publishing, you must assign and manage work like a publication.
Pick one. And stop having hour long standups y’all are crazy.
What you described above is more like kindergarten, which is why any sufficiently seasoned developer hates Scrum with all the passion they have. It is mostly belittling, humiliating, and not even very productive at the end.
Interestingly, Scrum almost always ends up like being in the kindergarten, instead of addressing the real pain points, as it should be (eg. involve the business in the development process). But that takes real effort, which is hard, and therefore no PM or manager is interested in.
You ever try organizing and managing the work of multiple skilled tradesmen that feed into a single integrated product on tight deadlines? Do you know what works really well in that kind of environment?
Telling people what to do and then checking in on them to see if they’re doing well.
Is this kindergarten? I don’t remember being a skilled tradesmen working on building components for complex assemblies on tight deadlines in Kindergarten.
I concede that I am unfamiliar with what a normal “scrum” session looks like outside of what is said in the Agile manifesto and the many anecdotes floating around. I do know that Scrum took a lot of cues from TPS/Lean of the 80s and tried to feed it to Software.
And as far as I can see, it’s not working because the profession and the products do not fit this factory model.
What everyone seems to yearn for seems to match more closely to the model followed by magazines and other such publications. Product Management the profession mirrors more the Editor than the Production Manager, SWEs mirror writers/editors-at-large, etc.
Self respecting writers in any newsroom would balk at being subjected to daily scrums that take away from precious research/writing time. And to put some kind of regular pace on progress, metrics, etc. to what really is very bursty, deep focus work is also ridiculous. Whether it takes you 5 hours or 5 days to write the piece, so long as it is of quality and meets the deadline what does it matter. And even if you miss the deadline, you could alway be slotted into the next issue unless the piece was a cornerstone piece to the issue, in which case a good editor would have assigned it with ample time or given it to the best writer on the roster.
Hell I like this analogy. Might spend more time thinking about it and talking to SWE friends about it. Feel free to expand. Maybe this will free everyone from the shackles of Scrum.
2 years ago we had 1 hour long dailies because the team was too large. We split into 3 subteams, each has their own stand-up. Now it's down to 15 minutes max.
Daily: should average at 10 min, 15 min is really the maximum. Including prep. So 5-15 min. No status updates! The daily is about getting people unstuck with their current tasks and quickly aligning on what to do next. If it is not useful for the team, the implementation is wrong. Doesn't mean it always has to be useful and interesting to you, there's a difference. Management stays out of the daily.
Sprint planning: the sprints are the compromise to management so we can have some sense of progress, so this is of course the one meeting that is useless to the team getting work done and can hamper productivity. Just make it quick.
Retro: you should do a retro about if you think the retro is useful and why/why not. If the team doesn't think it is, either change it until it works or make this the very last one. Management stays out of the retro. ("But are you then not doing scrum anymore?" "So what, save the pedantry for writing out the functional and technical requirements please")
Thing is, you do need to understand what you are working on, and it needs to be more or less the same as what your team members think they are working on. If you are 100% efficient at building the wrong thing, your 0% overhead amounts to exactly nothing, and the 80% efficient scrum team is infinitely more efficient. Though these extreme cases are usually a problem from higher up, without any way to align your work you will usually not be efficient. And if you are, then good for you, don't follow scrum like its some cult. But most teams need a little coordination.
Basically if anybody feels a meeting (or anything, really) is a waste of time, there is a problem that needs addressing. And the problem is not the feeling, but what is causing that sense of waste. Take it seriously, it is almost always signaling a flaw in the process. Learn how to talk about this in the retro and get to the bottom of it.
The retro is about debugging anything that isn't working optimal in the team. If you cannot find any bugs and fix them, then you are either perfect or just not good at debugging, and I know which one to bet one to be the most likely. One sure sign a team isn't very capable is when there is a lot of blaming involved. Usually external factors or tools get the blame, but in very dysfunctional teams people blame each other.
If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.
When nobody manages to do the thing right, then the thing isn't good. It doesn't matter what platonic ideal you hold for it.
Put another way, if you enter the olympics for breakdancing, and then just move your body around in a floppy way, you will not win the gold medal.
And the reason they are telling you that: because an agile process that is working well is like night and day to all the crazy processes that preceded it. When it works, it is amazing!
Huh, this is same for all employers I have known or worked at. Maybe on some distant planet it is done right.
This I don't understand. Why do people need a daily to "get unstuck"? Are they not talking to each other? If I have a problem, I can proactively work on it, and contact whoever necessary. Unless you are very junior, this should not be a problem.
That said, the 12 Principles of the Agile Manifesto offers another solution: Get rid of management entirely. It states that developers are best to work with the rest of the business collaboratively. Which is the irony of Scrum claiming to be Agile: Only management wants to use it, defying Agile to its fundamental core.
They all exist to give software development the illusion of predictability, but saying that a project should take “x sprints” is just setting a deadline with extra steps.
The way you get good at estimating is looking at your database of experience. “I did a task similar to this in 8 days”. Calendar time is real and punchclock time is real, either can be measured. Story points are not real and not measurable and they leave you lost at sea thinking that estimation is impossible, a scam, etc.
See also
https://en.wikipedia.org/wiki/Function_point
Which is also a kind of development “funny money” but which have a somewhat rigorous method to arrive at estimates.
Maybe best to just treat it as a classified secret that nobody actually needs to know. People inside the team just need to know that their stories are arranged in correct order of priority. People outside the team actually do need time axes on their burndown chart. But they don't need to actually know the toxic voodoo that was performed to produce the conversion.
:-P
But actually seriously. Nobody needs to know that number.
Here's the feature list; here is where on the list we'll definitely get to, here's where on the list we definitely won't get to, and everything else is some shade of inbetween. Now, would you like to adjust the priorities of any of those features, or would you like to change the deadline?
Sprints end with some kind of demo, retrospective, and sprint planning designed almost entirely to keep PMs and managers in the loop and happy. Reports are generated, spreadsheets with a few quarters worth of tasks are updated, and PMs or managers get to run that further up the chain, presumably to make it clear that great progress is being made under their supervision and well run scrum methodology.
There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum. Scrum is iterative, by design. It's supposed to evolve with the CLient's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that."
In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key.
When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic.
When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
I've never been on a team using scrum that didn't have a project manager or product manager as part of scrum (or both). Most often they have been my scrum leader.
Scrum is supposed to be self-guided, but I have never seen it implemented on a team of any scale.
I also wouldn't expect a team without PMs, whether that's project managers or product managers, to be very effective. Someone needs to be focused on keeping the project moving, and often the skills needed for a scrum leader/master overlap greatly with project managers. Someone also needs to be focused on the product and how the team's efforts fit into the longer term product goals. If that isn't anyone with a PM title it will be someone else playing that role with everything but the title.
2) no matter what "agile" was supposed to mean - managers anyway interpret it as devs having to be very agile for them all the time ...
There’s been plenty of discussions why the “what could have been” got buried in certain people jumping in, creating weird layers and interpretations of some process for their own profit and ego.
Chinese whispers then lost in translation.
We did 2 week sprints, but that really was more to keep a remote team regularly in touch and updated. Sprint work was very much up to each dev, and at the end of the sprint anything that changed or slipped was just chalked up to lessons for future work.
That did change eventually, both as the team grew a bit more and funding started to run low. Eventually we had the worst of both worlds mentioned in the article, sprints with more rigid goals leading to a quarterly goal driven more by marketing goals than anything else. Throw in the fact that the still rather small company ended up with one person making product, marketing, and even technical decisions and we devolved into glorified code monkeys pretty quickly.
But this is extremely fragile, because it takes a lot of energy to fight external people (often product people) who want to remove the self-management aspect.
Unless this is in the DNA of the company, you can't have agile or real Scrum, because it threatens those kinds of power-grabs. For this to work, you literally need someone threatening to fire people who attempt to micromanage others.
What would you prefer besides agile?
I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Everyone should just work on things until they are done. He argued this earnestly and didn’t recognize that there are opportunity costs and conflicting priorities and the need to choose what to do. He earnestly argued that every single user story should be worked on in order of entry until it was completed. It would have been precious how clueless this suggestion was if he didn’t spent 20-40 minutes a week arguing this as an explanation for why his items weren’t done and why he was civil disobediencing to refuse to estimate or report time on tasks.
Like, the constant micromanagement and process lawyers pushing you down makes me misarable.
At least with classic project processes you'd have some oversight plan to follow.
Plenty of learned people have made defenses for having no estimates. If you want to make the opposite claim, you don't need to use a junior dev as a strawman.
For simple activities you can get by with no estimates but with dependencies estimates become more and more necessary.
I have personally only ever had success with estimates that were "is this a project, or is this a task that belongs to a project". Perhaps stretching to t-shirt sizing of S, M and L. Anything beyond that, say, comparing two projects to be able to prioritize and see the opportunity cost etc etc is a fool's errand.
From The Black Swan by Nassim Taleb:
[Critics say that] the maps we had were better than having no maps. [...] This is the strangest of errors.
I know few people who would board a plane heading for La Guardia airport in New York City with a pilot who was using a map of Atlanta’s airport “because there is nothing else.”
It is, however, possible to provide more information than "whatever" about how long it will take to achieve a goal. I have had goals I've worked on that were summarized with things like
- Could take anywhere between 2 days and 2 weeks, depending on factors
- Has an external dependency on X, and we don't have any insight into when X will be available
- May have other external dependencies, but we won't know until we're a few days into the work
- Not sure yet what the complexity of using <this API we need> is, so we'll need to check back in with more information once we have some time to experiment with it
- Expectation is about 5 days, on this, but it could be as short as 1.5, and could be as long as 3 weeks, depending on some factors
All of those things are more information than you had before, and allow the people that make decisions (which may be you and your team, or may be someone higher up the chain) to make _better_ decisions (or at least, better informed decisions)
And if you're working on something that you literally have no information on what's required for it, what the complexities might be, what the unknowns might be, etc... then perhaps the task you should be working on is "Identifying the work required to achieve <goal>", not "<goal>".
Unless you are working on ChatGPT-6, i assure you, you can definitely estimate how long things will take. your estimates will not be perfect, but they will be good approximations for guiding development.
Even OpenAI by now probably is pretty good at estimating how long the next ChatGPT version will take to develop, since they've done it 4-5 times already.
Alway always distrust someone who says "we are doing things that have never been done before". At the very bleeding edge (OpenAI, SpaceX), you are iterating on something that has been done many times before, but with a small innovation.
"never done before" in my experience usually translates to "this combination of things doesn't have precedence internally [to the team or company], so I have to figure out how to glue all of these parts I don't understand together".
If it is not the first time, then you already have the code and hence the time it takes is 0.
There are cases where code is similar to code you've written before or you cannot just copy the old one due to licensing constraints. In this case estimation is easy, somewhere between an hour to a day or two.
Anything larger can be broken down to hour to day or two chunks since it has been done before.
All great, except this last case simply doesn't exist for the type of work that I do. And that is true for many people, software is extremely unpredictable because the stuff you need to build on top of might as well be quicksand.
I’m a fan of Taleb, but also a fan of using good maps. Note that Taleb isn’t advocating no maps at all, just that it’s stupid to use the wrong map just because it exists.
I agree that I’d rather have no estimate than a bad estimate, but it’s not like those are the only two options. I want a good estimate or at least a useful estimate over nothing or bad.
Beyond that, you’re metagaming and that is going to end up either not being worth the energy invested or a net negative. I say energy not time because there are only so many niggling arguments you can have with coworkers before they push you into traffic. Each petty little argument that could have been about something more important just runs down the clock.
I don’t think you need precise estimation down to the hour, but knowing if someone can do 4 things in a sprint or just 1 is really important because people have interdependencies.
I don’t think I’ve ever had arguments about estimates and it’s usually a really quick exercise of “I think this is a couple days” and others saying “ok.”
And on a larger team, a lot of these little things that need to be done could just be tasks rolled up into a maintenance story.
Of course when I was on a team doing Kanban none of this bullshit mattered. You just put it at the top of the backlog and it got done. Quick win, instant gratification, next story please.
And that right there is one of the biggest reasons Scrum is showing its age. It came into a world where quarterly milestones were the only time you found out how fucked the project is, and only then if you had a good bullshit detector. Otherwise it would be next quarter when you figured it out. It pushed that world down to two week resolution, one month to see past the BS. But it struggles to make good on reducing past 2 weeks. One week has more overhead, and forget about anything shorter than that.
Also I've never encountered anyone who followed Ken's advice to run sprints from Wednesday to Wednesday, so we always get the worst version of Scrum.
A big difference for what?
Usually, when someone insists on getting estimates, that's my way to make sure that they really need it. besides, it also helps making an estimate that won't be useless in the context of the decision to be made.
The lesson I learned from asking that is 1) many people ask for estimates without a clue about what they'll do with the info, and 2) when a decision actually needs to be made, the actual question is never "will it take 1 or 10 days", but rather "will that project be done by regulatory limit", or "will it cost 50k or 5 millions". And for the 2nd point, sizing every small task and adding up usually compounds uncertainty in unpredictable ways.
For projects it’s almost always a budget issue “how much money and time does it need?” And that’s important because, like money is hard to get and $1 is different than $2M. I think the time is usually related to money due to revenue and costs and whatnot.
My example was about estimating “how long to add a revert button to 5 pages” and that requires “db crud to revert stuff” so how long the latter takes affects when the former can start and if they can both make it into the same sprint. Etc etc
I've never been in a situation where adding db crud was its own user story. Usually, we group this and the button (and the metrics necessary to trask feature use) in a single item, and pair people so it can be shipped in one go.
https://agilemanifesto.org
https://agilemanifesto.org/principles.html
It's common in corporate implementations of Agile (tm) but it isn't actually some commandment or prescribed feature of Agile itself. It's actually prescribed by Scrum:
https://scrumguides.org/scrum-guide.html#daily-scrum
Business demands process for people in functions to follow. Scrum outlines meetings for programmers to attend, and specific process outputs like user stories to produce and close. Scrum is agile in business because business cannot do agile.
I personally prefer Kanban. The sprint is not a useful deadline for me so I want to ignore it.
Personally I find it more useful to organize things around useful product milestones that are actually usable and demo-able. Those might take a week, or three weeks, but probably not two months because that's a long time to go without a demo and getting feedback. Sticking to a rigid 2-week sprint with an expectation of demo-able progress after each sprint doesn't feel particularly realistic or useful to me.
The business needs to know when something will be done as they need to make promises to customers. The business also needs to know when things will be done as that is a proxy for cost - they need to make sure they are not spending more creating a thing than it will deliver (this is a hard problem as some sales will not happen until it is done and there is typically a competitor customers could go with). That is nearly impossible to say how long engineering will take doesn't mean we don't need to know how long it will take!
There isn't really any such thing as "doing Agile", it isn't a prescribed process to follow.
And saying that you use Agile instead of Scrum but dislike the invasive status meetings isn't actually congruent with the actual definitions of Agile or Scrum.
We could also get into the theory of whether it is actually possible to say how long software will take at all. Business might bevroutineky asking for the impossible using the wrong methodology for what they think they want
Trying to estimate when software is finished is tantamount to asking when the last light will be turned off forever in the warehouse.
I keep trying to tell PMs that around the release date is when developers are the most busy, including afterwards. It's not some magic deadline after which developers are no longer needed.
> The Daily Scrum is a 15-minute event for the Developers of the Scrum Team
The business doesn't actually need a daily update. They think they do because they dont want to give you the ability to deliver anything.
On daily standups, from he manifesto:
> Business people and developers must work together daily throughout the project.
> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The "standup" theatrical part isn't in it, but that begs for daily meetings in the same physical place really.
Also...no. Verbal communication isn't effective or efficient. It's fast and natural, and perhaps comfortable to many.
In our current corporate environment, effectiveness (providing the right info in the right form) and efficiency (minimizing back and forth) will probably be better achieved with documents and open chat with all the parties involved, even if (in particular if?) it means slower throughput and more deliberate communication.
This is all there is to Scrum, if it's not here it's not part of it: https://scrumguides.org/scrum-guide.html
It's like calling the electoral college part of democracy. Than just a choice one place made, it's not intrinsic.
I find it very useful for allowing everyone on the team to have a general idea what everyone else is working on. You can call out to ask for help at any time [1]. But having a 15 minute meeting each day to make sure everyone has a view of all the pieces in movement is handy.
[1] Though the standup does give a place for people that aren't comfortable calling out when they're having issues.. to do so because it's expected there.
In my experience, standups are the worst places for such people. If they aren't comfortable calling out when they're having issues, they're even less comfortable calling out that they're having issues in front of the entire class.
Sure, that's the goal. In reality, though, that's very nearly never what it does in practice. That's why I have come to view "agile" shops with an extremely skeptical eye.
Presumably you would still use iterations to track progress, Epics/Features to break down requirements, some kind of estimation to track if you're ahead/behind schedule?
I certainly wouldn't go back to Waterfall days, but I suspect many current devs never experienced that.
If you don’t trust your team to be productive for 2 weeks without communication something is deeply wrong. Individuals should be in constant communication, but few things need to be said to everyone. Scrum style management may be useful for highly dysfunctional teams, but it frequently adds a great deal of unnecessary overhead.
- Issue tracking as a common place to describe what needs to be done and thoughts / details on how it is solved. Something lightweight like Trello is ideal
- A Kanban board so people have an organised way to pick up new issues when low on work
- A weekly showoff meeting where there are few 5 minute presentations and a 30 minute "I did something really cool or learned something really cool"
- 6 month task split into 1 month ish deliverables, with a flexible deadline for each. Presentation of finished work each deliverable.
Two scheduled meetings per week = tons of dev time and freedom to explore / innovate! (Ok, three weekly meetings if you count the product-wide meeting, which is usually a waste of N-5 people's time, and I usually have it on the background while I continue working.)
We are remote, so ideally there's also one in person gathering per year to do the big vision casting and major high level brainstorming.
We still have room to improve, especially in the area of ad-hoc dev-dev communication. Always interested to hear how others do it!
That’s no easy feat and often oversimplifies the challenge of building competent teams. I think it’s achievable if you have a large budget to hire only senior/experienced devs and a mature hiring process/team. Plus, if your company has strong tech branding, it becomes easier to attract top talent too.
But if you’re at a startup with limited funding and possibly no branding at all, you’ll likely face this situation:
- Hire inexperienced but honest, motivated people with the potential to grow, and invest in mentoring them.
If you have to introduce some "process" - whatever that "process" is - because you do not have competent people and you feel like "process" will fix it, your chance of succeeding are a lot smaller IMO...
Those don't really seem like things you'd want to outsource, no matter how good the outsourcee is.
Product people are not management at least not where I worked.
I see how it might be a problem if your manager is talking to the customers.
Product people are or should be equal to dev, engineering. They should indicate priorities but should not in any way evaluate engineers especially if they have no technical expertise.
Leave good devs to play telephone through a middle-man, what we call the manager, and they almost certainly will work on the wrong things, but will have a lot more time to do it.
I wonder which is actually more productive? Agile (of the Manifesto kind) posits that the former is most productive, but Agile (of the fake kind) seems to always want to revolve around the latter. The general sentiment is that fake Agile is the one that gets it wrong, so presumably cutting out the manager is what is most productive, but more data is welcome.
The devs have the opposite problem, they can imagine all sorts of new technology that would be fun to use (for them) in helping the customer solve their problems with doing foo, and even if they understand foo from the customer's business perspective they they may not have a great understanding of how big a problem it is in the grand scheme of things and what commitment of resources and expenses are justifed in solving it.
Managers talking to managers can (in theory) draw some boxes around scope and priorities and get the right development problems solved at the right time. They may talk and realize that doing foo isn't even really a great idea and they should be doing bar intstead. Line-level employees working directly with developers will not be as likely to realize that.
Developers can fall into the trap of thinking that because they are smart (mostly) at building software they are automatically smart about all the business processes and problems and goals of the company. They should certainly be informed about those things, but they are not experts in everything.
There are a few polymaths out there, yes. But only a few.
Well, yeah, that's why they're considered good. Why they get a special title not given to everyone else. It would be nonsensical for "good dev" to refer to everyone who touches software development. "dev" would already communicate everything you need to know. The addition of “good” implies being set apart from what is typical.
Of course, if you are an early stage startup and one of your customer is half your revenue, sure. Do whatever it takes to make them happy.
Obviously not literally. What they want hasn't been invented yet, which means the words to accurately describe what they want also haven't been invented yet. But ultimately you do want to act on what they really, truly are trying to tell you. Indeed, figuring them out is a hard job all on its own.
> is a full time job.
Sure. That's the tradeoff. You can spend most of your time figuring them out, and then the small few remaining units of time you have for development will be on point. Or you can play telephone and have all kinds of time for development, but will more often than not go down the wrong path.
It's not really clear which is more productive at the end of the day. But we do know that Agile (of the Manifesto kind) pushes the former, while Agile (of the fake kind) pushes the latter. People seem to hate fake Agile more than they hate Manifesto Agile, so that does suggest that not playing telephone is more productive.
But, still, data?
But reading the article made something click: it is not about the specific process, the (lack of) autonomy is what really matters. I guess I got lucky to work a lot in teams where we largely controlled our own process, so even if we used bits and pieces of scrum, kanban or other methodologies, it was always of our collective choosing and when it didn't work, we changed it.
I did like to have rules, principles and process. A simple playbook for a daily meeting that made us not forget important things and sped up the meeting. Making things in small increments meant that I didn't have to review thousands of lines of code. Having a visual overview of work neatly spelled out means I don't have to re-think every time I pick up a new item to work on. This also prevents useless work because one of your teammates decides to work on the same thing as you without telling it. All these things make me happier and more productive working together on some big thing.
The key is that the team should be in control of the process, not some manager who isn't part of the team and affected by the process. You need to have a stake in it. The only other factor that undermines this is 'process for the sake of process'. Every part of the process needs to earn the inevitable cost its implementation is bringing. Some people seem to be happy paying the pricing without getting the value.
Somewhere in all this process stuff, I see maybe what some teams were doing but I doubt it was as rigid and I doubt they indulged in it when it made no sense. Once these teams or people are asked what they're doing right - it eventually gets defined into rules and then evangelized to people made to feel they can't deviate or improvise when the framework makes no sense. "Trust the process."
So people start wasting their time going through the process rather than using the process as a framework/tool for getting things done, they 'do' the process.
Their job is standup, their job is scrum, tickets, and points, and as a result their job is only marginally to do the things that need doing.
Company's might take more issue with this inefficiency if the workforce didn't double as something to manipulate pre and post head/tailwind to make the stock rise.
It refuses to learn from The Mythical Man-Month and recognize that building software has an essential complexity that cannot be avoided. You need smart people to implement and manage it, and you'll have to pay them what the market says they are worth.
Building software that's more complicated than a standalone CRUD system is hard, it will always be hard, and unpredictable, and to some degree stressful. No methodology will ever make it anything else because the methodology used doesn't change the nature of the problem.
Before: the team had internally decided to use Scrum. Other teams were not using it, and inter-team coordination used traditional project management methods. It was fantastic; the team worked like a well-oiled machine and I really did feel more productive. We never had crunch time. I did not feel the "end-of-sprint mini crunch" that this post describes; instead the norm was that, by the last couple days of the sprint, people were starting to finish up whatever tickets they had taken and pivoting to helping teammates get the rest of the work done. Oftentimes we'd close out all the user stories a day or so before the end of the sprint, and have all that time for tidying up the codebase, fixing small technical debt items, experimenting with new tools, or planning ahead for the next sprint. So, if anything, it was the opposite of what the article describes: the last few days of every sprint were downright relaxing.
After: The executives got wind of Scrum, and decided to standardize the whole company on it. We stopped work for a week so that we could have a famous Agile coach do an all-hands Scrum workshop. Which was fun, but the middle and senior managers were conspicuously absent. And then, after that, things kind of went to heck. The way our team did Scrum rapidly started to change as our team manager started getting explicit instructions on how to do things. We also started experiencing pressure to keep or maintain velocity. We started getting questions about why our velocity was so much different from other teams'. We could explain that the story point scale is team-specific and you can't compare story points across teams, but that didn't go anywhere. As I said, the middle and upper managers skipped the Scrum training. They weren't interested in being lectured about what I'm sure they perceived as pedantic little bullshit details.
I left that company and went to another where leadership didn't mandate any Agile methodology. My team did a homegrown Kanban-like thing. A team I collaborated closely with used Scrum. It also seemed to work pretty great. Again, possibly because we chose it for ourselves. I don't think the other team would have done as well on Kanban. Scrum wouldn't have worked so well for our team. I didn't see a problem with that. We each had different business domains that warranted very different "rules of engagement" with our stakeholders and ways of organizing the work.
Since then it's been a couple more companies where "Agile" was mandated from the top, and, apologies to Tolstoy, but they were both miserable in the same way that the first one was after the Scrum mandate got handed down from above.
Of course, this pickiness is only if I'm in a situation where I don't need to move. I can think of plenty of cases, for example being laid off, where I'd take a role in a scrum team.
IMO, if you're a SWE/dev and spending more time doing other stuff (meetings, TPS reports, etc.) than coding (coding includes the time needed to research, experiment and think of good solutions, not just actual coding), then something is wrong.
If a multibillion dollar corporation can do this, so can you!
It's kinda nuts how many capital-A Agile processes (and consultants!) produce situations that are diametrically opposed to the original ideas. Notably, Scrum is often processes and tools over individuals and interactions.
Incidentally, if you criticize the data (such as asking "Where does this data show the effort that people who spent time mentoring/pairing but didn't do the actual 'commit'? Where does the data show the effort spent code reviewing?), you should know that it won't be received well. The emperor really does not want to hear that he's not wearing clothes.
We often would go days without having a formal meeting.
But, software was different then as well. Everything is interconnected now. One team dropping the ball affects countless other teams. Deployments were whenever we felt a new one was due or at a multi month cadence. Did this introduce problems, yes, but at the same time, they came in controlled release cycles.
Nothing against CI/CD and continuous delivery, but the hamster wheel has gotten to a point where we have to release all the time. Corners are cut on everything, and testing is given lip service.
At this point, I am a manager, and SCRUM stresses me out. Either let us work from a queue, or give us a project with a deadline. Give me back a stupid gant or pert chart. At least then it was, is this done to allow XYZ, not we are going to accomplish this in the next 2 (arbitrary) weeks.
So much more to say, but I am toast.
First is the "gap" between those doing the work, and those writing the checks. (When it's the same person, this problem disappears.)
The guy editing the checks likes to understand progress is being made, and that the project both has an end and will be successfully completed.
The second problem is that by it's nature software "never ends" and many (dare I say most?) projects fail and are simply abandoned.
The moment the check writer is not the direct manager of the development you have an intractable problem. The person in-between (quite literally middle management), is often not technical. But he has to convince the bean-counters that this project is "on time and on budget".
He can't help but feel sometimes that he's herding cats. He's an irritant to those who are "doing the work" so they treat interactions with him as a waste of time. Inevitably he starts trying to measure things. (And we all know what that means.)
His job is hard. He's stuck between developers who don't want anything to do with him and higher-ups who want reassurance, bit don't really trust what he's saying.
The miracle is not that this process sometimes fails. The miracle is that it ever works at all.
And sure, you may not like your meetings, but at least understanding the game might help you understand why his job is the crappiest of all of them.
At the moment I'm having fun developing again, but I have had experience of management as well.
Obviously my experience does not speak to all cases, and I'm fortunate that most middle managers I've dealt with are competant.
I am in the fortunate position of being able to "speak truth to power" though, and generally been able to dispassionate translate technobabble into managerspeak, and help all the layers understand each other better.
I've found that when both sides understand (as much as they able) the complex demands being encountered, more realistic expectations and demands are made (and usually achieved.)
But I've been lucky. I've had good dev teams, good middle management, and good product owners. Who have all been pulling together to make projects successful. When one group is pulling the other way, things get tougher.
Managers with no domain knowledge are just an extra layer of indirection and overhead without any of the benefits. Would any IC want their career gated by someone who has zero insight into the team's day to day duties, doubly so if it's at a supposed "tech" company?
Well, sure, but that's what the daily standup is for. So that the problem solvers on the team can understand the process, the problems it faces, and, importantly, find ways to optimize it.
But it seems, for how crappy you claim it to be, those in that position don't want to talk about it in fear that it will get optimized away. Job protectionism trumps all, I suppose.
In my experience, with 2 week sprints, the business doesn't really have to think about anything outside of bite sized chunks or even how those bite sized chunks affect later bite sized chunks. They can make a snap decision without thinking about it because it can be rectified in the next sprint. Almost no-one has a "big picture," view of the software.
Before agile, we essentially did 4 releases a month (this was back on the burn a CD days), 2 major releases and 2 minor patch releases. It worked really well and we didn't get the burnout as much by sprinting a marathon. With sprints, I always feel burned out. No sense of accomplishment, no letup, working hard just gets you more work. It's like laying bricks one at a time on a wall with unlimited length.
Also feeling bad every 2 weeks because planning was really bad and now you need to say you're sorry the task has to roll over the next sprint and your manager has to explain to their manager, etc, etc.
Product Management has fallen a tremendous distance from where it used to be. PMs who have come up completely under Scrum seem to think stories and epics barely require more than 1-2 sentences and the developers should have to figure everything out from there.
Even senior people in their early 40s have completely forgotten how to specify or document anything well.
It makes me wish I worked on something that involved physical products. The whole thing with agile/scrum is that management can change their mind at any time for any reason and the process gives them justification. It works in pure software, it doesn't work in anything physical because they had to sign the POs to buy materials and parts.
Correction, 4 releases a year, or one every 3 months.
Just to call it out: Having CI/CD doesn't mean you have to do all these things, or do scrum. It's imho just good engineering practice. I have it in my side projects, and I've had it at work on a Kanban-driven team (as well as on scrum).
It removes disputes over build process (eg, nobody can ever say "well, it complies on my machine"). It is a form of build/deploy documentation. It removes bottlenecks ("only Tom knows how to deploy that service, but he's on vacation") and stupid mistakes ("whoever deployed this last did it wrong and left a bunch of old files around").
I also have found deploying regularly is stress-reducing. For one, with CD the development environment is running the same steps, and we know it works because we do it dozens of times a week. The longer it's been since last prod deploy, the less confident we can be it'll go smoothly, whereas when it gets deployed every few days it becomes a non-event.
When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.
None of this means you have to release everything on a regular schedule (like a sprint). You can still do long running branches or feature-flag things off, Just try not to go too long without deploying something.
This is, by far, the most important reason to practice continuous deployment. I've been part of enough of these fire fighting sessions following big releases to see that it's not a sustainable way to deploy software. And yet, I've never been able to convince any boss I've ever had to adopt CD because they're worried it'll introduce more regressions into production.
It's one reason I'm really thankful to work in a certified/regulated industry. It's mandated to effectively prove your work to get the sign off. And since you can't really sell too well in the area without that cert, it's a big part of development.
But holy hell is it still hard to get specific people to test their work. They just don't even think about it.
Increasingly, iterative models are used and those are much better. For some reason since it isn’t Scrum people still insist they do Waterfall even though they do nothing like it.
Additionally, there are other iterative models than Scrum. That's pretty much the worst one out there and its only value is to inexperienced teams needing training wheels or overbearing management that doesn't trust the team.
We use Kanban boards to get an overview and prioritize work. Apart from that devs mostly manage their own work.
We're a small shop though, perhaps that's why it works well.
We do not have anything like a SCRUM master.
We don't do stand-ups, we usually don't have a per-release target for features. For example, for the past three months I've had a target of October 1st for a feature, but no specific sub-deliverables for the realeases before that. This is typical.
We don't have a separate sprint retrospective meeting. We discuss such things during our weekly meeting, even between releases (ie we don't wait).
It doesn't feel like what I've been taught and have read about SCRUM. But sure I'll agree it's closer to SCRUM than to the waterfall method.
Scrum masters are needed to coach a new team with inexperienced project manager only. Established teams don't need them.
Stand-ups can be easily replaced by a team chat, such as Slack, with even better results.
I saw very few retrospective meetings too. If everything goes smoothly, then retrospective meetings are useless.
I've worked at ~three places that operated similar to this; "minimum viable scrum" is a good name, or even better, "emergent scrum" because it isn't a process that's designed, its the process that emerges when someone toggles the "agile/scrum" button in Jira, but no one really cares one way or the other. Its a good process.
I've worked in one environment that was hard scrum, had scrum masters, extremely strict. To be honest: I felt almost no stress, but the company also delivered very little. There was a lot of "we can't get to swapping the color on that button until Sprint 18 in three months, but we'll schedule it for then". Missing a sprint was life or death, so every estimate got padded like crazy. When you took vacation, it was common knowledge that you needed to leave halfway through a sprint and come back halfway through another, sprint planning would basically forget about you. That (public tech) company doesn't exist anymore, and it radicalized me against agile/scrum: The entropic end-state of perfectly executed agile/scrum is an extremely well-lubricated machine that actually does very little.
I work for a huge corporation. My team plans and commits to quarterly OKRs and has a team meeting once a week to check in on how folks are doing. There are no sprints and no 2-week deadlines. Once a month or so we update the progress scoring on the OKRs.
Team: "We are having trouble with Bob." Manager: "Ok I'll talk to him."
Team:"We are having trouble with Bob." Manager: "Don't come to me, you guys need to deal with that in your retro."
Team: "We voted Bob off the island." Manager: 'Ok, I'll forward to HR."
Autonomous teams get more done because they have eliminated management as a wait state and will proactively scale with other autonomous teams to maximize the amount of work not done. 21st century managers need to re-focus on flow efficiencies (as business engineers), and not people. 20th century managers won't have a job in 5 years.
What if the entire company is inverted.
I think what you bring up though is an interesting point: maybe managers needs to transition to business engineering roles.
This all will play out in the 21st century. 20th century management is a legacy artifact at this point. Best example is F500s, which are generally mediocre in their execution. If a SpaceX type org (14k employees, private) gets into their space, they're screwed. Even with politicians in their pockets, I don't see how rock swallowing dinosaurs like Boeing (170k employees, public) will make it. Just the energy they have to expend to get anything done compared to SpaceX is massive, due in part to their giant management bureaucracy.
Then Scrum spectacularly fails in its secret purpose, because it adds managerial type to the engineering team and removes power from the engineers.
Instead of allowing the developers to update the statuses themselves, she will often prematurely update statuses from "In Development" to "Ready for QA" before any code is merged. Or she'll update a ticket that isn't yet being worked on to "In Development". It repeatedly causes a lot of confusion.
I think she feels the need to be so hands on with updating the statuses in order to justify her job, which, in my opinion, shouldn't exist.
"There's a person" sounds weirdly mysterious
Better? (apologies to anyone I may have missed)
My actual job was to make sure the tickets were clear, relevant and ready to work on (as opposed to a stream-of-consciousness wishlist from managers). I gathered requirements, represented the devs in planning meetings, cleared their hurdles and QA'd their work. I was basically a prep cook for the devs.
I think it was a useful role.
Although I appreciate having someone to move boxes around for me. I cry a little every time I have to go near that horrid UX.
I imagine it's still not that every development process stresses you out equally though, so it's still worthwhile considering how much stress the environment adds and why.
Then shortly after:
> Treat [developers] as respected peers, not replaceable cogs in a machine.
Yes, it’s hard to know understand the (oft-maligned) “Business Side” doesn’t bow and genuflect when they enter a room full of programmers.
I was reading The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, and I came across this quote:
Royce’s 1970 paper, which is credited with “inventing” the model, actually identifies it so Royce can criticize it and suggest improvements. He wrote it is “risky and invites failure” because “design iterations are never confined to the successive step.” What Royce suggests as an alternative is similar to what we now call Agile. Sadly, multiple generations of software developers have had to suffer through waterfall projects thanks to people who, we can only assume, didn’t read the entire paper (Pfeiffer 2012) [p. 175].
https://www.jjinux.com/2015/07/the-waterfall-model-was-straw...
> Royce’s 1970 paper, which is credited with “inventing” the model, actually identifies it so Royce can criticize it and suggest improvements.
That means people were doing waterfall then, just maybe not calling it so.
> Sadly, multiple generations of software developers have had to suffer through waterfall projects
That means even after it being given the name "waterfall", "multiple generations" kept using it.
This is making observations, coming up with a model that fits the observations, giving it a name, and arguing against it.
This is definitely not a strawman as GP or the author of the post you linked seem to think, which is why it's being downvoted (I didn't btw).
Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance.
I’m not sure what planet the OP is from, but this will never change. If you have a small team with a simple codebase, kanban is probably sufficient. In larger teams or complex solutions, the reporting just needs to happen.
In the agile teams I've been on it's been to produce success. Getting good and useful software fast.
Of course, just like there are hundreds of wildly different Christian sub-religions, there are now any number of "agile" interpretations. In the end belief systems can be pushed to do most anything you want.
If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.)
>> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress, the existence of "intractable problems", work going unfinished creates significant stress up the ladder.
In a perfect world the dev team is given a perfect spec, and a reasonable time to do it in, and after being "left alone" they deliver the finished product on time.
Given that that world doesn't exist, given that the "money we're spending" may turn out to be completely wasted (because the spec was wrong, or because the problem us much harder than anticipated), the ideal case seems unlikely to happen.
I say this not as a defense of crappy management processes, or even less as a defense of crappy managers, but rather in the spirit that understanding the problem goes a long way to solving it.
And yes, many places have bad processes and bad middle managers. I don't envy you that. But finding a way to better solve the manager's problem typically improves the relationship.
You are essentially saying “Shit is bad, give up on it ever improving.”
It seems to me that most devs don't understand the root problem, so they both don't understand, and don't constructively improve the current solution.
Improvement is not "leave me alone". Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
I think ones that are against scrum are loud about it on the internet.
When it comes to have their salary paid out they will not speak up for themselves to push back against shitty management.
Like accepting ever increasing velocity until they burn out or accepting bad requirements because business is sayin “it needs to be done now” and working blind only to be scolded they did bad but requirements were bad in the first place.
How about gym memberships and mindfulness exercises?
Is the rise of Agile tied to the demise of the three-martini lunch?
The stress at the bottom is there by design. If you start meeting the deadlines too reliably, the higher-ups will probably conclude that there are needlessly many people in the team, and will try to remove one and see what happens. Repeat until things start cracking apart.
"Wow, this is the only project in our company that works reliably. There are no major bugs ever; and all the small bugs are fixed within a day or two. I wish other projects worked like that."
"You have five developers working on one project? Isn't that too much?"
Seemingly none of them was able to connect the dots and conclude that maaaaaybe these two things are somehow related. That maybe the fact that we are not understaffed somehow allows us to write automated tests, refactor when necessary, etc., so we can keep adding new features as required and the project keeps working ok.
So they started removing the developers one by one, moving them to other projects. The last guy left on the project felt overloaded and quit.
The project still worked okay for a few years without new updates, and was gradually replaced by several new projects (because it had a lot of functionality). But the new projects only had two developers each on average, so at least the managers didn't feel like they were wasting money.
Good luck with that because higher-ups have even-higher-ups until you reach the top. The bigger the pay packet, the more inflated the lifestyle and the associated stress of missing on the ever ballooning target. It is self-inflicted and never-ending; sacrifices of the lowly soldier will never quench that thirst.
It'd be nice if we could remove stress from leadership, but I don't think that's a thing that should be my responsibility as a dev. Of course it'd actually improve the life of everyone if did, so it feel like something you should do regardless.
But then I'm taking the managers job in addition to being the developer, and then what's the point of the manager in the first place?
Anybody doing work needs to be able to estimate duration, progress, risk of delays, etc. Other people's work depends on your deadlines. Go/no go of a project depends on cost and duration.
Insight and tracking is required. None of this was done any better before agile.
Assigning Points = Roughly estimating how long it takes you to implement it
Allocating Work = Well... allocating work
Standups = Talking with your colleagues about the current work and clearing problems
Reviews = Showing your results
None of that seems unreasonable. The only thing that kinda sucks are the rigid sprints, because they just cause artificial stress by setting unnecessary deadlines.
The direct effect is organizations start systematically ignoring the forest and start obsessing over the trees, simply because trees are easier to measure. And then inevitably wondering aloud "why is velocity AND quality tanking?". Anyone with half a brain can see why - disincentivizing innovation destroys innovation.
The real issue comes from middle management folks who conjure up buzzwords whenever they need to justify whatever they think the team should do. Don't know how to structure tasks but want to look like you're in control to the boss's boss? Just throw up a Kanban board with tiny tickets and a burndown chart trending down. Sprinkle in some Agile keywords in the management reports and call it a day. And let's not forget that by 'sprint' they often mean moving unfinished tickets from the last iteration to the current one, plus tacking on surprise urgent tasks that were not planned before because the product owner never shows up to share their vision and priorities.
When I asked a manager about a particular team, he said "I don't care if they do fight club in the morning, just let them keep doing what they're doing." To reframe, high-performing scrum teams are actually anti-legacy management, they get more done, are happy (low energy state) and stakeholders were satisfied. So their rolling sprint goal was taking a half day each month and going to Top Golf . The key is, everybody on the team was a scrum sme, and understood how to work the process as a team to reinforce certainty and stability. They also didn't need a scrum master.
I've got lots of anecdotes from this couple of teams, what kind of work their managers actually did, and the sneaky ways they made the process work for them. There's a lot more to scrum than a certification. Just the teams approach to sprint planning was in a whole different class from what mediocre teams normally did.
As for the other 99% of teams, they were mostly management tools. Scrum had been co-opted, especially in orgs using the SAFe framework. This has been at F250's in my experience btw.
But first principle, this is a physics issue: Whatever way a team comes up with to maximize the amount of work not done to deliver the same or better outcomes, I'm all for it.
I also often think of how our scrum process makes me feel like I’m back in grade school doing little busywork projects like coloring a hand-outline turkey or whatever. I really kind of think that’s the point. It’s for people who never escaped the schoolchild mindset. No doubt it works wonderfully well for them. It doesn’t work very well for me.
people who have to do the actual work don’t.
you should pay attention to that
You're supposed to have autonomous teams who put up their own tasks they want to complete in the sprint, and the sprint length can be more than 2 weeks if the team wants. And if it's tight to get the scrum's tasks done, that's supposed to be feedback to you and the team. You have autonomy in setting sprint goals, you can put less stuff on a sprint so you have the slack you're supposed to between sprints. Or spend more effort refining so you don't get surprises so often. (Or otherwise change things up in how you work)
If you don't have the autonomy and the continuous improvement in your work culture, it's not agile. Scrum is for agile and it doesn't work otherwise. If you do have autonomy you can switch to something else from scrum if you want.
Same goes for the "scrumfall" part of course but that's admitted in the text already.
(I do think scrum is overengineered for agile ideals, has failure modes like in the post, and in 95% of cases you should do something lighter than scrum)
Maybe having "easy" sprints would work?
There are benefits too, just that constant grind aspect is why I believe it's mostly a temporary endeavor. After 6-12 months most teams seem to just do something else then come back to it once a new manager joins.
If they all want to waste 2 hours a day, more power to them.
https://scrumguides.org/scrum-guide.html#daily-scrum
> The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
If what you are doing doesn't match that, then it's not a Scrum stand-up.
You must have stopped reading too soon.
"The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work."
US people tend to say that Dutch people are very blunt, but it feels like that should just be normal? If you do a bad job I'm not going to tell you that it was nice you tried so hard.
The OP may have some things wrong, but the 'constant grind' aspect of scrum sprints is spot on, there is no slack.
Add to that the 'radical transparency' aspect of scrum. That works great among a tight-knit team, but it can be insidious and actually self-defeating when certain types of manager get involved and weaponize it.
I'm sure there are many people who love programming, but hate being a programmer as a job, and to some extent that has always been true, but scrum seems in many cases to make it much, much worse, IMHO. The attitude displayed here is exactly the problem.
When a project is about non trivial projects, people, especially developers can not be easily replaced, because no one can replace a specialist with several years of experience on the spot. What I can archive in one day and what somebody else can archive on a day highly depends on what it is. Write a field to the database? Works. Write a rule engine? I'll probably be a factor of 10x more productive than an average developer. Write some GUI/CSS? A frontend developer is 10x more productive than me.
It definitely is human nature, and beyond that we're so trained to focus on goals and take them seriously that the "sprint goals" actually feel weaponized to me in order to get people to self-motivate/drive themselves. In the Scrum world engineers are fungible, so if one burns up or stops performing, you just replace them with a new one.
Also that "rough week at home" is going to show up on metrics for a very long time. A good manager understands the ebb and flow, but many do not. It also doesn't help that the Certified ScrumMaster® people will put so much emphasis on smoothness and consistency, and when it doesn't happen there's always someone/something to blame. When you remove the context (like team lead who knows what happened) and put it in a quarterly chart for upper management, you get a lot of bad and counter-productive conclusions.
Because it brought a kind of order to the game. Story points worked. They became boring so the teams started to twist them.
I think Scrum loses its advantage when people get bored - like with any other "process".