I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement.
Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance.
I’m not sure what planet the OP is from, but this will never change. If you have a small team with a simple codebase, kanban is probably sufficient. In larger teams or complex solutions, the reporting just needs to happen.
The post is fundamentally about all the performance of making stories, assigning points, allocating work and doing standups all the time. None of that is required to actually create software.
If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
>> None of that is required to actually create software.
Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.)
>> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress, the existence of "intractable problems", work going unfinished creates significant stress up the ladder.
In a perfect world the dev team is given a perfect spec, and a reasonable time to do it in, and after being "left alone" they deliver the finished product on time.
Given that that world doesn't exist, given that the "money we're spending" may turn out to be completely wasted (because the spec was wrong, or because the problem us much harder than anticipated), the ideal case seems unlikely to happen.
I say this not as a defense of crappy management processes, or even less as a defense of crappy managers, but rather in the spirit that understanding the problem goes a long way to solving it.
And yes, many places have bad processes and bad middle managers. I don't envy you that. But finding a way to better solve the manager's problem typically improves the relationship.
I think ones that are against scrum are loud about it on the internet.
When it comes to have their salary paid out they will not speak up for themselves to push back against shitty management.
Like accepting ever increasing velocity until they burn out or accepting bad requirements because business is sayin “it needs to be done now” and working blind only to be scolded they did bad but requirements were bad in the first place.
> Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
The stress at the bottom is there by design. If you start meeting the deadlines too reliably, the higher-ups will probably conclude that there are needlessly many people in the team, and will try to remove one and see what happens. Repeat until things start cracking apart.
In one of my previous jobs, I worked on a software project that frequently got the following two kinds of comments from the managers:
"Wow, this is the only project in our company that works reliably. There are no major bugs ever; and all the small bugs are fixed within a day or two. I wish other projects worked like that."
"You have five developers working on one project? Isn't that too much?"
Seemingly none of them was able to connect the dots and conclude that maaaaaybe these two things are somehow related. That maybe the fact that we are not understaffed somehow allows us to write automated tests, refactor when necessary, etc., so we can keep adding new features as required and the project keeps working ok.
So they started removing the developers one by one, moving them to other projects. The last guy left on the project felt overloaded and quit.
The project still worked okay for a few years without new updates, and was gradually replaced by several new projects (because it had a lot of functionality). But the new projects only had two developers each on average, so at least the managers didn't feel like they were wasting money.
Hmm, while I get what you are saying, I feel like dealing with that is _literally_ their job.
It'd be nice if we could remove stress from leadership, but I don't think that's a thing that should be my responsibility as a dev. Of course it'd actually improve the life of everyone if did, so it feel like something you should do regardless.
But then I'm taking the managers job in addition to being the developer, and then what's the point of the manager in the first place?
> Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
Good luck with that because higher-ups have even-higher-ups until you reach the top. The bigger the pay packet, the more inflated the lifestyle and the associated stress of missing on the ever ballooning target. It is self-inflicted and never-ending; sacrifices of the lowly soldier will never quench that thirst.
Scrum/Agile is basically an answer for things that went wrong in the past. Building software has a long history of delays, running over time, running out of budgets, etc. As a stakeholder/customer, you need certainties up front: how long is it going to take, what is it going to cost? And if you think this isn't reasonable, just consider, would you hire a contractor to work on your house that can't tell you up front cost and duration?
Anybody doing work needs to be able to estimate duration, progress, risk of delays, etc. Other people's work depends on your deadlines. Go/no go of a project depends on cost and duration.
Insight and tracking is required. None of this was done any better before agile.
What is required is frank conversation with the stakeholder/customer, because there are so many trade offs decision to make. Devs don’t like to estimate tasks because there’s an exploration phase (which cost time an energy) to have the solution and the cost of time and energy for the implementation. And it’s recursive. Agile was basically saying, let the devs do their thing, but have a conversation every once in a while to discuss new directions to the projects based on new evidence found. And unless the team have already built the same project (with the same people involved), it will always be a bet. No amount of tracking or insight will remedy that.
Agile recognizes that software development is a design process with uncertainties and not a repeated tested manufacturing process (product development versus product manufacturing). With the uncertainty of a design process in mind, and the need for estimates, it suggests comparing similar tasks to get an empirical estimate. But since it's just an estimate, you regularly need to validate that the estimate is still considered correct.
Assigning Points = Roughly estimating how long it takes you to implement it
Allocating Work = Well... allocating work
Standups = Talking with your colleagues about the current work and clearing problems
Reviews = Showing your results
None of that seems unreasonable. The only thing that kinda sucks are the rigid sprints, because they just cause artificial stress by setting unnecessary deadlines.
They’re not unreasonable in themselves. What sucks is the process around them, because it impedes progress. Why because each tasks varies, and often it morphs while you’re working on it. So whenever a metric is fixed or something interrupts you repeatedly, it just sucks.
Or worse than impeding progress, everyone adjusts their expectations to only that which can comfortably fit into a sprint. Big gnarly bugs, meaty technical problems, or innovative solutions - too risky. Better just take a few random tickets off the board and keep plodding along.
The direct effect is organizations start systematically ignoring the forest and start obsessing over the trees, simply because trees are easier to measure. And then inevitably wondering aloud "why is velocity AND quality tanking?". Anyone with half a brain can see why - disincentivizing innovation destroys innovation.
I don't feel anything you've said is logical. The deliverable is, in the best case, what communicates progress and success. Short of that, tickets can do that, which is also not what the article is complaining about. The article also specifically attacks Agile/Scrum; Kanban is different and quite explicitly sidesteps a lot of the stress problems the article outlines.
> Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In the agile teams I've been on it's been to produce success. Getting good and useful software fast.
Of course, just like there are hundreds of wildly different Christian sub-religions, there are now any number of "agile" interpretations. In the end belief systems can be pushed to do most anything you want.
Yeah, I totally agree in theory, it doesn't really matter what methodology you use, at the end of the day dev management is just a means to an end.
The real issue comes from middle management folks who conjure up buzzwords whenever they need to justify whatever they think the team should do. Don't know how to structure tasks but want to look like you're in control to the boss's boss? Just throw up a Kanban board with tiny tickets and a burndown chart trending down. Sprinkle in some Agile keywords in the management reports and call it a day. And let's not forget that by 'sprint' they often mean moving unfinished tickets from the last iteration to the current one, plus tacking on surprise urgent tasks that were not planned before because the product owner never shows up to share their vision and priorities.
Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance.
I’m not sure what planet the OP is from, but this will never change. If you have a small team with a simple codebase, kanban is probably sufficient. In larger teams or complex solutions, the reporting just needs to happen.