Cut me Some Slack: The road to continuous learning and improvement

The Prez

In my latest talk at Murex's Agile Community of Practice in Paris, I dwelled on the idea of Slack in the organization.

My goal was to shed some light on the relationships between work, load, capacity, efficiency, productivity, improvement and long term health.

While doing so, I showed how incorporating slack into the process, as counter intuitive as it might be at first, can be significantly positive.

The slides are available at slides.com/mcmoe/slack/

Prerequisite

Before we get started with that, I'd like to address a few definitions to clarify some of the questions brought up via post-talk feedback and mingling.

Feel free to skip these if you are well versed in their definitions.

Iteration

A timebox during which development takes place. A key feature of Agile approaches is the underlying assumption that a project consists exclusively of a sequence of iterations.

The purpose of working iteratively is to allow more flexibility for changes.

When requirements and design of a major application are done in the traditional method, there can be unforeseen problems that don’t surface until development begins.

By working iteratively, the project team goes through a cycle where they evaluate with each iteration, and determine what changes are needed to produce a satisfactory end product.

Hence, quicker feedback and more "agility".

Velocity

is basically the total amount of work completed during an iteration.

Technical Debt

is "a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution".

Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes later on. 

OK, so how does slack fit into all of this?

The Idea

Change is inevitable - in this fast paced world we live in, change is ever more frequent. Companies that cannot respond to change are at a risk of being left behind (see Nokia).

A company accelerating (completing a lot of work) does not mean it can change when need be. It is important to sacrifice some work in the short run as an investment in the long run.

As a company, we wish to increase velocity in the long run but at the same time, we want our people to be happy and enjoy the ride.

So less work today can mean more productivity tomorrow, as we create stable happy teams that deliver more and more high quality value.

Analogies

Cars

Imagine cars as companies and distance covered as work done.

A dragster, is super fast and can cover a lot of distance, however, is a formula for disaster if the road ahead is not outright straight.

A Porsche, is fast but also has "agile" maneuverability, allowing the driver to swerve and rapidly change direction in case of a "crossing Moose" or hard curve.

So a company that cannot change is more of a dragster and one that can is closer to a Porsche.

Game of Fifteen

  

In the game of fifteen (or game of eight in the diagrams above), your goal is to get the numbers in order by using the empty space to move the tiles about.

If we were to add a tile "9" to increase space efficiency by some 11% and achieve an optimal layout, we would lose the ability to change the layout!

Other Analogies

 

Think of how expansion joints are installed on bridges to account for thermal expansion and how power lines are always installed with slack to take temperature and wind into account.

Even the sock absorbers in your car can be thought of - imagine your car without them, sure not a big deal on a straight and newly paved road - but things are bound to get nasty once you start hitting pot holes.

Busyness vs Business

Getting work done and delivering business value is one part of the goal; the other part involves learning, growing and enjoying ourselves in the process.

Being extremely busy as an organization does not in no means infer that it is being productive, in fact I can argue that, extreme busyness is injurious to the real work it aims to achieve.

Let's take an example that can illustrate this better, and we can then look at how introducing slack, however counterintuitive at first, will lead to more productive behavior.

Efficiency has a cost

It's possible to make an organization more efficient without making it better

Let's start with an organization that seems to be hyper efficient. Imagine the flow of work between such individuals as illustrated above. Each circle is an individual, the edges between them is the flow of work and the cubes on each edge is a backlog where work is buffered. The buffering is needed since the individuals are one hundred percent busy all the time as they each operate at their maximum capacity. This means, any new work they receive at any point in time must be buffered and wait its turn. In such a case, we can see how being very efficient, or in other terms "very busy", at each node in the graph can make the overall system "less efficient".

If we consider the time to complete a unit of work is equal to the time it spends in the illustrated graph, then all these buffers end up slowing down this unit as it makes its way across the organization aiming to be completed.

Now how about we introduce some slack and see what happens to such a work flow? 

In this updated illustration above, we no longer have the cubes acting as a buffer. We've made each individual less efficient by making them take on less work than their maximum capacity. If we rethink about that unit of work, we can see how it can be a lot easier for it move across the organization, thus takin less time to complete. This is due to the fact that at any point in time, each individual is ready to instantly respond to a new unit of work, complete it and send it on its way to its next destination.

That's not all! Given that each node has some "idle" time which we put aside for these unexpected but inevitable new units of work, each node can self reflect on itself, the process and its context within it. 

This is an important part of a company's continuous improvement and evolution. In this example, imagine Bilal was no longer required to complete work being sent from "You" to "Simona". This could be due to several reasons, maybe "Bilal" delegated such responsibilities to "Simona" at some point in time, or has simply switched departments. If "Bilal" was busy all the time he would not have realized that, and even if he did he won't have the time to readjust the progress and remove himself from this work flow. But now that he does, we will end up with the following graph below.

The organization has now improved its work flow and our unit of work passes through the system at much faster speed. Just like the cars and the game of fifteen, the extra agility we had allowed us to adjust and change to our environment.

Allow the organization to breathe, to reinvent itself, and to make necessary change.

Slack is investment, not waste

As counterintuitive as it may have seemed at first, I hope I've managed to shed some light on how "less is more" and that slack is not time wasted, but rather is time invested in long term health.

Think of a company's R&D department. A company invests in a group of individuals today so that it can develop products and insights that can evolve and improve it tomorrow.

Slack is in fact a very similar concept, but instead of it applying to a specific mysterious department, R&D becomes part of the DNA and culture of the company and each individual within it.

We are all responsible for the continuous improvement and evolution of our company. We are our company. Change comes from within - and slack is a way to achieve this via a bottom-up approach.

When companies can't invent, it's usually because their people are too darn busy (see Nokia again).

Learning to think of slack as an investment instead of waste is what separates companies that are "in business" from those that are actually "merely busy".

Benefits of Slack

In general, if I were to sum up the benefits of slack in two words, I'd say "Better Responsiveness".

As a result of slack the many benefits include

• Reduced Stress
• Increased Agility
• Capacity for Redesign
• Capacity for Change
• Key personnel retention
• Improved ability to invest
• Capacity for sensible risk taking instead of risk avoidance (think #!/DEVLABS)

How to implement Slack?

Great, so you've reached this far. You're convinced slack is important and should be implemented in your team. The real question now, is how?

There are several ways to do so. In the Agile teams I've worked with, we've implemented a few ideas and it has tremendously helped us and those that we interact with.

I list these ideas below with details about each. If you want more information please don't hesitate to ask me or drop me an email.

Velocity Stabilizer

In each iteration a team aims to complete a given amount of work it commits to. The amount of work it actually completes is that iteration's "velocity". In an agile team, you aim to increase this velocity. If implemented correctly, you should gradually be able complete more and more work as iterations go by. If however, you end up with a "bouncy" velocity chart as seen below, then you should take this as an indication to introduce some slack.

A bouncy velocity chart means you've overcommitted. The solution is to commit less! This allows you to ensure that you will at least complete what you commit to. In doing so, your team becomes more reliable and commendable. In turn, the team is happier and feels better about its delivery and abilities. 

Now what about the remaining time we might end up having?  Consider this difference as slack. Note, this does not mean you work for 8 out of 10 days and go home for 2! Remember, slack is not waste.

For example, only commit to eighty percent of what you used to previously commit to. Then in the remaining twenty percent, schedule important work that is not time critical.

Schedule work you can set aside in case of an emergency. Such work can be the concepts explained later below, such as technical debt, research time and reading groups. These are not the only candidates, so feel free to play around with different ideas that better match your team. If you have some ideas you would like to discuss, I'll be more than happy to go over them with you.

Technical Debt

Even the best teams accumulate technical debt. In the picture below, those square wheels are your technical debt!

Now that we have incorporated some slack time, we can use that to clean up and improve those unnecessary obstacles we face everyday that slow down our daily work.

Technical debt could be in code, such as design, dead code, buggy code, fragile code, unnecessary long steps and workarounds that delay our development feedback, etc....

Technical debt could also be non-code related. You could have technical debt in the way you book meeting for example, or how long it takes to deploy an environment.

To me, anything that unnecessarily slows me down and we see a viable solution for, I consider as technical debt.

List these obstacles with your team members and prioritize them. Then each sprint, tackle on during your slack time and improve your overall process or development cycle.

Removing them today, will make you faster tomorrow, thus increasing your capacity which in turn should increase your velocity as can be seen in the plot above.

Research Time

Sometimes, things like technical debt might be difficult to solve and might need some research into better technologies or concepts. Also, as a team, you want to always be up to date with the latest breakthroughs and innovations in your field so as to become more competent and improve your skills and that of your product. 

You can take some time during the sprint to carry out some research on specific topics and ideas. For example on the day before the end of the sprint, take half a day in the morning to research either individually or together as a team and then share your findings and plan next actions that can help you improve your process or product. Remember, half a day goes by very fast, so stay focused and avoid any distractions.

Reading Groups

An alternative to research time, are reading groups; particularly for teams interested in discussing fundamental ideas rather than exploring new technologies.

Pick a book or article to read and then discuss together as a team. There is so much out there that can help improve your skills and product.

Side Effect: A Shock Absorber

Committing to less provides the opportunity to guarantee delivery on commitment and provides the time to improve the team's process and remove impediments that slow us down, in turn increases our capacity in the next iteration! Wonderful, isn't it? 

Another benefit of this is that the slack time we introduced can now act as a shock absorber. All those unexpected units of work that come out of no where in a middle of an iteration can now be treated and delivery without disturbing our original commitment. So those defects or QA fixes, unexpected sick days, major production issues - no problemo.

Conclusion

A busy organization does not mean a productive one. The best companies are less "busy" and are more "in business".

In today's world where change is inevitable, slack provides the agility needed to reinvent, innovate, evolve and respond to change in a timely manner. 

In the Agile world, slack:

• Allows you to be “done done”
• Enables consistent velocity by enabling you to meet you iteration commitments
• Diminishes your need for overtime
• Guarantees you meet your iteration commitments
• Provides you with a chance for extra refactoring
• Helps you reduces technical debt
• Eventually leads to an increase in team capacity

And specifically for developers

• By spending so much time paying down technical debt, your code steadily improves increasing your productivity and makes further enhancements easier.
• Furthermore, Research increases knowledge that helps you develop more effectively and provides insights

However, watch out for these pitfalls.

If your'e Always cancelling Slack or consistently using most of it to complete your original commitment, then you’ve overcommitted. Try and introduce more slack, stabilize your velocity and tackle those non-time critical issues.

It ain't slack if it's always required

References

The Art of Agile Development by James Shore and Shane Warden

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom Demarco


PS: Here's a PDF version of this article

---

By Morgan Kobeissi

Twitter handle: @mc_moe

Blog: http://blog.mcmoe.com