My goal for this site is to share my personal and professional experiences to prospective...
Scrum isn't just for software development, nor is it a solution to all problems. So, when is it appropriate to implement Scrum and when is it not?
The Cynefin Framework categorizes problems into four categories. Many of the problems in project-based work live in the Complex category, and that is where Scrum is effective.
I was in an organization once that didn't have a process for ordered work. Simple and repeatable tasks were put in the backlog for a future date. While they could be resolved quickly and had a greater impact on the business the longer it took to solve the problem, there was no room for adding work into a sprint.
Scrum isn't for all problems. There needs to be space for ordered, simple, and complicated problem-solving. On the other side, Scrum isn't for chaotic problems either. Chaotic problems are for leadership to respond to as novel situations that need managing. If your biggest client is threatening to leave, you aren't going to deal with it in a few weeks when there is space in a sprint.
Simple Problems
What are some examples of simple problems?
- A process or solution has already been developed to solve the problem. For example, a person cannot log in to their computer and needs a password reset.
- A decision needs to be made about the next steps. For example, the office is buying lunch for the team and needs to know if they should order pizza or tacos.
- A data update is needed that has been performed in the past and the SQL is already written. The impact of the update is low.
These decisions shouldn't require meetings and backlogs to get the work done. People should be in place to make the decisions and perform the actions needed. Tickets may need to be submitted to track and complete the work in an appropriate order, but we don't want to delay important but simple problems from being solved.
Complicated Problems
This is where problems might not have a documented answer to follow or have a simple decision to make, but still doesn't require a framework for solving. The cause and effect is clear and while some discussion may be needed, actions can be taken to resolve the problem.
What are some examples of complicated problems?
- Bad data entered the system. We know how it happened and the root cause has been solved. An expert is needed to fix the data, but no system changes are required.
- A client would like to use the system in a way that it hasn't been used before, but has been built to handle. An expert may be needed to review, set up, and test.
Complex Problems
A complicated problem becomes a complex problem when the cause and effect isn't clear or the solution isn't readily available. When research is needed to find out how the problem came to be, what the impact is, how the problem gets solved, we enter the complex territory. When software needs code changes, a new solution needs to be implemented, or a process needs to change, a framework will organize and schedule the work. Complex problems are likely to get stalled due to the involvement needed to find the right solution or the need to break the work down into pieces.
Chaotic Problems
These problems are novel and unique. It's your most important client leaving, a valuable employee resigning, or losing the lease on your building. These problems don't belong in sprints or a backlog, because they need immediate attention and/or high level management.
The video below dives deeper into The Cynefin Framework and how it can be used. When considering the most effective plan for every issue, this is a great breakdown of handling different types of work with separate processes and frameworks.