Scrum/Sprint planning, Agile is beyond this?
Scrum framework in implementing Agile does not need introduction. Still if you are new to it link below ha good reference material: https://www.codemag.com/article/0805051/Introduction-to-Scrum
Scrum definitely provides structure to get started when we new team is getting formed. Rhythm of 2/3 weeks cycle to course correct directions are required. As team itself is going through various stages of forming, storming and norming, some kind of structure in execution is needed and scrum is a good framework for it.
As team gets into performing stage, business context, priorities are very clear, that is the stage I feel overhead associated with scrum framework or any other Agile implementation framework should be questioned. Being Agile not just in product/service development but in process also is need of the hour. Do we really need to stuck with Scrum for years? or keep re-evaluating a need for it after certain intervals.
In my career couple of times I questioned lots of scrum practices when team has reached the performing stage and here is my take on all the benefits which scrum provides.
- Planning: Plan for 2 weeks , fix the scope and execute it and cycle continues. After reaching a certain stage as a team we tried something different in past couple of months. Pick a goal analyse/plan the effort required to achieve the goal and then the team focus on achieving the goals. To me it became goal/business outcome driven development rather than sprint driven development. Lot of discussion about sprint planning/spillovers/Metrics were avoided and everyone was super clear for the goal. Business also knew the timeline to when the goal will be achieved.
- 2–3 weeks release cycle: One of the advantage people call out that sprint gives release rhythm, after every sprint we should have e something which can be released and ready for feedback. My question is why sprint cycle. Should we not be dividing the work at smallest possible chunk to get early feedback and that could be multiple times in a week as well or sometime once a month. Working with Scrum for more than years with great companies, I am yet to see release cycle attached to sprint cycle.
- Fixed scope: Another advantage which people call out is fixing scope for a team for next sprint. It again goes back to first point if we always make sure that team is working on first 2 priority goals for product that itself fixes the scope. If anyone changes that scope that means changing business priorities and there will be good reason behind it and benefit will be much higher which will require priority changes.
- Cadence for execution: Regular demos/retrospective are great way to get feedbacks on multiple aspect. Does that really needs to fixed to certain interval or should the cadence change based on the work team is doing currently. I think the later is better and more value add specially for demos. I still feel retros are anti patterns because if something anyone observes at first day of sprint why should he/she wait for last day of sprint to talk about. Should it not be raised and resolved earlier. A matured team will actually not wait for retros to solve issues.
- Speed & Quality: After team happiness which should be the top most priority, Quality feature delivery with faster speed is what makes money in any business. What I have observed whenever there is tight timelines people have always moved to Kanban and however tough the timelines were to achieve, quality is still at the top which no one is asked to compromise. When I have experienced this multiple times, I have really started questioning scrum framework for execution and specially sprint planning.
- Daily stand ups: When we removed so many scrum ceremonies for months. Using stand up effectively is the key to success. How to be short in status update and then identifying topics to be discussed after status update is also important. It has great benefit to start the day with stand up. For some reasons if that is not possible end the day with stand up. I have worked in both the ways. Also worked doing stand up in middle of the day but that was not very effective for teams rhythm.
I love Agile manifesto and as it says working software, interaction and collaboration comes over any process and tools. I feel all the frameworks coming which claims to be helping in following Agile are bringing more tools and processes to make it easy to work in Agile fashion. As true Agile follower we should question even those to check the effectiveness.
Today my inner developer voice just tell this.
As a developer let me design and code because that’s all what goes to customer. If your process can help me do that better and faster tell me otherwise don’t disturb take away my focus or slow me down.
This is my personal take on scrum framework after working with it for around 12 years. Just implementing Scrum does not mean organisation is Agile and other way around might be true.
