“Scrum (and Agile as a whole) promised to liberate the developers”
No it didn’t. It was a process formalized by people who needed extra structure. It gave the priesthood the ability to run in place a little faster, accomplishing no more work than before. I anxiously await the next Silver Bullet.
I think scrum is best understood as a push back of waterfall.
Breaking large parts of work into small chunks, where it makes sense, which are testable and negotiable is better than the massive brittle project designs that collapsed under their own weight, with nothing to show for it.
Of course, not everything can be done in small chunks. But a lot can be.
Waterfall is a constructed counter example. Nobody out side of safety sensitive fields like aerospace or the military ever used it and there it is only used because the requirements force it upon the developers. What good can a paradigm do, which basic starting approach is to define itself as counter move to a strawman.
UK government projects suffered significantly from Waterfall planning, with nothing to show for it at the end.
This lead to the Government Digital Service who cite the failings of Waterfall.
> Using waterfall methods means you may spend 18 months building a service that no longer meets government policy, cannot work with the latest technology and does not meet users' needs.
This. I've been programming professionally for decades before Agile-like stuff was around, and I've never seen the process they describe as "waterfall". I think it's entirely made up.
Scrum has it's place in project management but not at the code writing level. There ere just too many unknows to be able to deliver good code on a set time schedule.
It's way more important to have competent project managers that know coding and developers that are motivated to deliver on time in a team environment.
>here ere just too many unknows to be able to deliver good code on a set time schedule.
So let's not try? No estimates at all then? I'm not sure how you how can include the role of project manager in the same post when saying estimates don't work at all. By definition one of a PM's core duties is to estimate the time, cost, quality of a project.
The main role of agile is not to deliver super accurate estimates anyways, but to make everyone involved in the project aware of what work needs to be done and then make sensible decisions around this. Seen this way, I think it works well. There are ways to know how much can be done in a sprint.
Barely anyone applies it that way. It is just authoritarianism with a different coat of paint, at least in my 20 years long career it inevitably always was.
There are no problems with giving estimates. The problems start when managers first say "don't worry if it's not accurate, just give me an estimate" and the next week say "it's not okay to give a wrong estimate".
It's no use, man. I communicated with quite a few of them. They don't do anything and just panic when their manager gets unhappy and start putting pressure on their team. That's it. That's all. There's rarely any other process going on.
I recently did work for two organizations that weren't that stupid and allowed leeway and had flatter structure. I liked them but they were prone to succumb to the council of elders trope where a few seniors basically decided everything and stopped listening to arguments.
I'm not saying that we shouldn't try. I'm saying we should also read some history and ask people who have been through it as well. And everyone and their dog are convinced that them and only them know the secret sauce that will finally solve management (lol). Human ego is fascinating, isn't it?
I do the PM role alot and sometimes the engineering manager role too and I do empathize with you, especially with regards to estimations. I've been on alot of projects where clients start with "it's ok if the estimates aren't accurate", and then the team gets nailed two weeks later at the end of the sprint when one or two tickets won't make it.
Still I think the exact purpose of a good project manager is to manage the other stake holders / clients / council of elders and let the engineers do their engineering to avoid this situation. This applies to the initial startup and estimation phase as well. It's all about setting expectations...
Yep, agreed with you here. A lot of the more responsible roles should do management of expectations and sadly that's lost on many and isn't being done nearly enough.
Yes, there needs be to a deadline since ultimately the work needs to be delivered. But scrum long term burns out the developers. It's pushing people for short term rewards.
It all comes down to the PM understanding the team and knowing when to push and to understand when not to. Being a good PM is hard. Also, the team needs to work well together and be willing to deliver on time.
I dont like scrum but I did like that it did manage to convince managers I worked for circa 2009ish to do away with arbitrary deadlines (which were common until that point).
Waterfall could only induce death march mode when deadlines loomed. With two-week "sprints" and management that expects the product of every sprint should be an improved deliverable (whether it's actually delivered or not is beside the point), you get the deadline effect every other week. Soon it just blurs into never ending death march.
2 weeks is too small deadline to implement something meaningful and/or non-trivial.
Many modern SDLCs and informal methods used by FAANG are using 6 weeks cycles.
Two 6 week cycles can fit to a single quarter (~ 13 weeks). Also works better with quarterly OKRs/KPIs, and with Amazon PR/FAQ. The latter I think for semiannual (2 quarters).
The best is to have no project management. Just a stream of ideas and high trust to prioritise effectively in an autonomous way. This only works when you have full alignment and everyone is competent at managing their own time and expectations.
Invariably someone will get flustered with this approach because they need visibility or believe things to be unaligned and hamfist scrum into the process. They usually do this with Jira and then claim there’s no better software. So we have two bits of pain for the price of one.
I really believe that we have a real lack of competence in project management in general; estimations are hard for sure, but reaching for tools without understanding trade offs is the kind of thing mid-level engineers do; seniors usually being marked by not adapting to tools but making tools work for their ends.
This is all a digression and what I originally wanted to say was that IME; scrum is the cart leading the horse.
Agile is also a difficult fit for something brand new; as how can you get user stories properly told without having users? but I think it’s quite good for refining something existing.
I agree that Jira is not the best project management tool, but it wasn't really designed to be one. It's not terrible a work tracking, but it seems to lacking in the roadmap/pre-planning departments that project/product should be using to feed developers work.
That said, spreadsheets are also not great project management tools either, quickly becoming messy and out of date. Nor do I think relying on senior devs to roll their own project management tools is a good idea.
I'd like to see more WBS(work breakdown structure) tools used to identify needs in advance and ways to monitor their implementation, testing & deployment. The industry's love affair with agile seems to lead to pre-planning & consistent structure being seen as "too waterfall". Basically it feels like no one does agile "correctly", and those that it's worked well for, likely have a workflow and product cycle that aligns with it well, but that may not be true for all products, tech, stacks, etc.
Ultimately we're trying to answer these basic questions: What are we doing? Why are we doing it? How are we doing it? When will it be done? Is it actually done? If those questions cannot be answered easily there are probably gaps in your workflow.
What do you do if you work in an organization that is set up with scrum managers whose sole job it is is to run through tickets + follow up?
"Hey developer, how is the progress on that ticket coming? Any blockers? When do you estimate it will be done? How many story points should it be? Should we pull it into the next sprint? Don't merge any code into the release branch for that ticket until we start the next sprint. Let's have a daily standup meeting, then let's have a weekly planning meeting for the next sprint." The scrum manager reports to the manager manager who reports to the director/VP who wants to see progress through releases/tickets, etc. etc.
Like... how many HackerNews readers live this every day versus how many will say "if that was my 9am-5pm, I'd quit because it's a sign of ________ in an organization/corporation/team and I wouldn't stand for that. I only work for teams that let me do whatever I want with 0 observability into progress/ticket tracking".
I mean, if you’re at that point then you’ve already failed the scenario I described.
A scrum master is a symptom of lack of trust personified into a role.
I’m sure some are servant leaders that seek to unblock, unify or enhance development; but that would be the exception. The causes for them being employed to begin with are likely lack of visibility or lack of trust in the ability of the team to understand what is a high priority.
Exactly ... agile fails on any project which requires pure research or exploratory hard problems which are above and beyond just grunt work ... Agile shops typically assume the work is predictable and just a function of redoing a known recipe
If Scrum is failing developers in your environment, then it is being implemented wrong. Fundamentally it should give more control to developers, break down large tasks into smaller tasks, and help management determine better what projects/tasks to direct resources to.
I don't know anyone that likes scrum. If everyone hates scrum because its "being implemented wrong", then wouldn't it follow that scrum is fundamentally broken in some way?
Scrum's formal, recurring decision meetings allows executives to retain the role of decision maker while avoiding participation in the daily rhythms of creation. Of all of the currents in the agile wave, Scrum was the one with the most formal process, and the one that most prioritized the needs of external stakeholders. It might be the best that you can do in organizations that will never delegate actual authority down to the team, but it doesn't make it pretty, or effective.
This is a pretty good article IMO; it pegs exactly why Scrum failed: the company has to change and not crunch developers. It requires a change in power structures, and it's pretty rare for a software delivery methodology to cause that.
I wonder how much successful software is developed with Agile/Scrum. Safari? OpenJDK?
My line of inquiry here is: what is Agile/Scrum about? Is it software Marxism (the workers seizing the means of production)? Is it process (mass production)? Is it software Protestantism (waterfall is Catholicism)? Is it vague unfalsifiable snake oil? Are other similar things (microservices, hexagonal architecture, DDD, functional programming, OOP) in this group?
I honestly don't know, and I welcome a serious discussion about it.
30+ years of development experience here. The #1 management tool that really works is a simple prioritised list. Whether you are managing a team or yourself. Tasks gets assigned in priority order and if a task is blocked then you pause and pick the next one on the list. The prioritised list is also excellent for negotiating with stake holders. Simply ask them to place what they want in the priority list. It makes it really obvious to the stakeholders what the trade offs are.
No Kanban is more involved. You can have multiple tasks in flight, you limit tasks per column etc. Kanban is IMHO for more complicated stuff (large scale manufacturing with multiple departments for example).
I doubt that Scrum is about helping developers or whatever this post is trying to imply. It's a very mechanical framework with rigid rules and meetings. It's very fragile and breaks apart as soon as you try to change something.
One place where it actually makes sense is when trying to move away from a chaos into a more structured process. This is where Scrum is useful, because it comes with rules to introduce this structure. But it never failed developers, that target group is business people, promising to deliver more in a shorter time via rigid time-boxing.
33 comments
[ 2.7 ms ] story [ 76.0 ms ] threadNo it didn’t. It was a process formalized by people who needed extra structure. It gave the priesthood the ability to run in place a little faster, accomplishing no more work than before. I anxiously await the next Silver Bullet.
For now, let’s get back to Maker’s Time:
http://www.paulgraham.com/makersschedule.html
Breaking large parts of work into small chunks, where it makes sense, which are testable and negotiable is better than the massive brittle project designs that collapsed under their own weight, with nothing to show for it.
Of course, not everything can be done in small chunks. But a lot can be.
Sounded very normalized here: https://youtu.be/hxXmTnb3mFU?list=PLakykuPxo3ch60vi4JeOieW4P...
This lead to the Government Digital Service who cite the failings of Waterfall.
> Using waterfall methods means you may spend 18 months building a service that no longer meets government policy, cannot work with the latest technology and does not meet users' needs.
https://www.gov.uk/service-manual/agile-delivery/agile-gover...
It's way more important to have competent project managers that know coding and developers that are motivated to deliver on time in a team environment.
Scrum and any other tool will not fix that.
So let's not try? No estimates at all then? I'm not sure how you how can include the role of project manager in the same post when saying estimates don't work at all. By definition one of a PM's core duties is to estimate the time, cost, quality of a project.
The main role of agile is not to deliver super accurate estimates anyways, but to make everyone involved in the project aware of what work needs to be done and then make sensible decisions around this. Seen this way, I think it works well. There are ways to know how much can be done in a sprint.
There are no problems with giving estimates. The problems start when managers first say "don't worry if it's not accurate, just give me an estimate" and the next week say "it's not okay to give a wrong estimate".
It's no use, man. I communicated with quite a few of them. They don't do anything and just panic when their manager gets unhappy and start putting pressure on their team. That's it. That's all. There's rarely any other process going on.
I recently did work for two organizations that weren't that stupid and allowed leeway and had flatter structure. I liked them but they were prone to succumb to the council of elders trope where a few seniors basically decided everything and stopped listening to arguments.
I'm not saying that we shouldn't try. I'm saying we should also read some history and ask people who have been through it as well. And everyone and their dog are convinced that them and only them know the secret sauce that will finally solve management (lol). Human ego is fascinating, isn't it?
Still I think the exact purpose of a good project manager is to manage the other stake holders / clients / council of elders and let the engineers do their engineering to avoid this situation. This applies to the initial startup and estimation phase as well. It's all about setting expectations...
It all comes down to the PM understanding the team and knowing when to push and to understand when not to. Being a good PM is hard. Also, the team needs to work well together and be willing to deliver on time.
Many modern SDLCs and informal methods used by FAANG are using 6 weeks cycles.
Two 6 week cycles can fit to a single quarter (~ 13 weeks). Also works better with quarterly OKRs/KPIs, and with Amazon PR/FAQ. The latter I think for semiannual (2 quarters).
The best is to have no project management. Just a stream of ideas and high trust to prioritise effectively in an autonomous way. This only works when you have full alignment and everyone is competent at managing their own time and expectations.
Invariably someone will get flustered with this approach because they need visibility or believe things to be unaligned and hamfist scrum into the process. They usually do this with Jira and then claim there’s no better software. So we have two bits of pain for the price of one.
I really believe that we have a real lack of competence in project management in general; estimations are hard for sure, but reaching for tools without understanding trade offs is the kind of thing mid-level engineers do; seniors usually being marked by not adapting to tools but making tools work for their ends.
This is all a digression and what I originally wanted to say was that IME; scrum is the cart leading the horse.
Agile is also a difficult fit for something brand new; as how can you get user stories properly told without having users? but I think it’s quite good for refining something existing.
That said, spreadsheets are also not great project management tools either, quickly becoming messy and out of date. Nor do I think relying on senior devs to roll their own project management tools is a good idea.
I'd like to see more WBS(work breakdown structure) tools used to identify needs in advance and ways to monitor their implementation, testing & deployment. The industry's love affair with agile seems to lead to pre-planning & consistent structure being seen as "too waterfall". Basically it feels like no one does agile "correctly", and those that it's worked well for, likely have a workflow and product cycle that aligns with it well, but that may not be true for all products, tech, stacks, etc.
Ultimately we're trying to answer these basic questions: What are we doing? Why are we doing it? How are we doing it? When will it be done? Is it actually done? If those questions cannot be answered easily there are probably gaps in your workflow.
What do you do if you work in an organization that is set up with scrum managers whose sole job it is is to run through tickets + follow up?
"Hey developer, how is the progress on that ticket coming? Any blockers? When do you estimate it will be done? How many story points should it be? Should we pull it into the next sprint? Don't merge any code into the release branch for that ticket until we start the next sprint. Let's have a daily standup meeting, then let's have a weekly planning meeting for the next sprint." The scrum manager reports to the manager manager who reports to the director/VP who wants to see progress through releases/tickets, etc. etc.
Like... how many HackerNews readers live this every day versus how many will say "if that was my 9am-5pm, I'd quit because it's a sign of ________ in an organization/corporation/team and I wouldn't stand for that. I only work for teams that let me do whatever I want with 0 observability into progress/ticket tracking".
A scrum master is a symptom of lack of trust personified into a role.
I’m sure some are servant leaders that seek to unblock, unify or enhance development; but that would be the exception. The causes for them being employed to begin with are likely lack of visibility or lack of trust in the ability of the team to understand what is a high priority.
I wonder how much successful software is developed with Agile/Scrum. Safari? OpenJDK?
My line of inquiry here is: what is Agile/Scrum about? Is it software Marxism (the workers seizing the means of production)? Is it process (mass production)? Is it software Protestantism (waterfall is Catholicism)? Is it vague unfalsifiable snake oil? Are other similar things (microservices, hexagonal architecture, DDD, functional programming, OOP) in this group?
I honestly don't know, and I welcome a serious discussion about it.