S.L.I.C.E.
The Experimentation Mindset

Introduction

​

The Wheel arguably may be the greatest invention of all time; not the first one though. And the earliest wheels may not have been used for transportation as against popular belief. No, this article isn't about the wheel, it's about how one arrived at the wheel and why this is relevant to our teams. 

​

I have been a Management Consultant for a while and my fascination with Continuous Improvement began in 2011 with a question - "during retrospectives, why don't we capture actions for things that are going well?" For those who aren't familiar with retrospectives, it's a practice where team members meet at certain intervals to pivot their way of working in order to improve results & situations. And it's not to say that no teams capture improvements for things which are going well, mine didn't. But does that matter and why was this important to me? 

​

The answer lies with the wheel, particularly transportation. Transportation existed even before the invention of the wheel majorly in the form of Boats but also as Sledge. Wheels provided an improvement in transportation even though boats were doing the job fairly well. The general tendency for humankind has been to innovate and although related, it's not the same as invention. While invention involves creation of something novel as a process or a product, innovation refers to the practical way an invention gets implemented, ergo not all innovation require a new invention; like the wheel as an invention not only innovated transportation but also innovated pottery making. Hence it's probably safe to assume that innovation has the potential to occur more frequently than invention and it is this act of constant innovation that usually gets referred to as Continuous Improvement.

​

Both invention and innovation however stem from the same act, the act of conducting experiments. Most businesses realise that change is inevitable and in order to stay relevant it's necessary to constantly innovate, however what's not easy for many to comprehend is the fact that innovation needs experimentation. Usually when I ask a bunch of people if they run experiments at work the answers mostly oscillate between "yes" and "yes, if time permits (which usually means a no)". Many times the act of experimentation itself is not well understood by many and that results in a lower degree of continuous improvement. So what exactly is experimentation and is there a way to do it right?

​

Experiments, Experimentation, and The Scientific Method

 

In 2011 when I embraced the idea of Continuous Improvement for myself (and my team) it didn’t take much time for me to realise that experimentation was the way for me to achieve this. However the only knowledge I had of running experiments was from my time at school and it was oriented more towards proving facts which I understood weren't very helpful. So I dove a bit deeper to understand the nature of experimentation and here’s a gist of what I got. A simple Google search defines Experimentation as “the action or process of trying out new ideas, methods, or activities” and Experiments as “a scientific procedure undertaken to make a discovery, test a hypothesis, or demonstrate a known fact”. Clearly I was looking for a combination of the two which led me to the Scientific Method.

​

The Scientific Method has been around at least since the 17th century with Aristotle recognised as it’s inventor. It provides a structured empirical method to conduct experiments that prove or disprove hypotheses as a part of Scientific Inquiry and it’s models can be utilised for continuous process improvement as well. The constraint that lay with me was that Continuous Improvement requires buy-in from others and one person alone can’t drive it; hence it was important for me to pass on this knowledge to others and onboard them to move ahead with our quest. That’s how SLICE was born. When asked about SLICE, I usually call it an old wine in a new bottle approach towards the Scientific Method; look at the bright side though, it’s a new bottle, it’s a theoretical simplification of the Scientific Method. SLICE provides a convenient acronym for people to understand and buy-in to the process that focuses on the improvement without worrying about the underlying mechanics and elements of the Scientific Method aka small innovation towards Continuous Improvement.

​

S.L.I.C.E.

​

Here’s SLICE in a nutshell: Select - Learn - Implement - Chronicle - Expand

• Select a hypothesis or an improvement idea that we wish to try out

• Learn the relevant topics needed to implement the idea

• Implement the potential improvement

• Chronicle the observations

• Expand the experiment multiple times, over multiple days, with multiple teams

 

It was intentional for a few aspects which were considered here, firstly, the hypothesis or idea can come from anywhere; this meant that not only were we open to improve the parts we were unhappy with but also the parts we considered to be working well for us. Secondly, the term Chronicle was a deliberate choice instead of documentation since the observations could have been recorded using any medium that could be utilised for expansion. And finally, implementing the idea only once wasn’t enough, it was important to persist the change for weeks if not months even if it gave bad results and possibly with multiple teams to determine contextual variations.

​

And that’s it, that’s SLICE and I have tried it multiple times with multiple teams and so far it hasn’t disappointed.

​

SLICE does come with at least a couple of attitudes which are needed for it to be successful though:

​

• Learning to Fail: Given the pretext of experimentation, success is not always guaranteed; in fact we would fail more often. Of course learning from failure is a necessity but if failure is not an option then innovation suffers. It is important to imbibe this attitude in the team and get a buy-in from the leadership in order for SLICE to succeed. This requires creation of a safe environment for team members where they are allowed to do unsafe work (work that’s not fully proven). Tolerance limits for the failure can be created in various forms however Expand requires that this tolerance is not set to one.
   

• Don’t hate what you don’t understand: Criticism of ideas and hypotheses is not allowed in SLICE especially not before enough has been Learned about the Selection. Everything is subject to change even if it’s known to be the current best practice; if it ain’t broke don’t fix it doesn’t apply. Teams may choose one implementation mechanism over the other in a democratic (or any other) way without belittling an idea / mechanism that’s not selected. When it comes to SLICE, ego is the one thing that’s not entertained.

 

Although these form the bare minimum attitudes, teams can have many more that help them experiment with potential improvements; a few that I have witnessed in the past include:

• Theory is as practical as we wish it to be (it’s someone’s practice written in books)

• NOT an excuse to do it wrong (ideas that potentially degrade performance are not allowed)

• Implementers decide the Implementation (not their management; self-managed teams)

 

And many more.

 

SLICE in Action

​

The simplicity of SLICE (one pager) sometimes makes it a difficult pill to swallow as to how this can even work. The way I put it is that complex problems shouldn’t necessarily require complex solutions, the art of maximizing the amount of work not done is essential to improve agility (agilemanifesto.org). Here’s an example of SLICE in action from one of my past engagements.

​

My team and I were involved in building a Business Intelligence platform for one of our European clients and we had already made a few releases while working together for close to a year. Once when our Product Owner visited our India office, we decided to run a retrospective with a focus on improving our ways of working. One of the possible improvements that was called out by all was the amount of meeting interruptions throughout the iteration that resulted in loss of focus. It was time to put SLICE into action.

​

The hypothesis that we selected was that reducing the interruptions caused due to meetings (and possibly the amount of meetings itself) can improve the team's output (no the measurement of output was not velocity, it was just reduction of frustration).

​

The learning aspect involved listing the meetings that we had and questioning their purpose. Once we had the bare minimum, it was time to identify the participants for each. Our primary mode of working was Extreme Programming however since we were operating in iterations, we referred to some basic Scrum as well to identify and reason with the existence & participants of our meetings, for e.g. the need for Product Owner during Daily Stand-ups was questioned.

​

The implementation required some drastic changes and we were up for it, for starters our Daily Stand-ups were scheduled for India evenings to accommodate our Product Owner’s timezone. Since our Product Owner was convinced that their participation was irrelevant for these, the Daily Stand-ups were rescheduled for India morning so the team members could plan their day better. Our iterations ended with a Showcase (with participants from around the globe) and a Retrospective, both of which required our Product Owner to participate and these were re-scheduled for the last day of our iteration post lunch India time to accommodate everyone. The same day before lunch India time was reserved for three activities:

• Brown Bag sessions where team members met and shared their learning from this iteration

• Speed Dating Feedback between all team members

• And a Code Retrospective to identify Tech Debts

 

New iteration began the next day and just so India teams could begin in the morning, our Product Owner was gracious enough to join the first hour of our Planning Meeting in their early hours (before dropping their kids to school). In their absence, the team identified implementation strategies, ran spikes, and began the iteration post lunch India time. And each day ended with a 15 minute Backlog Refinement session with the team which was an indication to stop working. This resulted in an iteration that had ten working days, where the first and last days were designated meetings days and the rest of the days started with a 15 minute Stand-up in the morning and ended with a 15 minute Backlog Refinement in the evening with Zero Planned Meetings in-between. We virtually had zero interruptions on eight out of ten days in an iteration apart from any ad-hoc huddles that were needed to discuss any roadblocks.

​

The chronicles took various forms; after we continued with this practice for over 3 iterations we decided to stick with it and we showcased our happiness during our Office All-Hands, presented it as a Case Study in blogs, and Coached teams when they reached out to us. We had achieved what we set out for, reduction of frustration due to meeting interruptions.

​

The expansion resulted in a lot of learning as well; although this process in practice worked with teams that had context similar to ours, there were a number of contexts where this was tried and it failed (even when the original team members seeded new teams). For e.g. it almost always failed when the team’s time zones had a huge variation like India and the United States; the timezone gap was just too huge to accommodate all the meetings over two days. The process in practice also failed for teams which were not well distributed i.e. the people needed for the same piece of work were in different time zones e.g. a developer in India and a developer in Germany couldn’t pair-up effectively unless one started very early or the other stayed back very late. It also did not work in instances where the Product Owner in a different timezone was not accommodative with certain requests like staying away from Daily Stand-ups. At the same time, many teams adopted this process in practice quite well and even brought in their own variations even-though the original was working just fine. These variations were shared in their chronicles which led to further expansion and hypotheses.

​

In Retrospect

 

SLICE, the Select - Learn - Implement - Chronicle - Expand cycle in my experience has been a great way to achieve Continuous Improvement. Not only does it motivate the team to experiment with new ideas and hypotheses but it also ensures commitment towards actions where the team members hold each other accountable for the required change. However it is important to mention that SLICE isn’t the change, rather it’s an effective mechanism to bring about change that can help build high-performing teams. I’m delighted that what started out as my own hypothesis has proved to be effective with many teams in many situations and I’m convinced that it has the potential to help your team’s Continuous Improvement as well.