Chris Sterling’s Blog

To start with, I want to be honest about my knowledge of kaizen. I have not been in a workplace where the actual term kaizen was used to demonstrate improvements within our organization. I have researched quite a bit about it and found the book “The Kaizen Revolution” by Michael Regan was the easiest for me to read on the subject. This book also follows a fictional situation that creates examples of using the kaizen philosophy to change a company around. Through my research and discussions with others on the subject I have found that kaizen and the mindset shift is similar to that enabled by the Scrum framework.

Scrum is based on an empirical process control that focuses on inspecting the current state and adapting behavior to improve. This focus on continuous improvement through “inspect and adapt” is supported in the Scrum framework at 3 points in the process.

• The Daily Scrum meeting allows the team to focus on their commitment for the current Sprint and whether they are still on track to deliver on that commitment. If they are not able to meet the commitment then they are asked to adjust the Sprint therefore adapting to the situation.
• The Sprint Review meeting allows customers to view a potentially shippable product increment created by the Team and provide feedback that adjusts the Product Backlog contents and priorities. We are inspecting the product and adapting to a new understanding of the product.
• The Sprint Retrospective enables the Team to improve the process they use to delivery software each Sprint. The Team is expected to inspect their process honestly and thoroughly to figure out how they can adjust for improved delivery capability in the following Sprint.

The “inspect and adapt” focus allows for a Team and product to continually improve over time through seemingly simple mechanisms with sizable effects on the software delivered. An unexpected or additional effect of this focus on “inspect and adapt’ in Scrum is the organizational environment encompassing the team starts to adjust based on needs of the Team to improve their software delivery. Therefore a single team causes “organizational change” through small and incremental adjustments.

One of the main tools that a Scrum Team can use to “inspect and adapt” is the “impediment”. An impediment is:

“Anything that prevents a team member from performing work as efficiently as possible” - from Victor Szalvay’s article “Glossary of Scrum Terms”

In coaching teams I have found that capturing impediments is done casually and is not initially found to be as important as other activities the team is doing. Over time I have found a few simple “rules of thumb” for capturing impediments that have helped Scrum Teams:

• ScrumMasters keeping a physical impediment and action item list. As we teach in the Certified ScrumMaster course it is important to action impediments after the Daily Scrum meeting immediately. Many of our teams at SolutionsIQ setup an area to capture impediments written on post-it notes. Following the Daily Scrum meeting team members who are interested in taking action on the newly captured impediments stay behind to work with the ScrumMaster. An action item is created identifying “What” needs to be done, “Who” is going to make sure it happens, and “When” they will communicate progress back. It usually looks something like this:

Impediments getting actioned

• At least 1 impediment raised every Daily Scrum. It is my opinion that if a Scrum Team is unable to bring up at least 1 impediment at each Daily Scrum then the ScrumMaster is not supporting the team effectively. I want the ScrumMaster to find ways to extract at least 1 impediment during the Daily Scrum. In the past I have asked teams whether they were comfortable speaking about an impediment they are having in the Daily Scrum with me there. I have also pleaded with a team to tell me at least one impediment before we leave. One time the Daily Scrum was before a Sprint Review we were going to conduct in the afternoon. Each team member said they had no impediment and at the end I found out that at least one person was not ready to demo the software just by asking “Why are there no impediments today?”.
• Ask everybody on the team to write down at least 1 impediment. Sometimes a Scrum Team has improved significantly and begin to get into a flow. Although I want to celebrate significant improvements we should not sit on our laurels. The stagnation of “status quo” can catch hold quickly and we must find ways to break through this potential behavioral issue. Just ask all members of the team to write down at least 1 impediment and then work with the team to action those impediments immediately as shown above. One of my colleagues, Brent Barton, once wrote up on our white board the following saying that I have found to be helpful to me for fighting the “status quo”:

“The absence of conflict is not harmony, it’s apathy” - from article by Kathleen M. Eisenhardt, Jean L. Kahwajy, and L.J. Bourgeois III called “How Management Teams Can Have a Good Fight”

My own nature has helped me internalize the “inspect and adapt” mindset with Scrum. I used to think I was lazy but the fact that I would work additional hours to improve builds, mock frameworks, test cases, and other artifacts of projects I worked on seemed to contradict this. The reason I thought I was lazy was my tendancy to find ways to automate just about anything that could be so that I did not have to manually do it anymore. My initial splash into programming actually started this way while working in a data entry job. Each day my work was incredibly repetitive. One day a person who understood the software we were using to do data entry showed me the use of a cool macro that allowed fields to be automatically filled out. I was immediately impressed and asked them to show me how that worked. The language used was a Visual Basic knock off and the scripts I wrote following this allowed me to get 10 times faster in my data entry. I was able to focus on other activities including learning HTML, JavaScript, Pascal, and Java. The moral of this story is jump on opportunities to improve your environment including processes, facilities, and software.

Those additional hours I put in has decreased over time as I have found a much more sustainable pace for myself. I cannot say that I keep a fully sustainable pace even now but at least I am able to identify earlier when I am starting to tank. The “inspect and adapt” mindset should not cause our Scrum Team to adapt themselves into a culture of late hours and intravenous Red Bull drips. A Scrum Team should find ways to adjust within their timebox rather than adjust their timebox. This means that hourly, daily, and iteration timeboxes are important to understand and monitor for breakage. As a ScrumMaster I want the team to keep a constant pace as much as possible and sudden adjustments that cause time management problems should be identified immediately and monitored from there to resolution ASAP.

A continual need to improve my life and environment has become an addiction of mine. How can I better use the time I have with my family? How can I help make my work environment even more fun to work in? What can I do to improve my knowledge in all types of subjects? This addiction has been a valuable behavior for my entire life and I hope that others will find something that has similar effects for themselves. People reading this blog who are currently using Scrum please use the impediment to your advantage and find ways to improve your software delivery. It’ll be worth every minute used to “inspect and adapt” your Sprint, Product Backlog, and processes.

2 Comments »

On November 6th I presented an updated version of the Managing Software Debt talk at Agile Vancouver “Much Ado About Agile” conference. This is a link to the presentation deck:

Managing Software Debt - Agile Vancouver (PDF)

I was honored to present at this local conference and had a great time meeting up with old friends and getting to know some new ones. I hope that I can do this again soon. If you are interested in more information and other presentations at Agile Vancouver you can go to their home page.

Comments Off on Managing Software Debt presentation @ Agile Vancouver