Leadership hack 024 – is getting better more important than getting work done?

Posted by Max on August 9, 2018 in effectiveness, leadership, product development, strategy | 1 Comment

“Improving daily work is even more important than doing daily work”

Gene Kim

You never have enough time and resources, so you throw everything at the task at hand – getting the product shipped or the problem fixed. We have all been there.  It is very, very easy to focus relentlessly on getting your work done.   However, is it better to go ‘all-in’ on getting sh$t done or should you try and do sh%t better?

From a math perspective, the answer is obvious.  If you got 1% better every day, you would be 38 times better after a year (1.01^365).

Even if it took 10% of your day to get 1% better, your effort would break even after 26 days, and then your productivity would continue to accelerate so that after 148 days you would be twice as productive (see chart below).

Principle 12 of the Agile manifesto also supports taking time out to improve.

“Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.” (see here)

But how do you get better?  Here are some thoughts.

1. Think ‘system’.  You cannot understand traffic by analysing a car.  Analyse the system as a whole and how workflows through the whole system.   Find out how much work is done right first time, vs failure demand.   Look at how long it takes for different types of work to go from inception to being complete and adding value to customers (lead time)
2. Attack the constraints.  A constraint is typically one person who wears multiple “expert” hats and through which a disproportionate amount of work “has to” go through to get done correctly.  There are 5 steps for attacking the constraints which is one of the primary ways to increase the flow of work:
   1. Identify the constraint (who are they?)
   2. Exploit the constraint (get the most out of them – meaning: only critical work)
   3. Subordinate the constraint (everything else is secondary to achieving #2)
   4. Elevate the constraint (change other systems to increase the capacity of constraint)
   5. If a new constraint arises during any of the previous steps, go back to step 1
3. Eradicate sources of unplanned work. Unplanned work can take 30% longer than planned work, so if you bring in a ‘3-day’ story midway into a sprint – you need to remove 4 days worth of work!  With code live on production, there will always be unplanned work, but you need to decide whether problems need to be fixed ASAP or can be put into the next sprint (Jez Humble suggests that high performing teams spend only 40% of their time on code that is ‘live’).
4. Standardize and automate infrastructure.  Without that, we have an infrastructure snowflake problem (no two servers/load balancers/deployments are alike).  Platforms and infrastructure should be a service which anyone dev can create instantly
5. Everyone needs a customer mindset.  It is natural for people to try to control and optimise their work.  The issues come when people who are not directly creating value for customers (marketing, risk, compliance, legal) create processes that put burdens on the teams adding value.  Prevention is better than cure, so new processes must be minimised at all cost and must be built with those that use them (the customer).  If you already have ‘a lot of barnacles on the boat’, reducing them will need executive focus and support
6. Reflect and adapt.  At an individual, team and company level take time to reflect on what went well and what could be improved (in Scrum this is called a Retrospective).  Having a list of ‘blockers’ (something that delays work being completed) created by each team that can then be solved by them and by the company as a whole

Use these tools to reflect frequently and learn and adapt.  Leave a comment if you have any other thoughts or ideas.