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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.”
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.
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.
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.”
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.
> 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.
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.
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".
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
"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.
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.
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.
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.
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.
> 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?
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.
> 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)
> 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.
> 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.
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.
> 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.
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.
>scrum elevates them from total failure to unproductive but fumbling in a good direction.
Where's the evidence for this? I kind of agree on big corporate not being able to achieve great development speed. But they had a system before scrum, and I've yet to see scrum not completely destroying every metric of development achievement, whether it's throughput, latency or iteration speed.
The evidence is in the company choosing scrum then sticking with it. They believe it helped.
> I've yet to see scrum not completely destroying every metric of development achievement, whether it's throughput, latency or iteration speed.
It is too hard to argue from vague anecdotes, so I am resisting the urge to try. However, I will say that if that is a demonstrable thing and there was no upside then it would be surprising that scrum sticks as well as it does.
>scrum then sticking with it. They believe it helped.
Not necessarily. It's well known that there are many psychological biases in favor of keeping the status quo. Whether it's the sunk cost fallacy, the escalation of commitment or the endowment effect.
Humans tend to stick with bad decisions way longer than rational.
I think the problem here is we've had a huge trend in switching to scrum, but then people stick with failed scrum because it's the new status quo. Switching back to waterfall can't be sold by consultants. Even if it would help.
I'd go on a sarcastic rant here, but it's hard to stop myself. Don't read further if exaggerations upset you.
Sure, there are upsides, but they are hardly benefitting software engineering speed, quality, stability and developer happiness. The biggest upsides are for management:
- keeping the engineers under tight control by one of their business types (PO)
- making sure long-term thinking (like "what am I doing in this company") is suppressed by having a horizon of only 2 weeks in which you are supposed to give all you have to hit an arbitrary deadline. And then you start again! /s
- scrum has the beautiful effect of making engineers feeling either like kindergartners:
1. what did you do yesterday, Timmy? (standup)
2. Let's play with some cards, kids (planning poker)
3. Let's review what we learned last two weeks, children, and let's see what progress you made on your bean drawings (retros and demos)
How can you want a salary increase or question big man POs decisions, when you've just been acting like a kid for the last two weeks? Don't get me wrong, I do see the benefit of retros, demos, and some kind of planning and sync, but the way scrum just dumps it on you and prescribes you how to do it is just humiliating. Adults can sync, plan, retrospect and demonstrate what they did on their own volition and don't need some framework to tell them when and how, and two parental figures (the PO and Scrum master) to tell them what to do and when.
> The evidence is in the company choosing scrum then sticking with it. They believe it helped.
Many people also believe the Earth is flat and are sticking with that belief.
We absolutely learned something since the 90s that was beneficial. Corporative software projects now have about a two times higher chance of success than they had back then.
Also, we almost certainly learned that thing from Agile. There is no other credible source.
But the article has a clear point that places where people say they are practicing Agile has an even lower success rate than the overall one from the 90s. So it seems that the actual lesson from the Agile manifest was only learned by the people who don't claim to practice it.
> We absolutely learned something since the 90s that was beneficial.
Yes, software engineering has evolved, but to attribute its successes to the methodology used is like attributing higher cancer survival rates to better hospital management. In reality, it's due to the availability of better drugs, more understanding, and a lot of R&D, and it has 0 to do with management. Same with software engineering: we use better tooling, libraries, hardware is more commodified, and a lot of things we don't have to do ourselves. All things that have nothing to do with the methodology.
> So it seems that the actual lesson from the Agile manifest was only learned by the people who don't claim to practice it.
No methodology/manifest and no amount of management can compete with smart, qualified adult people being invested in their craft, and having autonomy and ownership on what they are building. The projects that succeeded are projects having those people, regardless of the methodology. In a way, people succeeded despite Agile, not because of it.
Could it possible be that.... you're not doing it right. lol
It is another great point. But it is another great point about how the process in your organization could be improved. Nothing says you have to have two parental figures.
And why on earth would you have a dedicated scrum master?! It's just not a job that should be requiring that much labor. Just have one part-time scrum master in the entire company who periodically audits and coaches teams who aren't doing the process right. Or coaches teams through the initial learning curve, as required.
In scrum and non-scrum processes that I have worked with, the PO comes from the marketing/sales team. On the theory that, if anyone has the pulse of what customers in aggregate actually want, it's going to be them. Also a part time job. But essential for injecting some realistic sense of "value" into the development planning equation. The direct contribution of a good PO is to make sure that the team is contributing work output to features that customers actually want. A good PO contributes enormously to team productivity.
Compared to what, exactly? I can't imagine you could say anything like that if you had experience with any of the heavy development processes that preceded scrum/agile methodologies.
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 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 :)
> 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.
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.
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.
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.
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.
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...?
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.
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.
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 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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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?
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.
- 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!
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.
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...
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.
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.
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.
If you are a manager and this makes you angry, you're one of the bad ones.