How to deal with weird development cycles?
I work on a pretty planning intensive team. Sometimes we'll spend several weeks planning out our next project, but since planning takes so long, not much time is left for execution after we're done planning. This leads to us having to sprint to deliver, and after we go that, we go back to planning and the cycle starts all over again. This is all pretty hectic, so I was wondering if anybody had any ideas on how to improve this process?
Discussion
(2 comments)- 2
3 years agoStaff Software Engineer @ DoorDash, ex-FB, ex-KlaviyoWithout too much context, I think you can do a few things to start with
- understand why the planning is so long?
- too many dependencies?
- lack of domain experts?
- hard to size?
- hard to get alignment?
- Plan for longer? there are times it takes long time to plan out a long term roadmap. From sprints to sprint, you really should not re-plan lots of milestones.
- are there lots of disruptions where your requirements to deliver changes?
- then that's a different set of problems to address.
- understand why the planning is so long?
- 13 years agoMeta, Pinterest, Kosei
Are others on the team also aware (and acknowledging) that this is a problem? I wonder if you could document several examples (in a non-confrontational written doc) which clearly shows the compressed time for actual execution based on your current planning cycle.
I imagine the main people responsible for the current setup are your manager and some sort of TPM or PM. Can you explain the benefit of having a more regimented planning timeline? It sounds like the issue now is that the planning consistently takes longer than expected, and you can brainstorm how to improve that:
- assign a DRI to make the decision
- move synchronous debates to be async to make them faster
- gather more of the project requirements earlier, so planning is not as taxing
Another thought is to ask why the planning/execution phases have to be so distinct? It feels like an anti-pattern to me to only do planning for weeks, and then execution for a few weeks. (I imagine it's not actually that extreme due to things like on-call and ad-hoc requests). Could you have some longer-running (perhaps lower priority) projects that cut across sprints? Then you have an outlet (pressure release valve) when things become stressful.
Other Great Discussions
![Entry-Level Software Engineer [L3] at Google company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fgoogle.jpeg%3Falt%3Dmedia%26token%3D780356ef-3efc-4728-9eb4-d909b75bb4a6&w=96&q=75){kind=small}
