Scrum Has Failed the Developers
medium.com
medium.com
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.
For now, let’s get back to Maker’s Time:
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.
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.
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.
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...
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.
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).