Kaizen and the Art of Agility

Turning Challenges into Goals

by Jeff Himmelright

First published on 11 November 2016

“You look at where you’re going and where you are and it never makes sense, but then you look back at where you’ve been and a pattern seems to emerge.” 

― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values

Pause – Inspect – Adapt!

Improving our condition in life is an essence of being human. We seek to improve. As a species, we have always been seeking paths to improvement. But often we debate over what it means to actually improve. What does improvement look like? What are the success criteria to say we have improved? What must we sacrifice to reach this improvement?

In the business of product delivery, we apply metrics to show improvement. Most metrics we seek are quantitative and measurable: “This project came in under budget by $25,000 and has 47 fewer defects than a similar project last year.”

In the end, the validity of the data really depends on the validity of the questions. Are we asking the right questions? Are we performing valid comparisons (e.g., project A to project B)?

It is our nature to reflect, compare, contrast, and adjust. But we often pay disproportionate attention to macro-level results, such as meeting long-term delivery dates or budgets.

Incremental Challenges

“It isn’t the mountains ahead to climb that wear you out; it’s the pebble in your shoe.

― Muhammed Ali

Kaizen means continual improvement, which can and should include making small adaptations over time that eventually will bring about large-scale advances. This strategy is not new to the business world; however, it is often overlooked, because we tend to focus on the big hit.

Continual improvement requires attention to details. But who lives in the details? That’s right – the Scrum teams! The indications for potential improvements often come out during scrum ceremonies, although they may come out any time. An attentive Scrum Master can help pull out these details and identify the true impediments.

Once identified, what do we do about the impediment? We can challenge the team to overcome it. Is your team up for the challenge? Then make that challenge a goal. This is the basis of my article; turning the impediment challenge into a sprint goal.

Challenges Become Goals

Here is a brief case study from the files of my own experience. As scrum master for a fairly mature team, I noted that the team was becoming less engaged during the sprint retrospectives. The general feeling was that we would bring up items that were not going well, but we would not address them adequately. Some retrospective items lingered over multiple sprints.

I decided to try a new approach. During the Sprint Review, we would typically use a short slide deck to summarize the Sprint to the attending stakeholders by introducing the team members, the sprint goals, and what we nominated as completed product increments. To this slide deck, the team and I decided to add two slides – (1) Sprint Successes and (2) Sprint Challenges – which we would later discuss in further detail during the Retrospective. I asked the team members to each identify at least one success and one challenge (which, by the way, were not difficult to pull out because they were quite fresh in their minds). Then I wrote these on a flip chart. (Note: This approach also has the added benefit of allowing Stakeholders and business owners to see the real world of challenges that the development teams work with, but admittedly not all retrospective items are meant for this audience.)

During the Retrospective, I asked the team to vote on one or two challenges and make them goals to either eliminate or improve for the next sprint. Finally, along with the Product Owner’s goals, we placed these challenge goals on the same print-out that we would post next to the Scrum board.

As a simple example: a team member identified a challenge that the test-driven specifications were not being reviewed on time (impeding the satisfaction of our definition of done). We determined the cause – the review tasks were not being created until later in the sprint, because nobody knew who would own it, and by then, nobody paid attention to self-assign them. As a goal, the team set out to create all “test-spec review tasks” and ensure they were assigned by the end of the Sprint Planning day (even if the assignee would later change).

As a result, the visibility and tangibility of these goals (front and center) made it much easier for the teams to address, by making them harder to neglect. Along with the goals from the Product Owner, the challenge goals now became a team-owned mission.

In a sense, I also removed my own impediment; that is, the retrospective engagement and contribution complaint. The strategy: rather than pleading or demanding (as a Scrum-nanny) with my team members, I decided to look for a sustainable solution. My team was not being obstinate so I empathized with their situation. Rather I basically created a new format of the Sprint Review/Retrospective using an experiment.

Being Agile is Always Becoming Agile

Trying small, safe-to-fail experiments is an essence of becoming agile. The modified retrospective (combining it with an addendum to the Sprint Review) certainly does not match any ideal depiction found on many Scrum web sites and guides. Nevertheless, it worked very well for this specific team. The team began to knock out sprint challenges by owning the issues that they could resolve while using the Scrum Master (me) to escalate the issues beyond their control – putting them on the radar for project stakeholders to understand and address. Scrum should be about the people!

Kaizen Promotes Values

Theory: Develop a culture where the team is actively engaged in improving the company.*

Practice: Provide a forum for the team to feel empowered to take action on making improvements.*

Result: A team that is empowered and trusted is a team that will be committed, caring, collaborative, and creatively engaged in continual improvement.

*Paraphrased from https://www.leanproduction.com/kaizen.html

I hope you found this article informative and perhaps entertaining.

Best of luck in all your projects and in becoming agile!