When not to use Scrum?
Tushar Jain
Transformational Servant Leader | Innovating at the Intersection of Tech, Strategy & Operations Driving Success by Effective & Performance Orientation | Passionate about Transforming Ideas into Company Success
When not use Scrum?
When to use Scrum?
What are the preconditions to use Scrum?
The answer to the first two questions is pretty straight forward. If the work you are executing belongs to the Complex domain of the Cynefin framework, Scrum is an appropriate choice. If work belongs to the Simple/Obvious domain, Scrum will be overkill. For work belonging to the Complicated domain Scrum might be ok but I will prefer to look for an alternative. Work belonging to the Chaotic domain needs to be brought into Complex or Complicated or Simple domain.
The answer to the third question is a little more nuanced. Before going into details of the answer, I want to introduce two new words:
- Sufficient-Condition
- Continuous-Condition
Sufficient-Conditions: The bare minimum set of conditions to adopt a process or start working under a methodology. It is possible sufficient-conditions may not allow adopting the process/methodology in full but good enough to start and moving toward its full implementation.
Sufficient-condition is not the same as pre-condition. Pre-condition does not bother about what happens after pre-conditions are met; sufficient condition is ok with partial adoption.
Continuous-Conditions: These conditions build up over sufficient-conditions and existing continuous conditions. With continuous execution of the process or working under adopted methodology, the quality of adopted process or methodology keeps on increasing as the environment presents the increasing number of opportunities and more and more conditions are met to adopt process/methodology.
As we have sorted out vocabulary, it’s time to list sufficient-conditions to adopt Scrum:
- The team should be willing to deliver in increments (Iterative approach is preferred over incremental)
- The team should be willing to stick to a time box (fixed time-box is an excellent start, variable time box is a slippery slope) for each increment. This time box should be under four weeks
- There is someone to play the role of Scrum Master (Full time is the best-case scenario, it is OK to start as an additional responsibility by one of the team member)
- Team has technical skills to create increment with acceptable quality
- Team has access to the tools, space, and allied resources to create an increment
Continuous-conditions build over sufficient-conditions and existing continuous-conditions. Some of the continuous-conditions are:
1. Dedicated Scrum Master
2. Scrum events (Sprint Planning, Daily Scrum, Sprint Review, and Retrospective) are observed regularly.
3. Fixed time box for the Sprint
4. Product Owner is engaged with the team
5. Continuous refinement of the Product Backlog
6. The relative sizing of work items
7. Well understood Definition of Done (DoD)
8. DoD reflects desired results from completed work items
9. Every member of DevTeam is full time in the team
10. Scrum Master is competent and has resources to tackle the impediments
In very simple terms, sufficient conditions are a good starting point to adopt Scrum with desire and will for continuous improvement. If desire and will for continuous improvement are lacking, opportunities presented to meet continuous-conditions will be lost.