Why sprints are taking the joy out of building software
zaidesanton.substack.com
zaidesanton.substack.com
What we did then, and what we do now is what I will term "developer driven development". The developer picks up a task, often themselves, and works on it to completion. If there's a strict deadline, a PM might get involved, usually working directly with the dev(s) on the project. Other than that, the PM's job is largely just to watch over tickets.
I don't get the draw. We've had Agile and Kanban pushed on us before, and it's never stuck. We never got anything positive out of it. It only ever had negative effects on performance.
Is it just to help very poor communicators? People who can't be bothered to talk directly, so they need to waste everyone's time?
We don't do meetings. We don't need them. If someone needs a status update, they ask the person working on it directly.
Building software just isn't as difficult as these workflows try to pretend it is.
“Grooming” is just breaking down things from there. Sprint planning is a formality. Ten-fifteen minutes.
I guess my point is you’re right, the rituals aren’t important in a high context team. The work is really figuring out what you’re building. Like really really figuring it out.
100% agree.
You can change a design on the whiteboard rapidly and with practice you can really eliminate a lot of problems with a relatively small investment of time.
We just had one where a small group was stretching a bit in what they could take on, they ran into some issues and afterward commented "ok, I see what you're saying, we needed to work through that flow in more detail for a couple hours to avoid that week of pain".
The only rationale I can see for these frameworks is if you have a workforce that is entirely truly terrible workers.
It honestly takes a lot of trust AND discipline from the higher up folks to let dev teams work in the self organized, effectively ad hoc ways described in these other comments.
Me too (many decades), and we still manage things the same way I was taught when I started:
Pragmatic and flexible analysis of the project, and mapping out how best to approach this particular project or set of tasks. Projects are not all the same and different methods or approaches are required for different situations (e.g. whs with complex conveyor execution system+multiple app systems that can only go live in a big bang fashion, vs incremental improvements to ordering and order routing processes that can be chipped away at).
Generally it results in breaking it down into some major phases, (e.g. this qtr or year we tackle x,y and z, next qtr or year we tackle x', y' and z' and d,e and f).
Within a phase of work we talk about how to break it down, what needs to be designed up front, what can be handled as we go, which areas are we unfamiliar with and need to do some prototyping, etc.
Then we work, meet regularly, check progress, adjust our plan, adjust design where needed, decide when to divert some attention to going live and things like conversions/training/change mgmt, etc., lather, rinse, repeat.
The one time I felt the need to enforce Scrum was when I worked with a very chaotic Product Manager that wasn't able to organize any work ahead of time, so everything was an emergency and micromanagement and rushing ensued.
What’s the most impactful task for the business right now? What’s the feedback from the sales team? What tickets are coming into customer support? What are our competitors doing? What do the marketing team need? You’re across all this? What about the other 250 developers in the business?
At some point it doesn’t scale. So maybe you need someone further up the pipeline identifying opportunities and looking at risks, talking to customers and aggregating the data so that we can be focused on the most important thing.
Maybe you’ve only worked in very small companies over those 20 years but it’s a naive take on things.
I usually just maintain a priority list and work on (or assign) whatever is #1 priority. It’s simple. It works.
It means I never say no. I just negotiate where to put it in the priority list. It’s a great way for people to realise the trade offs of what they are proposing.
The structure it provides in organizing the discovery, design, development, and delivery process made for a very predictable cadence and enough focused time to feel like a dev team wasn't sacrificing (be it work life balance or code quality).
It absolutely works and creates space to do meaningful work, learn, and experiment.
Plenty of us saw it coming ...
I just don't understand the point of boxing yourself into a set of work for X weeks when you could just use Kanban and pick up/put down work when needed.
"The weekend. Sometimes."
1. A work week is 5 days.
2. A work month is 20 days.
3. These are the numbers you plan within.
4. If you work outside those limits that is a process failure.
5. Process failures in an iterative process lead to incorrect/bad feedback into subsequent planning/estimation, baked in over-optimism, burnout, and ultimately failure to deliver a product on time.
6. Don't work weekends.
Doing otherwise and deliberately running your staff hot and into personal time seems pretty damn in violation of the spirit of:
"Individuals and interactions over processes and tools"
Without the pressure to make your stupid charts look pretty it’s just a two week planning cycle, and that’s fine.