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.

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.

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".

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!

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.


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

Wednesday, December 13, 2017

Eight Agile Wastes of Hanukah: #2 Handovers

Each night of Hanukah, the custom is to light an increasing number of candles, placed in a nine-slot candelabra, the hanukiyah. Two candles are lit on the first night of Hanukah, three on second night, culminating with all nine on the eighth night. One candle — the shamash — is lit with a match and used to light the others. Blessings are said, songs are sung, specific games are played, foods are eaten, and so on. More on these later.

How many candles are needed for Hanukah?

2 + 3 + ... + 9  = (2+9) + (3+8) + ... = 11 x 4 = 44

Agile Waste #2: Handovers

The second Agile waste, common in software development and other forms of knowledge work arises from excessive and ineffective handovers. Like the children's game of telephone, where one child whispers a message to another and another until a garbled message arrives at the last child.

Similarly, when the creation of a complex product or service is split between many people in a strictly linear fashion, with documents and artefacts handed from one person to the next, without confirmation and discussion creating feedback loops, misunderstandings are magnified and collaboration and creativity are constrained.

Arranging larger organisations into functional teams and silos institutionalise and slow down handovers, as do excessive role specialisation.

What to do instead

We reduce handovers through increased collaboration.

Suggestions:
  1. Develop broad expertise in addition to special skills. Become a generalising specialist or T-shaped person. This will allow you to collaborate and contribute to a broader range of activities.
  2. Adopt swarming strategies for work: in software, learn pair programming (two heads are better than one) or mob programming (many heads!). Non-software equivalents abound: e.g. pairs of writers get together to spitball ideas. Don't just pair to solve hard problems: pair to learn new skills.
  3. Workshop ideas rather than passing a document around ad nauseam: get all the right people in a room and thrash it out. The more people, and the less skilled they are at collaborating, the more value you will get out of strong and structured facilitation.
  4. Work in cross-functional teams rather than functional teams
  5. Reduce or eliminate functional silos in your organisation and reorganise around value streams. In technology companies DevOps seeks to remove the distinction between Development and Operations: if you make it, you run it, you support it. If something breaks it's your problem to fix it — and that's a healthy feedback loop!
Finally, just as a single candle is used to light all the other candles on each night of Hanukah rather than each lighting the next relay-style, ensure that your on-site customer or Product Owner is highly available to the whole development team to discuss and clarify nuance and detail.

Tuesday, December 12, 2017

Eight Agile Wastes of Hanukah: #1 Low value features

Tonight marks the start of the Jewish festival of Hanukah, commemorating in part an ancient miracle in which oil supplies for the eternal flame in the Temple of Jerusalem were running perilously low: there was only enough oil for one day, but that oil lasted eight days — long enough for fresh supplies to arrive — an ancient miracle!

In a modern interpretation Hanukah can be seen as a conservation festival, drawing attention to reducing waste, encouraging recycling, caring for the environment, and so forth.

In this spirit I am going to do a twist on the idea of publishing an advent calendar by recounting "eight wastes" of Agile, one day and one waste at a time.

Agile Waste #1: Low value features

No-one adds product features that everyone regards as low value, but all too often your (or my) bright idea doesn't turn out to be all that great in retrospect. "It seemed like a good idea at the time" is a common refrain, but after the fact is too late, and the damage is done.

Low value features are wasteful in several ways:
  1. They steal time from designing, developing, marketing, and selling other, better features.
  2. They increase product complexity, increasing maintenance costs
  3. Their eventual removal is also costly

What to do instead

The Pareto Principle (80/20 rule) suggests that roughly 20% of features are responsible for around 80% of product value. Those are the features to build, but it's not necessarily easy to figure out which they are!
Therefore: 
  1. Apply strategies like Design Thinking and Lean Startup to validate ideas and build prototypes and minimal versions rather than naïvely pursuing a grandiose vision. Then iterate like crazy.
  2. Listen to your customers and not the HIPPO (Highest Paid Person in the Office). Use techniques like Hallway usability testing, Customer Research, and A/B testing to validate your hypothesis that a feature really adds value.
  3. Explore techniques like user story-mapping, story-writing, service-blueprinting, and impact mapping that help with contextualisation and prioritisation.

Credits

The idea of relentlessly identifying and reducing waste comes from Lean Manufacturing, adapted for software development most notably by Mary and Tom Poppendieck.

Sunday, December 3, 2017

How to be a good Agile Stakeholder

The Stakeholder Role

Stakeholders ultimately aim to deliver value to the end users and customers of the organisation, as well as serving complementary concerns, such as staff sustainability and happiness, legal obligations, and organisational effectiveness and profitability.

In trying to serve these aims they will frequently request work from Agile Development teams via the intermediary of the Product Owner, who constructs a single prioritised backlog for his or her team.

Coöperation over Competition

Stakeholders may be viewed as competing with each other for the development team's finite capacity. But a better way to view their role is in coöperating with other stakeholders to deliver maximum value (on balance) per time period, be it a sprint, a quarter, or a release.

Good Agile Stakeholders work with the Product Owner to clarify their needs, which then get queued up in the form of a single backlog.


Key points
  1. Participate in collaborative planning and prioritising exercises — especially Discovery sessions — with other stakeholders with the aim of educating about your area, while understanding how it fits into the big picture.
  2. Learn about the Agile approach to development: watch (and periodically re-watch) Henrik Kniberg's excellent Product Ownership in a Nutshell [15 minutes]
  3. Attend workshops and sprint reviews (product demos) to help plan and inspect the output from the team
  4. Help break down large pieces of work into smaller bits
  5. Respect the prioritisation process

What about when I need something done now?

Agile teams typically maintain an Express or Expedite lane to allow for emergency work. As a stakeholder you may request truly urgent work via this mechanism, but do not abuse it! 

Although emergency services vehicles can travel fast through traffic, everyone else has to slow down. In the same way, use of the express lane gets the expedited work done faster, but it slows down all other work. Use sparingly.

Lessons on Product Ownership

I interviewed my wife, Andi Herman, who acts as Product Owner for our start-up, youpatch.com, on the big lessons she has learned in learning about how to be an (awesome) product owner.

Understanding the Product Owner role is helpful for stakeholders, who get most of their work done via the Product Owner.

Here's the summary:
  1. Shared Understanding: Take the time to develop absolutely clarity of understanding between PO and the team around what is meant by backlog items. Learn each other's language. 
    • Why? Because ambiguity leads to wild goose chases and waste.
    • Examples, sketches, screenshots, etc. are helpful here.
    • Invest the time to express yourself clearly and to validate understanding through discussion
    • This is a great reason for the team to write the stories to demonstrate their understanding and the stakeholders to read them
  2. Steer clear of micro-management: Understand that although you might envisage one way to accomplish a task, but don't try to enforce that on the development team. They may have better ways. Learn to trust the competence of the team.
    • Stakeholders own the Why? of backlog items
    • The PO and team collaborate on the What?
    • The team owns the How?
  3. Prioritisation: Understand that things need to happen in a certain order
    • The PO balances business value (ideally cost of delay) with estimated duration when prioritising the product backlog
    • The team may somewhat re-order by adding in considerations of risk, learning, and dependencies
    • E.g. You can't put the roof on a house before the walls (dependency)

Conclusion

Agile delivery offers a great deal to stakeholders: faster feedback, better quality, and the ability to change course in the light of learning, new ideas, or changing external conditions. But it does demand a shift from giving orders to greater interaction and collaboration, and for most people it will be a journey of learning ... but one that can be professionally and personally extremely rewarding.

Sunday, November 26, 2017

My Coaching Philosophy: Feel the Learn!

Feel the Learn!

I'll sum up my personal coaching philosophy in three words: "Feel the Learn!"

Physical trainers are apt to say "Feel the burn" as a shorthand for training at a sufficient intensity to challenge muscles and force an adaptive response.

Through my Agile coaching I don't expect your muscles to burn — that would be a surprising and probably unwelcome side-effect! — but you should be burning fresh neural pathways as you learn and improve.

The intention of the snappy phrasing is to act as a reminder that while a wide variety of practices and principles can be brought to play as part of an eclectic coaching approach, they should serve the higher purpose of helping people to actively learn, and to value learning.

Why?

In a fast moving world, the fastest learners win. The coaching profession exists to help people learn and perform effectively. Ideally, we teach people to learn independently, and collaboratively: to think for themselves and to play well with others.
Coaching can focus on achieving external goals or developing personal capability. Of course, the two are inter-related: strengthening capabilities makes it easier to achieve external goals, while setting explicit goals help us to focus.

Personally, I lean somewhat to the learning and capability side rather than the goal-focussed side of the coaching coin. With improved insight and capability goals become easier to achieve, and the confidence in one's skills and capabilities tends to be transferrable to new goals, especially meta-skills like knowing how to learn.

What?

How do you know that you've really learned something? I believe a good test is what you fall back on when you are distracted, or when the going gets tough. Then you find out what you've internalised.

For example, when I discovered that (like most people) I had learned to tie my shoes incorrectly and resolved to fix this I ran into a problem: unlearning is typically more difficult than learning. While I only needed a small modification to my shoe-tying routine — loop under rather than over —it took me over a month of conscious and frustrating practice (frequently catching myself in the old habit) before I was able to switch over to the new routine automatically.

Good learners (and coaches) are humble. Not because "they have much to be humble about", but because there is always so much more to learn. The best sportspeople in the world have coaches who the athletes can out-perform at their given sport, but their coaches bring other attributes — typically around, technique, conditioning, and mental training — that help their charges rise to ever-greater levels of performance.

How?

I like to model the coaching engagement on the Tuckman model, also known as "forming, storming, norming, performing".

The forming stage is about getting to know each other and sense-making: where is there room to learn and improve? What are the strengths that can be harnessed? Where are the weaknesses and blindspots that need recognition?

In the storming stage I challenge some pre-conceptions and maybe this is resented: after all hearing that you're not perfect is typically a bit of a blow to the ego. Or maybe we disagree on where the work needs to be done. If I believe that what I'm going to raise is particularly challenging I may prepare the ground by asking, "Would you like to hear the truth, or the comforting lie?". So far people have always asked for The Truth, but this does help them steady themselves!

Having navigated the storming stage we can start to set some norms about how we're going to work together: different people learn differently, and a nice aspect of bespoke coaching is that we can tailor the techniques and style more so than in a mass-production, get with the program style.

Finally: performing. Having built up rapport and established some norms we are set up to engage in the serious business of learning and improving.

My actual coaching cycle looks a bit like this:
  1. Identify an area for improvement
  2. Engage in some targeted learning
  3. Relate that learning to on-job-work, with coaching support
  4. Practice, practice, practice, correct, practice, adjust, practice, practice, ...
  5. Reflect and improve more, maybe identify another area to improve
  6. Profit!

What Else?

One of the great lessons I learned from undertaking a Diploma of Education is that learning should centre on the learner and pretty much every style of teaching works for some (but not all) learners in some (but not all) contexts.

Therefore I aspire to have a wide variety of tools at my disposal, plus the judgement to pick a suitable approach for particular learner(s).

This jibes nicely with my personal desire to keep learning, improving and exploring, both for my own benefit, and to help serve my clients. A few key areas of personal learning that inform my coaching approach are: martial arts (25 years and counting), improvisational theatre (past), Integral Facilitation (current),  and — of course! — parenthood (ongoing ;-).

Key take-aways

In my coaching approach I emphasise
  1. Capability development over fixed goals
  2. A bespoke approach over one size fits all
  3. Reserving sufficient time for continuous improvement (including learning)
  4. Deliberate and repeated practice to internalise new skills
  5. Building self-coaching capability
Or, in three words: Feel the Learn!

Tuesday, November 21, 2017

Getting Started with User Stories

Why User Stories?

In Agile (software development and otherwise) we need suitable items to populate and pull from our backlogs. Well-constructed user stories balance the needs of stakeholders for valuable and meaningful pieces of functionality with the need of development teams for contextually relevant, but not overly prescriptive work items.

Relevant Agile Principles

Effective use of User Stories contributes to mutiple Agile Principles:
  • Continuous Delivery of Value
  • Welcome changing requirements
  • Business people and developers work together daily
  • Continuous attention to technical excellence
  • Simplicity is essential
If you find that your User Stories aren't helping with these aspects, some reflection is in order!

What are User Stories?

User stories are ideally small chunks of functionality and have become the de facto standard for backlog items. When they aren't small we call them epics or features, and do out best to split 'em down.

The ideal user story satisfies the somewhat famous INVEST criteria (due to Bill Wake):
  • Independent: user stories can ideally be developed in any order, allowing prioritisation of the backlog
  • Negotiable: not over-detailed so as to allow co-creation between customer / stakeholders / product owner and the developers
  • Valuable: it needs to be valuable to the customers or end-users
  • Estimable: a rough sense of size (as well as value) is needed to prioritise the backlog
  • Small: small items can be completed relatively quickly, enabling flow
  • Testable: we want explicit criteria for completion, so we can tell when a story is "done"
Tip: Don't get too hung up on INVEST at first, but keep coming back to it as you build your intuition for what makes a good user story.

How to Create User Stories?

Old school user stories were fairly informal and followed the 3Cs:
  • Card: Written on a 3" x 5" index card, by sticking to one side of a card they were necessarily brief
  • Conversation: "The card is a placeholder for a conversation". The description on the card was intended to be elaborated through conversation between developers and the customer representative or product owner.
  • Confirmation: The back of the card would sketch out minimal acceptance criteria or tests of completion.
Pros
  • Rapid, lightweight, and tacticle
  • Easy to sit down as a group and write cards individually, then combine and re-write
Cons
  • The Conversation aspect practically mandates high domain knowledge and constant access to a customer representative or Product Owner
The newer school, arising from Behaviour Driven Development (BDD), is more formal. The User Story now describes Who?, What? and Why? to give more context, or (more formulaically):

"As [a] ... I want ... So that ..."

And the acceptance criteria are typically specified in Given [current state] When [event] Then [effect] format.

"Given ... When ... Then ..."

Pros
  • Seems to work better for less experienced teams
  • Lends itself to test automation (especially the Given When Thens)
Cons
  • De-emphasises the Conversation aspect, which aids co-creation and iteration
Use whatever works. Try both (and try the other style periodically).

Who writes user stories?

User stories should be written collaboratively by the development team, the product owner and stakeholders.

Often it is delegated to Business Analysts, but their role should be more around facilitating and editing.

What else?

Small stories may be decomposed further into technical tasks, if this is useful for the development team.

Sometimes there will be a piece of work that is meaningless to end users and stakeholders, but makes sense as a cross-cutting piece. These often represent so-called non-functional requirements (NFRs) and that's ok. Often these pieces are referred to as technical stories or architectural epics. They should be the exception rather than the rule.

Other items can appear in product backlogs:
  • Defects
  • Spikes: short investigations
  • Learning and improvement items
Rather than putting user stories straight into a backlog, they can be organised into a user story map. And that's a great move!


Thursday, November 9, 2017

Getting started with Scrum

Here are some notes I've made to act as a prompt for new or newish Scrum Masters to look over ahead of a coaching session with an experienced Coach. The crux of the matter is that Scrum is designed to reveal problems and encourage certain useful patterns of behaviour, while setting the stage for ongoing improvement via inspection and adaptation.
  • What are you doing? How's it going?
  • Are you experiencing any of the common challenges listed below? Or other challenges?
  • Let's talk about it!
Further reading:
* * *
“Scrum isn’t a silver bullet; it’s a silver mirror.”
“Teams that finish early accelerate faster.”

Keys
  • Think of Scrum as a system for delivering and improving, that can itself be improved.
  • Understand the intent behind the practices; don’t just follow them ritually.
    • Ask “Why?” and don’t be satisfied with simplistic answers.

Scrum in a nutshell*
  • Set a sprint length of 1 to 4 weeks (and stick to it)
  • Start of sprint: Set a meaningful goal; pull an amount of work from the Product Backlog into the sprint backlog that you can reasonably expert to finish in the sprint, while reserving learning / improvement time, and saving some capacity for urgent, unplanned work
  • During the sprint:
    • Hold a daily stand-up
    • Hold a set number of refinement sessions during the sprint to help the Product Owner prepare the upcoming items nearing the top of the Product Backlog
    • Check completed work against your explicit Definition of Done
  • End of sprint: Review / demo, hold a retrospective

*This is a process view, and doesn’t get into the roles or finer points.

Some common challenges

  • Unfinished work at the end of the sprint
  • Learning / improvement time gets squeezed out
  • Coping with “surprises”
    • Unplanned work
    • Unexpected absences
    • Unexpected work item complexity
    • External blockers
    • Other impediments
  • Poorly defined work or acceptance criteria
  • Difficulty in breaking work into small chunks
  • Team members with “nothing to do”, and lacking the skills to help others
  • Uninspiring sprint reviews / demos
  • Retrospectives feel like a waste of time
  • Lack of follow through on retrospective actions

Saturday, September 23, 2017

Agile/XP Coaching for Automation Success

If you'd like to discuss how I or a colleague can help you with Agile and automation adoption in your organisation (and avoid "the Agile Trap" discussed below) send me an email: daniel.a.prager@gmail.com

Introduction

The central thesis of my talk on Agile/XP Coaching for Automation Success (slides below) is that success in automation is 80% mindset, skill and culture and only 20% processes and tools.

My claim echoes the first of the four core values of the Agile Manifesto, that "we have come to value Individuals and interactions over processes and tools".



Backtracking a bit, why is automation a key to Agile success? Simply because in Agile (and its descendants, Continuous Delivery and DevOps) we seek to deliver quality software to our customers in a constant stream of small, continuous batches. To do so without compromising quality we must constantly run test suites to quickly detect (and then remediate) any regressions. Running and re-running test suites is a task much better suited to computers than humans, who get bored by repetitious work, make mistakes, and are relatively slow and expensive.

Now, if you buy that argument, you may proceed to the head of the class and skip the rest of this article. Presumably, your automated test suites match the pyramid profile on the right, and you're good to go!

AgileTestingPyramid2.jpg

You have successfully made the argument that speed comes from quality, your developers understand that writing automated unit tests enables fast feedback loops and helps them sleep at night, and you are presumably delivering software into production every couple of weeks or faster. (For example Amazon, as of 2014, deployed new code on average once per second.)

However, for most organisations, their testing profile looks more like the ice-cream cone situation on the left, and this has likely come about because the prevailing mindset and culture within the organisation is resistant to the logic and many successes of Agile software development, which is perceived as deeply threatening and irrational.

A precedent: the Copernican revolution

The situation is not unlike the stand-off in the early 1600s between Galileo and the Church. Galileo championed the idea that the Earth revolved around the Sun (rather than vice versa), a theory previously advanced by Copernicus. While not being burned at the stake, Galileo was forced to recant his claims and live out his life under house arrest, despite having convincing evidence (essentially incontrovertible scientific proof) for his claims.

f-d66117b7502d406bfdd8864adfff4d28a49693c8aebd239d82baa9a54IMAGE_THUMB_POSTCARDIMAGE_THUMB_POSTCARD.1

Now, the important point here is that Galileo's Copernican view was deeply counterintuitive on a naïve reading, while the Earth-centric view is fairly intuitive: from the standpoint of most earthlings the Earth does feel immovable, and it is correct that the moon revolves around the Earth, and it appears that the Sun and planets similarly move around our fixed planet.

To appreciate that the Copernican model is superior requires an understanding of the limits of the Earth-centric model, and how the counterintuitive aspects can be reconciled.

Have human beings improved at integrating new(ish) ideas that go against the conventional, societal wisdom? It doesn't look like it to me!


* * *

Today there are many such mental shifts required to master Agile and Lean ways of thinking and acting. One example is valuing flow over busy-ness: the illusion that if we are busy at work we must be making a solid contribution. Henrik Kniberg calls this phenomenon the Resource Utilization Trap and has made a brilliant 5 minute video to dramatise the common misunderstanding.

The Agile manifesto lists four mental shifts out of the box, including the main subject of this post: valuing individuals and interactions over processes and tools.

Here's a critical mental shift I went through early in my software development career: the shift from manual testing after writing a program, to writing self-testing code in advance. Writing test code first is a bit more expensive in the short-run, after all you are writing more code, but it leads to better designs and pays off spectacularly as your code-base grows ...


My Story: How I Learned to Write and Love Self-Testing Code

When I switched from academia to software development in 1997 — making this something of a 20th anniversary blog post — I was appalled by the sheer amount of time I spent in the unsatisfactory activity of finding and remedying defects. Design and programming new features seemed to be value creating exercises, but owing to my imperfections as a programmer (and I am by no means a slouch) I was routinely spending about half my time finding and fixing bugs, both defects of design and implementation: i.e. the crash the program type.

Worse, fixing one bug might break other parts of the program, and I wouldn't find out about this for a considerable period of time. This built up a background stress of not knowing whether the programs I worked on actually worked.

The less said about how I felt about finding defects in other programmers' code the better!

Now, being a hitherto competent academic I figured that there must already be a better way and started searching the existing literature, and soon discovered Design by Contract. I immediately tried it out using my existing, mandated, substandard tools (cough: Visual Basic 5 & 6) and was pleasantly surprised to find that the time I spent debugging plummeted by about 90%! I still made mistakes, but I could now find and fix them really fast. Because I made a relatively small investment in up-front self-tests, when something went awry the computer was helpfully pointing me to the location of the defect, often giving additional insights into the nature of the defect. As a bonus, the added discipline helped clarify the design of my programs, making them more readable, maintainable, and well-structured.

In essence Design by Contract involves documenting assumptions with assertions (simple code that can be read by a human, and executed by the program). Here's an example, written in pseudo-code to transfer money between bank accounts:

define transfer-funds (from, to: Account; amount: Money)
    require
        non-negative-amount: amount > $0.00
        sufficient-funds-in-from-account: from.balance ≥ amount
    do
       // code to transfer the funds
    ensure
        correct-amount-sent: from.balance = old from.balance – amount
        correct-amount-received: to.balance = old to.balance + amount
    end

In this example the require clauses tell the computer to halt the computation if a zero or negative amount is to be transferred, or if there is an insufficient amount of funds in the from account. In either case blame can be correctly levelled at the calling code.

On the other hand, the ensure clauses check that the correct amount of money has been subtracted from one account and placed in the other account. If one of these conditions are violated, the local code (shown in orange) is to blame: it didn't deliver on its promise.

The net effect of systematically following this discipline and more advanced aspects of Design by Contract is to make highly readable and code that is self-checking. Bugs are found fast, and usually easily remedied.

Do you notice that the code that does the work is omitted? With well-chosen assertions the job of the code is make sure the assertions all pass when given valid arguments. Interesting! The purpose or why is contained in what's expected (required) and what's done (ensured).

Occasionally there is a defect in the assertions themselves, but in practice these tend to be fairly straightforward to find and fix. 
Another objection that is sometimes raised is that these checks (especially the ensure checks) can be quite computationally expensive. While there is some truth in this, computers are now so fast that a lot of checking is quite affordable, and there are trade-off strategies that can be brought into play when these expenses become a problem: typically slower, more thorough checking against a test suite to flush out problems early, and lighter use of expensive self-tests in production.

Back to the story: I was overjoyed by my new practice of this more effective way of programming. I was having more fun, had become more effective, enjoyed the aesthetic improvements to my programs and had far more confidence in their reliability. [A few years later, when I learned about the similar, but different Test Driven Design / Development (TDD) I was happy to find a second, related technique that gave similarly positive results. There are others in the family.]

But what was interesting (and again, appalling) was that my colleagues did not follow my lead. It was all too much trouble. The expression "bondage and discipline" may have been used. Sadly, this reaction is not unusual in the programming profession.

And don't think management was of any help: at the time they didn't "get it" either. Have you ever tried persuading non-technical management to permit pair-programming (let alone mob programming)? These qualitatively beneficial and (net) cost-effective techniques suffer from being counter-intuitive and only make sense from a more sophisticated perspective.

Mindset, Skill, and Culture

So why can't people just see? When you find a better mouse-trap why doesn't the world sit up and listen?

I urge you to reflect on your own experiences of when you have been wrong. We've all been there! A tightly held belief that you've foolishly clung to, is ripped away ...

The problem is, none of us are omniscient, and there are other beliefs that we continue to foolishly hang onto, but which are they? When someone argues against your existing belief, how do you distinguish the sage from the charlatan?

Inevitably track record comes into play. If I have reason to trust someone's level of discernment I'll be more likely to contemplate their challenging idea. If not, not so much. A useful rule of thumb is that "extraordinary claims require extraordinary evidence".

Mindset

A very useful concept courtesy Prof Carol Dweck is Growth Mindset vs Fixed Mindset. Growth and fixed mindsets are attitudes to one's ability to learn something. A person with a fixed mindset believes strongly in nature over nurture: either I can or can't do that thing: learn to dance, do calculus, whatever. By contrast a person with a growth mindset believes that they can learn through study, practice and application.

The key point is this: if I have a fixed mindset about something I'll just believe that my level of achievement is basically set, so why bother improving and learning? That's why some Agilists have been known to refer to the growth mindset as the Agile Mindset. It really is a key to continuous improvement.

Skill

A growth mindset puts you in the right frame of mind to learn, but deep skill takes time to develop. Daniel Goleman (of Emotional Intelligence fame) makes the point that most amateurs learn until they hit about the 50 hour mark and then plateau, while world-class performers and athletes continue to learn and improve under the guidance of a Coach, who helps them mix things up and break through those plateaus to increasing levels of performance.

Pablo Casals, the great cellist, when asked in his eighties or nineties why he still practiced for so many hours a day, replied: "Because I think I am making progress".

Of course, Pablo Casals owned a fabulous cello (the tool), but without his amazing skill very little of value would have emanated from the instrument. Forced to choose, I'd much rather listen to Pablo Casals playing an inferior cello than an amateur playing on a Stradivarius!

Culture, and the Agile Trap

We can see how coaching and deliberate practice coupled with a growth mindset leads to ever-increasing skill, but without a supportive culture you're dead in the water.

Increasingly I am witnessing what I call the Agile Trap. Here's how it works: by introducing pretty basic Agile techniques from typically Scrum or Kanban, a team or teams will get an immediate 10% to 30% bump in performance. That's huge by normal standards, but well short of the Agile promise of twice the value in half the time (a 400% uplift). The trap is to go, "Goody: let's push through 10% to 30% more work from here on, and slap ourselves on the back". The bad news is that even that uplift will drop off as people burn out.



The smart move is to reserve all or most of that capacity for continued re-investment. Learn UX methods so you're building the right stuff, and how to automate so that you're building it right.

Toyota has risen to become the pre-eminent car manufacturer based on a culture of innovation, experimentation, and continuous learning over decades. My good friend, Sydney-based coach, Dave Martin expands eloquently on this point in his article on Sustainable Pace for Organisations. Too many leaders announce victory before putting in the hard yards. They think that the end goal is all there is, and forget that the journey of learning and improvement is long and involved.

Real Learning and the 70 : 20 : 10 Rule

One of the problems that I've observed in conventional corporate training is that it seems to work as a check-the-box exercise, with too much weight placed on formal training, and insufficient attention paid to integrating and internalised new skills in the workplace.

The real test of what you've learned is to notice what happens when the going gets tough. Do you make use of the new skills, or fall back onto old ones? To truly incorporate new skills requires not just conceptual understanding — which we have seen cannot be taken for granted — but also repetition and habit-building. For example, it took me over a month to re-learn how to tie my shoes after it was pointed out to me that I was tying them wrong. And to remain at the forefront of shoe-lacing tying technique — and in the spirit of continuous improvement —I will need to learn how to tie my shoes again!

At time of writing the standard approach is to send employees off on a standardised two-day course and then expect them to return with skills raring to go. There are several problems with this model:
  1. Attendees usually only a retain a fraction of the material
  2. Contextualisation is left to novices
  3. There is typically little coordination between the follow-up activities and the training.
A superior model is to gradually integrate new skills into the workplace in smaller modules, with coaching support. The 70 : 20 : 10 rule is a rule-of-thumb for this: for every hour of formal training, plan on two hours of on-the-job coaching / mentoring on real tasks with the new skills, and then about 7 hours practice with lighter touch supervision to embed the skills.

This is the approach I have recently been taking as a consultant / trainer / coach, with promising results.

Conclusion

So there you have it. You can't buy automation (and Agile) success, but you can invest in it through training, coaching, bringing in people with the right skills and backing them to the hilt. Of equal importance is fostering a growth mindset with respect to skill and leadership, with coaching and mentoring for leaders and teams to support learning.

To have any longevity, organisations will need to develop and maintain a culture of excellence and continuous improvement, by becoming true learning organisations. These entities will of course make full use of tools and technology, selecting and apply them intelligently and effectively by dint of their peoples' skill.

By contrast, organisations that try to buy the tools and processes while neglecting the human skill, mindset and culture will be as competitive as a monkey playing a cello! 

We're on an exciting journey to change the world of work (and ultimately the world) for the better. And we're barely getting started!