A few months ago, I took the 2-day Certified Scrum Master course through KnowledgeHut and sat for the CSM exam. I had an interest in doing the course for the past few years because I wanted to improve my understanding of the agile process. Across the different jobs I’ve had as a Software Engineer, I have typically been on small teams where we don’t have a Scrum Master or a designated person to coordinate the agile process. I’ve been on teams where we try to follow the “classic” scrum process stringently, and I’ve been on others where our process very loosely resembles scrum. Having seen an array of implementations, I went into the course hoping to learn more about defining and following an effective agile practice, and the course did not disappoint.
The Types of Problems Scrum Solves
One of the first thing we talked about in the course that I found interesting was the concept of mechanical vs organic problems. A mechanical problem is something that can be broken down into its smallest parts and figured out. Mechanical problems are predictable and there are a fixed number of components that go into them. Organic problems are nondeterministic and often times we lack the ability to determine cause and effect with them. An example of an organic problem is determining how a drug treatment will effect a patient.
With that in mind, we started to talk about the different types of problems that exist. In its most basic form, you have simple problems, which are mechanical problems that we can easily decompose and solve. When simple problems get more difficult, they become complicated problems. When something is in the complicated problem space, it usually requires someone in a highly skilled job, who understands the components in order to solve it. A methodical, reductionist approach is often helpful to break the complicated problem apart into manageable pieces. After complicated, we move to complex problems, which enter the organic problem space. These require a holistic approach where all the moving parts are taken into consideration. These kinds of problems require an expert to be adaptive and empirical. A good example of a complex problem is tackling climate change. Beyond complex problems, we have chaotic problems, where things are moving so fast and unpredictably you’re just trying to get a handle on it the best you can.
This spectrum of problem types is explained by the Stacey Matrix. The Stacey Matrix is a graph where the x-axis represents the how to solve it part problem, and the y-axis represents the what we are solving piece of the problem. The further away from the origin, the more uncertain both of those aspects become. This relates to scrum because scrum is designed to tackle the complex problem space with an iterative and adaptive approach. It also aims to keep us out of the chaotic problem space by providing a framework that we can follow to achieve our goals.
The New Mentality and Goals of a Good Scrum
Our instructor, Jem Jelly, talked about how the “old” product management mentality was to deliver everything that was promised on time and on budget at all costs. This often means flexing on quality, attempting to add more time or people, taking shortcuts and working people overtime. This is not sustainable, and it takes the integrity out of the process for the product and the employees. In agile, you don’t throw more people at the problem or allow the quality to take a hit, you simply change the scope.
The focus of the sprint is to protect the sprint goal. The sprint goal is a goal that is defined for the team at the beginning of the sprint that is meant to unite, inspire, and focus the work for the sprint. Jem gave a great, high level example of a sprint goal. He said “find me something French, sweet and delicious”. This could be a croissant, a danish, a scone, etc., it’s completely open-ended what the shape of the finished product is as long as it meets the requirements. He doesn’t dictate where to go to get it or how. This is how the sprint goal should be. The team cannot organize without a clear shared goal, but the goal is meant to inspire and leave room for innovation and creativity.
A successful scrum should have intrinsic motivators. People are motivated by knowing why they are doing something and having autonomy to go accomplish it. The product owner and the acting scrum master need to coordinate the agile process, so the team knows the direction their going, why they are doing things, and ensure everyone has what they need. The work being done in the sprint can, and often will, have surprises, but the process itself should be predictable. When something comes up in the sprint, the scope of what the team is planning to accomplish should change, but not the sprint length, sprint rituals, or quality of the work.
It’s important the scrum process is organized and consistent throughout the sprint. I have experienced anarchic sprints first hand and can confidently say that when the sprint is in disarray, productivity and morale suffer greatly. The course talked about all the different responsibilities and goals of the sprint, and they are all crucial to a successful process, but here are a few things I find vital (in no particular order):
- Clean product and sprint backlogs: this provides a glimpse into the future and makes it easier for people to pickup the next task if they finish all their work in the current sprint
- Definitions of done: this should apply to everything. The tickets in the sprint, the backlog items, the product increment, etc. In my experience this is one of the first things to slide, but these are imperative because they make sure we are building the right thing and that it is of the level of quality we want it.
- Ticket prioritization: the team needs to know what work is most important, so they can pick it up first and avoid putting the sprint goal in jeopardy. One important distinction to make here is ordering vs priority. Ordering is about sequence and priority is about importance. Ordering can come into play if tasks are dependent on one another, but the goal is to focus on importance.
That said, the scrum process is meant to be iterative and one thing that I learned from the CSM course is there isn’t a one size fits all approach to scrum. I went into the course expecting to learn the quintessential “right way” to do scrum and learned that it really does depend on the needs of your team and your business. Certainly there are principles that make it more successful but ultimately you don’t know how it’s going to work for the team until you experience it.
Final Thoughts
Overall I learned a lot from the CSM course and from studying for the exam. I would highly recommend taking the course through KnowledgeHut with Jem Jelly even if you’re not interested in becoming a scrum master for your team. I also met a lot of really interesting people from all kinds of backgrounds while in the course as well. Lastly, I wanted to share few books that were recommended during the course that I intend to check out:
- Measure What Matters by John Doerr
- User Story Mapping by Jeff Patton
- The Toyota Way by Jeffrey Liker