Tuesday, December 19, 2017

All Eight Agile Wastes of Hanukah

In this series I cover one "Agile waste" for each night of Hanukah.

Kind of like the purported Hanukah miracle, in which one night's worth of oil lasted for eight nights I've made a single idea stretch across eight (now nine) blog posts!

To recap:
  1. Low value features (introduction to Hanukah)
  2. Handovers (lighting candles)
  3. Defects (dreidel)
  4. Technical Debt (Hanukah songs)
  5. Work in Progress (Latkes)
  6. Task-switching (Sufganiyot)
  7. Delays (Neyyappam)
  8. Human Potential (Gelt)
How about a ninth waste? Norman Bodek has suggested "Managers' resistance to change" as a separate category, but I think I'll save that one for another time!

About the wastes

"All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes." Taiichi Ohno

Lean Manufacturing recognises eight wastes and its worth reading about these in the original manufacturing context. They can be summarised in the DOWNTIME acronym:
  • Defects
  • Overproduction
  • Waiting
  • Non-utilized/underutilized talent
  • Transportation
  • Inventory 
  • Motion 
  • Excess Processing
Mary and Tom Poppendieck translated the wastes from manufacturing to software development (slides). As with Agile software development, it turns out that most of these also make sense for any form of knowledge work. I've used their list as the basis for this series, and added in "the eighth waste" of non-utilized talent (human potential) to round out the set to Hanukah size.

I trust you have enjoyed the series, and encourage you to visualise your value streams from concept to cash, and start (or continue) eliminating waste!

Eight Agile Wastes of Hanukah: #8 Human potential

Originating in 17th century Poland, it has been customary for parents to give children gelt (i.e. money) for Hanukah.

Since the 20th century this has transformed into giving chocolate coins as a substitute or in addition to the cash.

If they wish they can then risk some of their chocolate coins by playing the Dreidel game (see Agile Waste #3).

Agile Waste #8: Human potential

When we regard human beings as cogs in a machine we cheat ourselves (and them) of their greatest ability: to learn and improve. Moreover, they frequently become demoralised and disengaged.

It is only human beings that can inspect and adapt: they can study the system in which they are part of and eliminate wastes and embrace opportunities.

Many management practices are either anything goes (which works at very small scale) or soul-crushingly bureaucratic. In this hyper-competitive and fast moving era we can and must do better.

By valuing and supporting people, they will become more energised, more productive, and less likely to leave. Replacing knowledge-workers is far more expensive than manual labour, as the time to acquire local and tacit knowledge in a new environment is typically lengthy and will require significant additional effort from existing staff.

What to do instead

There are many approaches to personal, team, and organisational development. Here are just a few suggestions:
  1. Reserve substantial time for learning and improvement. As with product delivery, small batches are best: e.g. half an hour or an hour each day, or half a day to a day each fortnight. Blend individual and team learning, and personal and organisational learning priorities. Team-members should have significant autonomy in choice of learning areas. This is more difficult than it seems, but worth it!
  2. Embrace the 70 : 20 : 10 model for learning and development: 10% formal training and coursework; 20% coaching and mentoring; 70% challenging assignments.
  3. In product development organisations hold occasional hackathons
  4. In a software team trial mob programming or start a coding dojo
  5. Start a book club and read and discuss relevant books as a team or management team. Nowadays, what with books being so old school, you can also read blogs and watch and discuss relevant Youtube videos together.
Outside of work: For health and character development I personally practice martial arts, but that's not for everyone. Something that will take you on a journey to mastery that is probably not directly work-related is the ticket. Practice something meaningful long enough, and it will eventually influence how you work: here are my 10 Agile lessons from the martial arts.

Learn (even) more

For excellence in Agile & Innovation consulting: Skillfire

Monday, December 18, 2017

Eight Agile Wastes of Hanukah: #7 Delays

Neyyappam are another traditional food fried in oil for Hanukkah. These sweet fritters are less widespread than latkes and sufganiyot, and are a specialty of the Cochin jews of South India.

I have not yet had the pleasure of trying neyyappam, but they look to be delicious!

Agile Waste #7: Delays

"A fast game's a good game."

Delays generate numerous kinds of waste:
  1. If there's a long delay between planning and doing, conditions will often change, rendering your plans out-of-date.
  2. Delays between activities make it more difficult to remember important details, resulting in additional defects (Agile Waste #3) and additional time spent re-learning.
  3. The longer something takes to deliver, the longer the wait until benefits begin to be realised.

What to do instead

There are many great techniques for reducing delays:
  1. By mapping your value stream(s) from concept to cash, you can identify where the big waits are and focus improvement efforts there.
  2. Don't just limit your WIP (Agile Waste #5), limit your queue lengths. Long queues make for big waits.
  3. Record impediments that result in delays and prioritise improvement activities to reduce and remove them.
  4. Big items take longer to finish. Learn to split them down, and prioritise the high value components.
  5. At the individual and team level, organise your work day to maximise maker time — big blocks of uninterrupted time — to help doers get stuff finished by reducing managerial interruptions.

Learn (even) more

For excellence in Agile & Innovation consulting: Skillfire

Sunday, December 17, 2017

Eight Agile Wastes of Hanukah: #6 Task-switching

Foods fried in oil are compulsory Hanukah fare.

Next up we have sufganiyot (in Hebrew), also known as ponchkes (in Yiddish), a kind of deep-fried jelly-centred donut.

Nowadays you can get all kinds of exotic fillings — chocolate, custard, and so forth — but I stand by tradition (or habit) and go for the jam ones!

Agile Waste #6: Task-switching

Excessive task-switching is a natural extension of having too much Work in Progress (Agile Waste #5). 

If you have lots of things on the go, you will need to switch between them to keep them all moving. Even if some are blocked, there's a cost to periodically checking whether the blocks are still in place.

Every time you switch between tasks there's a switching cost associated with recovering context and focus. Worse, your mind is paying a holding cost for every additional task that's on the back-burner while you work on one at a time. For knowledge work this cost per item is considerable.

Some people wear there purported ability to multi-task as a badge of honour, but this is an illusion. I suspect that they are mistaking the feeling of busyness for efficiency. That's a big mistake.

What to do instead

First of all, prove to yourself that multi-tasking is inefficient and stressful. There are plenty of simple experiments you can do by time-trialling yourself at the same task done with and without task-switching. Here's a good one.

Next, reflect on the insight that (if you are multi-tasking) you are needlessly wasting a huge amount of time and energy.

Finally, start uni-tasking: organise your self to do one thing at a time, or at least fewer things than you did before. Naturally, all the advice on limiting Work in Progress applies here (Agile Waste #5).

You will most likely also notice that by paying full attention to one thing at a time the quality of your work also improves, reducing defect creation (Agile Waste #3) and increasing your work satisfaction.

* * *

If you manage or work in a team reflect on how much more effective (and calm) your team can become if you all stop trying to keep lots of balls in the air, and instead focus on getting a few small pieces of work flowing through the system at high speed.

"The sooner you start the sooner you finish" and "If you want something done, ask a busy person" are dangerously misguided pieces of advice.

Much better: "Limit your WIP" and "Stop starting; start finishing".

Learn (even) more

For excellence in Agile & Innovation consulting: Skillfire

Saturday, December 16, 2017

Eight Agile Wastes of Hanukah: #5 Work in Progress

By association with the Miracle of the Oil it is customary to eat fried foods during Hanukah.

Latkes are traditional roughly shredded potato cakes and they are delicious.

The key question about latkes is this: salt or sugar? I like them with salt, but as a proud Australian I also enjoy them topped with smashed avocado.

Agile Waste #5: Work in Progress

Work in Progress (WIP) is simply unfinished work. Clearly, unfinished work needs to be brought to completion before it is useful.

Too much WIP causes multiple issues:

Firstly, it hides problems. Having lots of tasks (or projects) on the go at any one time gives you the illusion of productivity: if any one task is delayed you can always work on something else. But this popular strategy hides systemic issues. If instead you reduce your WIP you will now be confronted by delays and inefficiencies and become inspired to understand and remove them, and thereby improve the efficiency of your system.

Secondly, work gets finished slowly. Working on lots of things at once, or even a single large thing, means that everything moves slowly through the system.

Thirdly,  priorities are unclear. With lots on the go the emphasis shifts to getting stuff done irrespective of its importance. Busy-ness rather than delivery of value soon becomes the focus. Ugghhh!

What to do instead

The advice here is simple to state, but easier said than done. Limit your WIP!

Go learn how to do Kanban and/or Scrum — the best known forms of Agile project / productivity management — properly. Both have a focus on WIP-limiting, with Kanban offering more fine-grained control.
  1. Visualise your work: e.g. write each work item on a card or sticky note and estimate its size. Split the big pieces into digestable chunks.
  2. Limit your WIP: in Scrum we learn how to estimate how much work we can do in a designated (typically one to four week) time-box, while in proper Kanban we place a low hard limit on how many (small) work items are allowed in any work-state at once.
  3. Once you hit your WIP limit you will be forced to start saying "no" to additional work (the hard bit!) and that induces some sort of prioritisation of unstarted work. This is healthy!
  4. Managing urgent unplanned work is the next refinement. The smart play is to reserve some capacity for unplanned emergencies, but be sure not to allow everything to become an emergency, and appreciate that you may need to put some things on hold when major emergencies occur.
This area of Agile waste management is profound: the deeper insight is that it is better to pursue the fast flow of a small number of small work items than keep busy all the time.

Every system has a finite capacity. That includes you, your team, and your organisation. By visualising work we begin to understand our capacity and this gives us the power to tune our work habits. By limiting WIP we are forced to consciously prioritise, balance delivery with improvement activities, and to appreciate the trade-off between throughput and responsiveness.

* * *

Small latkes cook faster than big ones and the first batch will be out of the pan quickly for you to enjoy. As you fry batch after batch you'll also be able to refine your technique through an iterative approach to cooking!

Learn (even) more

For excellence in Agile & Innovation consulting: Skillfire


Friday, December 15, 2017

Eight Agile Wastes of Hanukah: #4 Technical Debt


Following the nightly lighting of increasing numbers of Hanukah candles, it is customary to sing traditional songs. 

Ma'oz Tzur (Rock of Ages) is a popular choice. Here's a nice choral version.

And then there's Adam Sandler's Hanukah song.

Agile Waste #4: Technical Debt

Technical Debt is a metaphor concocted by programmer Ward Cunningham, who also famously invented the wiki. It's a term to help non-technical people and (to a degree) technical people appreciate the insidious consequences of compromising internal technical quality.

What is it? Sometimes (for good reasons or not) developers rush out a feature and do a quick and dirty job. The trade-off here is that the feature is available more quickly to users, but the  the code-base becomes messier and more difficult to maintain, and future feature development will be slower and less efficient.

Here's the metaphor: It's like when you take out a loan. The loan allows you to buy nice things that you couldn't otherwise afford [release new features early], but then you have to pay interest on your loan [clean up the mess you created] as well as pay back the principle [re-write the ill-advised bits of your hackery]. The longer you take paying back the loan the greater the total interest payments [lost productivity].

Technical debt isn't all bad. It makes sense to slam out a fast prototype when you're trying to determine whether a new product or feature is high or low value (see Agile waste #1: Low value features). If it turns out to be low value you can just throw away the code (and not pay back the debt). But, if it's high value the right thing to do is a thorough clean-up or possibly re-write straight away

The insidious bit? Once a feature works the internal hackery to get it up and running is easily forgotten; the effects of the debt will bite later and there's demand for other new, shiny stuff right now. In non-engineering led companies especially this effect can be spectacularly magnified over time.

What to do instead

Always reserve some capacity for paying back technical debt. The real trap is to just keep on incurring increasing amounts of debt and lose the attention to technical excellence that goes with keeping your code-base clean and modular.

A classic way of incurring debt is to skip writing automated tests (see Agile Waste #3: Defects). Writing your tests first —BDD and/or TDD style — helps with both the design quality and psychological discipline needed to avoid the technical debt trap.

In an organisational setting a critical role for technically literate leaders is to educate their non-technical leaders about the very real consequences of unmanaged technical debt and together avoid falling into a debt trap. Incur enough technical debt and you'll kill productivity, and eventually your competitiveness.

Finally, here's some excellent advice from Andrea Goulet on what to do if you do find yourself mired in technical debt: Forget Technical Debt — here's how to build Technical Wealth.


Learn (even) more

For excellence in Agile & Innovation consulting: Skillfire


Thursday, December 14, 2017

Eight Agile Wastes of Hanukah: #3 Defects (and Dreidels)


I joke that Hanukah is the festival in which Jewish children eat fried food and learn to gamble! Hanukah features an iconic spinning top, the dreidel.

Each dreidel has four sides, each with a hebrew letter. Together the letters form an acronym that translates as "a great miracle happened here".

There are rules for a gambling game based on the Dreidel letters, but in my family we just enjoy spinning them in increasingly challenging ways: preferred hand, other-hand, both hands simultaneously, inverted, etc.

Agile Waste #3: Defects

Software defects (colloquially known as "bugs") are instances where the software either malfunctions or behaves in a way inconsistent with its intended behaviour. Famous examples have resulted in lost space-craft, exploding rockets, and death from malfunctioning medical equipment. More down-to-earth defects result in losses of data, financial miscalculation, security breaches. Defects also result in programs that are slow or crash or don't respond to user input.

Designers and Programmers create a lot of defects. The defects that affect end-users and customers are the ones that haven't been prevented or caught and remedied ("debugged"). But unfortunately, in complex software, removing one defect can introduce others.

Finally, software is an automated process, so manual (and mixed automated/manual) processes can be defective too. These too need to be debugged.

What to do

Detecting and fixing defects are important activities, but not intrinsically value-adding, and the rule-of-thumb that prevention is better than cure applies. The longer a defect goes undetected the more expensive its impact and the higher the cost of remediation. The general idea is to move quality left:  it's better to catch defects earlier than later.

Suggestions:
  1. Develop less features (see waste #1) as more software leads to more defects!
  2. Develop clear specifications via techniques such as Specification by Example / Behaviour Driven Development (BDD)
  3. Adopt a modular architecture so that defects can be more easily isolated
  4. Rely primarily on lots of automated tests, rather than manual testing
  5. Do manual exploratory testing to find subtle defects
  6. Write those automated tests at multiple levels (unit tests, component tests, functional tests), to test both technical assumptions and expected behaviour
  7. Have programmers peer review each other's code: the fastest feedback loop for this will be in real-time via pair-programming or mob-programming
  8. Use test driven design / development (TDD) to improve code quality by writing tests first and "refactoring" code for simplicity and elegance.
  9. Run the automated test suite against every change via Continuous Integration (CI)
  10. Explore more sophisticated preventative techniques: e.g. Design by Contract (DBC)
  11. Generally prioritise defect fixing over new feature development: don't trade away quality

Learn (even) more

For excellence in Agile & Innovation consulting: Skillfire