When we created our training materials we included a time line stretching back to the 1700s, which identified significant events, revolutionary breakthroughs and key people that have influenced how we work today. This required quite a lot of research, which proved to be both interesting and enlightening. One of the small gems we got from this effort was a lovely set of norms from Training Within Industry, which was created by the United States Department of War during the World War II to provide consulting services to war-related industries.

The norms, with a couple of additions are as follows:

• Speak your mind freely
• Listen thoughtfully to others
• Don't monopolize the discussion
• Don't let the discussion get away from you
• Indulge in friendly disagreement
• Honor time limits
• Don't play with your phone

The image below shows the original document about The Responsibilities of the Modern Supervisor, which is part of the Management Training Program.

I had an idea for a splash screen for a future Energized Work session about acceptance test-driven development but then a friend suggested t-shirt.

Obviously inspired by the greatest band that ever rocked, AC/DC.

Backlog out. Mind-map in showing user activities and high-level tasks

We haven’t used a conventional list of stories or stack of cards backlog for over a year. We’re lazy. And creating a big backlog that kept on growing with ever more detail and required regular triage was just wasteful. Instead, we’re currently using a mind-map made with Post-It notes, which maps out the different types of users, the activities they’re involved in and the tasks they perform as part of those activities. It's a spin on Jeff Patton's idea of a story map but doesn't require the aircraft hanger. The map is created during a chartering day in collaboration with the client. Here’s an example:

The pink Post-It notes represent the different users. The blue Post-It notes represent the user activities and the yellow Post-It notes represent the high-level user tasks. An example user activity might be 'play football'. The user tasks are also described at a very high-level. Examples might include 'take a penalty', 'pass the ball', 'throw in', 'make a save'. (These may be contrived but hopefully you get the idea.) The map is a fluid visualization. As we have more discussions amongst ourselves and with the client and the users, it becomes more representative of the breadth of user interactions with the product rather than capturing depth or feature detail.

Visualizing investment rather than tracking backlog complete

We don't use a burn-down chart to illustrate how much of the backlog is done. We consider this to be waste because the product is a moving target and the backlog can never done until the product is no longer available. However, we do visualize the investment made in the product to date. Whenever we invest in a high-level user task by building out a story, we place a dot on the task's Post-It note. We use red dots to represent development work. Sometimes pure design work is performed such as creating paper prototypes modeling various user interactions. In this case a yellow dot is used.

Over time the dots often reveal interesting things about the product, the strategy and its direction. For example, at a previous client, despite mapping out user activities and tasks requiring diverse feature sets the dot groupings showed the tendency of business decision makers to stick to their areas of expertise and prioritize their darlings. The visualization showed deep investment in a few areas making the product functionally quite specific and consequently appealing to a smaller set of users. The lack of broader investment eventually prompted the business to start adding flexibility to the product with other features in order to pursue different users they had identified during chartering. We also surfaced the amount of money invested to go with the dots, plus quantified benefits realized from the investment (this is sometimes difficult to do). This made the prioritization conversations far more meaningful.

Kanban board - Input Queue | WIP | Done

At LSSCUK, Karl Scotland asked me to talk a little about a new layout for our Kanban board that we were experimenting with. The columns of traditional designs started to feel like bars in a prison cell. We wanted something that felt freer with more space to doodle and accumulate interesting and relevant snippets of information relating to work-in-process. Here’s a photo of our latest Kanban board:

On the left-hand side there is an Expedite slot at the top, which is typically for pink cards representing defects. Beneath that is what we call the Sin Bin. It has 2 slots. This allows us to temporarily shift up to 2 cards that are blocked work-in-process to the side. We don’t so this lightly but sometimes there’s only so much we can do to remove obstacles without escalation or magic (which is one reason why we loathe dependencies). Finally, we have a small input queue containing those cards not yet started. The number of cards in the input queue varies but it’s never more than 2 or 3. Often the queue is empty.

Cards that are done are placed on the right-hand side. Done means released if we're doing continuous deployment or inventory if we're using a weekly release cadence.

The middle area of the board is the work-in-process. Up to 4 cards can be in process simultaneously (excluding any cards in the Sin Bin). The quadrants provide enough space for the story cards and avatars plus notes, mind-maps, sketches – basically the stuff we've discovered about the stories that we want to keep visible. This has proved to be an effective catalyst for discussion leading to exploration of users, their problems, feature solutions, technical options, etc.

When a work-in-process slot becomes available we call a timeout and run a Pomodoro planning game to discuss and write a new story to pull into play. If we know another slot will become available soon we sometimes decide to plan a second card, if there’s time remaining in the Pomodoro session. This second card goes into the input queue until a slot frees up. Huddled around the mind-map with the client we discuss which high-level user task to work on and write a card describing a story related to that task, which can be done in 2 days or less. For a prioritized high-level user task, the approach is to start with a cheap version of the feature, which provides the minimum functionality that allows the user to perform the task. We revisit features over time to add functional depth based on user feedback. The goal is to iterate features to improve the functional effectiveness and flexibility, and enhance the user’s interaction experience. For example, take the high-level task 'pass the ball', the first version of this might be a story like 'pass the ball 10m along the ground to an unobstructed player' (or, if you're an England player 'lob the ball hopefully up the field to the shortest player on the pitch';). A later story might be 'cross the ball ahead of a player running down the other touchline', and so on.

You might've already seen these sketch notes but I wanted to publish them on this blog because, well, I think they're just wicked. They were drawn by the inimitable Tim Malbon at Made By Many during an Energized Work training session.

Deming's Plan-Do-Check-Act cycle is a scientific method for problem resolution. But it isn't just about resolving problems in a timely fashion. Used properly it raises awareness of context in order to solve a problem by identifying and removing its root cause so the problem won't recur and thus improve the long-term performance of the system.

Plan

Before planning changes, it's important that we first grasp the current situation to gain an understanding of the system and how the problem has manifested. We should to 'go to the source' and observe the problem in situ for ourselves. This helps us challenge our own assumptions, clarify the problem, and verify our mental image of how the system works. To be more objective we should study the system and the problem from as many viewpoints as possible. We always look at least from the perspectives of the business, its customers, and the product itself (the product has needs - it wants to be healthy, reliable, be used by customers, etc). And we look at the economics of the situation too.

We must develop a hypothesis about the root cause because without it our approach is just trial-and-error and we won't learn anything. We then devise countermeasures, i.e. changes to the system that will address the identified root cause, and we design an experiment to implement them in the system. The experiment must include suitable measurements. These are used to visualize the future system state by defining explicit expectations for the countermeasures and, of course, measure the effects of the countermeasures to determine whether the system was improved.

Do

We conduct the experiment and execute the plan immediately.

Check

This is the step most people don't do or don't do well. We have to measure the effects of the experiment using the measurements we defined in our plan. By comparing the actual results to our predictions, we confront our assumptions to gain insight, validate understanding is accurate, and confirm what we think we've learned.

Act

If the results are satisfactory, we can incorporate the solution into system, e.g. if it's a process change we make it the new standard way of working. Otherwise we take remedial action.

With organizations fixated on short-term results, people are driven to work around the problem or deal with it quickly and often clumsily. People usually take the visible and immediately obvious manifestation of a problem to be the actual problem and set out to resolve that. But it's more than likely a symptom of something more deeply rooted. In which case the problem will recur.

We use PDCA repeatedly to root out the true causes of problems and systematically find and verify better ways of working. By running short experiments we are able to continually test our understanding for assumptions and gain insight. In effect, we are constantly learning.

Estimates are lies and estimating is waste. That doesn't necessarily mean it can't sometimes be useful. It's still waste but used at appropriate times, in appropriate ways, and understanding the flaws in the results it can help things along with business and finance people and clients. People just have to realize that it's just not possible to be any good at estimation. The best you can hope for, and certainly what you should aim for if you have to do it, is consistency rather than accuracy. If you're always consistently over or consistently under that's enough for reasonable planning.

A few words on planning generally - don't get up on the plan, it's over-rated and will be out-of-date as soon as the wheels hit the road. The act of planning, however, is an important learning exercise. It helps you develop the right reflexes and it's necessary for identifying high-level goals. Doing the work is about producing the planned goals not following the plan.

Let's get back to estimation. One person giving estimates is just opinion. And if that person is someone not actually doing the work then, frankly, what the hell do they know! If you're doing the work and you're being told to buy into estimates you had no part in making, then you should say no way! When you're estimating the work you'll be doing, you'’re very likely to be optimistic. We're all good at underestimating the likelihood of obstacles and focusing on the best case. We even think we can estimate better because we've become more familiar with the requirements, the software and the users' needs over time. Perhaps there's some small truth in that but there are always unknown unknowns lurking in the dark getting ready to jump out. Even when we start work and we’re learning as we progress we’re still no good at estimating how much work is remaining. We're great at knowing when something isn’t started and we're ok at knowing when something is actually finished, but we’re bloody rubbish at anything in between.

Using range estimations

People have asked how Energized Work is using estimates nowadays, if at all. Well, currently, we don't work hard at estimation but we have found it useful in two regards - forecasting and reducing variation to achieve smoother flow. Being ever conscious of waste, we have reduced and continue to reduce the waste within the estimation mechanisms we use so that we get the benefit for the least overhead.

We only use range estimates. A single point in time estimate - "the functionality specified will take 64 man-days and will cost £126,396" - is pants and feeds the illusion of accuracy. Management and clients probably already think an estimate is a promise to deliver so don't give them the impression of accuracy. A range estimate - "that can be done in 1 to 2 elapsed days" - conveys the amount of uncertainty inherently present to management and clients, whether they like it or not, and sets their expectations more realistically.

An aid to forecasting

These days our backlog is a story mind-map that identifies the user activities (e.g. play football) and the constituent high-level user tasks (e.g. pass the ball, tackle a player, take a penalty, throw the ball in, take a corner). We use this level of scope detail for forecasting, which is linked to incremental funding from our clients based on a quarterly charter. Stories on the mind-map are quickly estimated using t-shirt sizes for ease of language. Each t-shirt has an elapsed day range from the least time it would take to complete the story to the most time it would take.

The least estimates are added and the most estimates are added. Together they create a total range estimate - "somewhere within this range of time and this range of cost, up to but not exceeding the budget, we can deliver something within this range of functionality". The odds of getting 'on the green' (or in the box) are way better that 'hitting a hole in one' (or hitting a specific date). Providing a range has always been good enough and acceptable for forecasting and budgeting purposes.

Reducing variation and smoothing the flow

In 2007, Jeff Patton reminded us all that it's not iteration if we only do it once. As a means to vary scope effectively, deal with uncertainty and still hit the deadline, he prompted us to iterate the functional depth of features and prioritize features by necessity, flexibility, safety, and finally by comfort, luxury and performance. We've been working this way ever since.

When a space on the Kanban board triggers an on-demand planning Pomodoro, we huddle around the mind-map, identify the user activity to invest in, write a physical story card for the prioritized high-level user task and discuss an acceptable level of functional depth to build for validation by users. Only at this point, does a high-level user task such as 'take a penalty' become something more specific like 'blast the ball into the top right corner from a short run up'. Knowing when the acceptance criteria on the back of the card have captured enough detail and whether the story is about the right size drives the amount of discussion. The story card is then placed on the Kanban board.

Right-sizing stories reduces variation, which helps us achieve a smoother flow and a more predictable cycle time.

It also allows us to simply count the number of cards to determine throughput, work-in-process, inventory and calculate an indicative cost per card that gives us financial figures for the cost of inventory, rework, etc.

The right size story for us is about 2 elapsed days, on average. Small is beautiful in so many ways - complexity is reduced, the regular sense of completion is a nice feeling to experience, and actually, we don't have to over-process to achieve functionally coherent stories this size because we've actually become really good at it over the years. We ditched planning poker a long time ago. It was always effective but took longer than was necessary. Now we simply ask can the story be done in 2 days or less? If everyone answers yes, then we're done. Otherwise we talk a bit more and agree how to reduce the scope a little, then we ask the question again.

What next?

This is working well for us currently. It has really helped us to have just enough discussion to make a start, deferring more discussion to later. But I'm curious to see what happens when we stop asking whether stories can be done in 2 days or less. I wonder if the average story size will remain the same? Is it a collective instinct that drives enough discussion to happen so that we arrive at a story that is approximately 2 days or less to complete? Or is it simply answering no to the question? I wonder.

Continuous improvement has always been an implicit part of being agile and with the growing awareness of work by Deming , amongst others, plus the increasing popularity of Lean thinking, it is rightly becoming the centre of attention. And yet, I suspect much of the continuous improvement that happens may or may not be actual improvement. I wonder if most of it proves to be negligible in the grand scheme of things.

When thinking about continuous improvement it's important to understand the work as a system. Systems exist within other systems so decide where to define the boundaries. At Energized Work we work in product streams. Each product stream is a system of production geared to the market and includes the customers. Most people are probably aware of Deming's Plan-Do-Check-Act cycle. But in many cases it's probably used only partially. Mostly change is planned without defining measurable expectations for the outcome. Almost never is the outcome checked against those expectations and rarely is the outcome understood in terms of its causes. The vital step of checking is often missed, and planning and doing without checking is just decision-making that’s not validated. Checking reveals all kinds of things we should know about and it helps us understand and remove root causes of problems. But without a way to measure the impact of changes on the system we can only rely on a qualitative assessment as to whether an improvement was achieved. Qualitative assessment is useful but having data allows us to conduct analysis and gain better insight. Measuring the impact of changes using quantitative instrumentation provides us with knowledge that enables us to learn faster and more effectively. Planning decisions are transformed into experiments that help us determine the optimal operating conditions of the system.

Systems exhibit both exceptional and routine variation. When using PDCA listen to the ' voice of the system ' ( Wheeler ’s voice of the process ) because it defines what can be obtained from the system. Statistical process control charts can help understand the system's behavior and identify signals amongst the noise.

Exceptional (special cause) variation

Exceptional variation occurs beyond the natural limits and signals special causes , i.e. things outside the system that are significant enough to skew its output. It indicates dominant cause-and-effect relationships that affect the system that are not being controlled. According to Shewhart 's definition, with the presence of such exceptional variation the system is unpredictable. The system should not be changed to accommodate special causes. Rather the special causes should be eliminated to make the system predictable. Get timely data, react quickly to the signals and conduct root cause analysis to identify the causes. Then take immediate and effective action to remove the causes forever, which may involve making changes to the system (or more likely to the system outside the system :).

The first chart below shows a single data point beyond a natural limit signaling a special cause. The second chart isn't a signal as such but when 3 out of 4 consecutive data points are closer to one of the natural limits than they are to the average it may suggest a possible special cause. Certainly it warrants a closer look.

Joiner proposes additional tests for special causes hidden within the natural limits. These are shown in the last three charts: 8 successive data points on the same side of the average may indicate the system has been 'bumped'; 14 or more data points alternating up and down may indicate the system is moving back and forth with regularity (e.g. perhaps due to on and off-shore teams working opposing hours); 6 or more points in a row steadily rising or falling suggests the emergence of a trend (although Joiner says you seldom detect a special cause with this test).


Signals of possible special cause variations
Originally uploaded by energizr

Routine (common cause) variation

Routine variation occurs within the natural limits over a reasonably long period of time, appears well behaved and is entirely due to common causes that typically reside deep within the system. In this situation the system is predictable within those limits and, unless something is changed, the system continues to behave this way. A predictable system can only be improved by changing the actual system in some fundamental manner, e.g. by introducing new process settings or a new technology or new ways to do the work. Whether to act on common causes of variation is a judgment call. Although the system is stable it may be worthwhile reducing common cause variation to improve predictability even further and increase what the system can deliver. Unfortunately, unlike special causes, there are no obvious signals for common causes of variation. Therefore to reduce its effects run small experiments using PDCA to pinpoint the common causes and then develop changes in the system to counteract them.

Watch live video from Startup Lessons Learned on Justin.tv

At GGUG on Monday 19th April, Gus talked about how to effectively use HTTP caching in Grails applications .

See the video and slides here .

Our purpose is to improve the quality of service for customers. Quite simply, our goal is to delight customers. But Goldratt said 'the goal of every company is to make money'. Making money is mandatory but fixation on profit and obsession with costs is a sure way to become detached from customers. Our goal is not do delight shareholders. Delighted customers become loyal customers and loyal customers provide repeat business. They even do marketing for us. They tell their friends and family who then give us their business and they’re delighted so they tell their friends and family. Making money is a consequence of delighted customers!

There are lots of people who can be considered customers and they have different needs so satisfying them all is difficult. Lets not get hung up on the definition of the word customer. Just think of these people as deriving some form of value from what we deliver. So our deliveries must somehow balance their needs. This isn’t easy but we have a chance when they share a vision, have common goals and are able to provide consensus on priorities. There aren't many delighted customers out there!

But we know this. And yet, change is all the rage. IT is awash with improvements. It still doesn't feel like it's any easier to get stuff done. Consider for a moment, all the things that, in your experience, might be needed to get something out the door. There's a lot of different things right? Organizations are over-organized!

We get separated by specialty. These days it's common to have core platforms and infrastructure with centralized teams providing services like build, testing and release management. The problem with centralization is that it comes at the cost of complexity introducing dependencies, bottlenecks, waste, etc. It's difficult to understand the big picture when all we see is part of the product through a window in our silo. Living in a silo we just end up chasing local targets creating local optimizations and not really helping the product as a whole. It's all too complicated!

Most changes we've observed organizations making attempt to tackle symptoms. The underlying problems remain and consequently people go back to how they were doing things before like zombies back to the shopping mall. Dealing with complexity goes in the too hard box. Complexity is not a setup for success.

The unspoken truth is that failing conventionally is the status quo!