Inception - How Long?
Abhijeet Ghadling (ICP-ACC, CSPO, CSM, SAFe SPC5)
Agile Coaching & Product Management Expert
I see in a few new Product/Service development kick-off meetings, people tend to keep sufficient time to carry out Inception activities for successfully start Sprinting and achieve good velocity right from Sprint 1. Usually, stakeholders feel better to have safe Inception. They are ready to spend few weeks to few months for it. Some folks call it "SPRINT ZERO" too.
Few Inception activities for reference here -> Product Discovery and Backlog, Design Strategy, Environment strategy, Release strategy define..etc
Some aspects to think about keeping dedicated time for Inception –
- Can any team [not just Scrum team, but Program/Portfolio management team as well] finalize Inception activities in the dedicated time provided before Sprint start? Isn't it evolving throughout the development cycle? This is what ‘Inspect and Adapt’ as per Agile Philosophy, right?
- If we keep NO time for Inception and plan its activities right from Sprint 1 as ‘Analysis Tasks’ (/Spike stories) and get feedback on outcomes in demo events, isn't that add direct value to further development/decisions & indirect business value as well? Isn't it good to inform Inception progress to stakeholders and welcome feedback?
- Don't we delay the feedback cycle [which we get while Sprinting in 'Sprint Demo' event] by having dedicated time for Inception?
- Isn't it against fail-fast, fail-small and fail-safe philosophy we understand from Agile?
- Is it necessary to achieve optimum velocity right from Sprint 1? Why can't we spend the initial few sprints more on spikes [Analysis stories], than trying to achieve good velocity?
- Spikes eventually help to build a healthy backlog for the future, thereby increases velocity [in other words value delivery], true?
Please provide your inputs to evolve my thinking and approach…….
Agile Coach | Scrum Master | Product Manager | Delivery Manager | Program Mgr | Help Startups adapt Agile | New Agile Coaches / Scrum Masters contact for free sessions
5 年Abhijeet Ghadling?- You have brought in valid points and its food for thought.? In my opinion, it depends on the project and how old the Team is.? Sprint zero can be useful if the team is new.? In this case, access to server or some tool would be required prior to start of the Sprints.? Else, I do not see any value out such Sprint.? However, it should be for a short period of a week to identify and prep for forthcoming Sprints e.g creating and grooming backlog for the Sprint 1 & 2.
SVP-Platform, IIM Indore, Management Consultant, Product & Program Management, Business Transformation, Adjunct Faculty @ IIM L, IIM I, ICAgile Trainer
5 年This is classic case of doing fake agile ! If the focus is on velocity at the start of agile journey then the company has failed in its adoption of agile even before it started. Its sad but true. When you start agile journey using scrum, first few sprints are learning cycles, its evolutionary in nature. You should bear in mind that you will fail but that should be taken as learning experience than anything else. Fail fast to learn fast is the basic philosophy on which the success would depend. Starting with Sprint zero is the first sign that leadership simply has a long way to go.
Facilitator and Coach
5 年Abhijeet Ghadling, your points on evolving, fail fast, fail small, early feedback - they do make sense. When I read these statements - "stakeholders feel better to have safe Inception", "for successfully start Sprinting" and "achieve good velocity right from Sprint 1" - they tend to tell me that the stakeholders are not psychologically safe themselves, they do have need to showcase success (as opposed to being success or being okay to trying, failing and learning), they do have a need to prove velocity instead focusing on value (may be that they are measured on velocity) - these can be due to multiple reasons. I think its important to recognize this because it helps to understand people making decisions. This could very well be part of org culture. To me, it looks like classic situations when leadership has not quite adopted agile but they want teams to adopt agile.