Who Is Delivering to You?

In the previous post, Whom Are You Delivering To?, we pondered some questions about service delivery. Those questions can bring about some clarity and stimulate improvement.

Now imagine someone who delivers to you did the same to understand their service delivery. How would that help you?

Jack’s Story

Jack was considering a new project. One of his options would involve some eCommerce functionality.

It turned out another business group in his company had already delivered something similar. That group’s codebase was well-refactored and included a service layer and API Jack could reuse. Two products were already using the API. Jack would only need a few new features built and exposed through the API.

Jack’s project success would depend on the eCommerce team’s delivery.

The team had a reasonably deep Kanban method implementation. They understood the two-point commit, measured their flow and drilled lead times by work item type. They could forecast their delivery.

Diagram shows service delivery to a customer, but the service provider depends on another service

Jack said, 90% delivery guarantee in 20 days? I can contemplate making promises to my customers based on that. (Jack’s group would have to include their own value-adding work into their delivery estimate.)

This story didn’t have a happy end. Jack’s project had another dependency. The group providing it was different. All they could “forecast” was, their Product Owner would still be prioritizing the backlog where Jack’s API requests would be among hundreds of user stories. Jack couldn’t trust their delivery. He had to make a more expensive make-versus-buy decision.

Some Questions to Ask

  • Who is delivering to you?
  • Do they know about it?
  • Do they know your delivery expectations?
  • Do they measure their delivery capability with your expectations in mind? (E.g. if you expect a fast turnaround and they measure velocity, answer No, you’re measuring different things.)
  • If there is a gap between their capabilities and your needs, what can they do to close it?
  • Can you help them?
Posted in Kanban | Tagged , , | Leave a comment

Whom Are You Delivering To?

Play this simple game with your colleagues when you have a chance. Give them a piece of paper and a pencil. Tell them to pretend they run a pizza shop. Ask them to describe the variety of what they deliver.

This is a tricky question. The answers are usually about the variety of pizza sizes, crusts and toppings. But let’s look at the Domino’s store closest to where I live. (You can tell I live in a temperate climate.)

Domino's Pizza store.  The sign says: "Domino's, the pizza delivery experts."

It’s interesting that Domino’s don’t call themselves the pizza crust or topping experts, but the pizza delivery experts. They are not in the pizza baking business. They are in the pizza delivery business. Baking a pizza pie is just part of the process of delivering it.

The Pizza Service Delivery

The store delivers pizza two ways:

  • Pizza ASAP
  • Pizza at the right time

When I order the first type of delivery, speed is important to my satisfaction. I order this service when I’m hungry. If it takes too long to deliver my pizza, I have to look at other options, such as ordering Chinese takeout or cooking something in my kitchen.

When I order the second type of delivery, speed is not as important as the precision. It can take many hours from placing my order to taking delivery. If I have invited guests and want to serve pizza at 7pm, I wouldn’t be happy if the store told me, like a cable guy, to be there from 5 to 9. In that case I would have to look at other ways of entertaining my guests. (But this store can deliver with the 5-minute precision.)

Note that the two services have different customer satisfaction criteria:

  • speed
  • precision

Note that neither service has, as a satisfaction criterion, a metric resembling velocity or throughput. Customers mind with their own pizza order delivery, not how many pizzas per hour the shop can bake.

It does matter, of course, how well-cooked the pizza is, how it tastes and whether the toppings are correct. But the standardized ingredient supply, baking process, and topping checklists take care of that and result in predictable, satisfactory quality. The “expert” part of running this business appears to be how to manage the work and sequence the orders such that the shop can deliver to two different classes of customers and meet their conflicting satisfaction criteria.

From Pizza to Knowledge Work

A software development manager requested a consultation with me. His group tried to start an iterative development process, adopted some practices, but was unhappy with several things:

  • their “velocity wasn’t consistent”
  • there were “too many interruptions”
  • the retrospectives at the end of two-week iterations showed that, although something was finished, not all of it was planned at the start of the iteration. A lot of what was planned wasn’t finished.

The following picture emerged during our consultation.

The group was producing a new analytical product. One service they obviously delivered was a stream of new product features. Several key, early-adopter-type, well-paying customers occasionally requested custom analytic research reports. Why the group had to deliver them – it will suffice to say, these particular customers helped create the market and it fit the company’s growth strategy, so it was the right thing to do. These reports required creative work by specialists skilled in statistics and data mining. But the same specialists had to produce some product features as well.

The group had its fair share of production issues. It was also often contacted by the Sales department to assess feasibility of proposed features. The Sales people would use this information to negotiate with customers and possibly close deals. Often, this information would make no difference, the customer would or would not sign up regardless of the feature, but sometimes it would bring in a sizeable new contract.

Here is the summary of what this group delivered:

Service To whom Request arrival pattern Customers’ delivery expectation
Service #1 All customers Backlog Predictable velocity
Service #2 All customers Unpredictable ASAP
Service #3 Select customers Random, but somewhat predictable 7 days (fixed time)
Service #4 Customer within the company Unpredictable 1-2 days

A diagram shows a group delivering four different services

So, there are four services delivered to three different types of customers, work arriving in different patterns, to be delivered against different expectations.

Something Changed At This Moment

The manager realized he was in the business of making four different pizza deliveries!

Now we can discuss how we allocate his group’s capacity to deliver these services, make relevant policies explicit, and so on. We can be free from dogmas like “protect the team from interruptions.” We can appreciate what those “annoying” Sales people do and give them a better service. We can simply start with what we do now and think about making our service delivery better and satisfying all our customers.

Before our meeting, the manager wondered if a kanban system would help his group. We hadn’t designed a kanban system yet, stepped to a whiteboard, put PostIts on it, or crisscrossed it with painter’s tape. All of this can follow in due time. But we did one very important thing.

The visual management part of a kanban system has to show how we deliver services. It is so much more effective if we understand what we deliver and the needs of those we deliver to.

Some Questions to Ask

  • Whom are you delivering to? What? Why?
  • Have you identified all services you deliver? How?
  • What is the arrival pattern of requests for each service? Consider: regular intervals, random, chaotic, backlog, etc.
  • What are the customer expectations on the service delivery?
  • What is your group’s capability to deliver each service? How did you measure it?
  • Do you provide different classes of service? Are any policies governing scheduling and sequencing of work explicit?

Next

Who is delivering to you?

Posted in Kanban | Tagged , , | 1 Comment

Exploring Leadership Traits

I went yesterday to our local Agile group meeting. Selena Delesie was the speaker. Her own consulting business has evolved in recent years from Agile coaching and software testing. It is now more about leadership to create modern, enlightened workplaces. So, she led the conversation about how anyone, at any organizational level, can exhibit leadership behaviours.

Selena told us there are many leadership traits, but gave us five important ones to consider in this session:

  • courage
  • commitment
  • curiosity
  • connection
  • class

In the first round of discussion, each round table group had a discussion to define one of the five by example. When someone exhibits commitment, what does it look like? What do you observe?

One of my discussion mates had a manager who faced a dilemma familiar to many. His team had to do its work, but also needed to learn how to do it better. Under the usual pressures from customers and stakeholders, the former usually wins. But this manager had the courage to say, “we’re going to do both” and “I take the responsibility for this risk.” He took the “both” attitude while his peers settled for “either-or.”

Another table discussed curiosity and someone put “why does it work?” on the flip chart, resonating with me. The convenient, lazy, “it worked for me” language can be heard often in companies. “Here’s how we did it in my previous company and it worked for us.” It takes a curious leader to lead the inquiry by asking “why did (does) it work?”

In the second round of discussion, each table had to pick one particular practice (my table choose Daily Meeting) and discuss: how would this practice be affected by the presence and the absence of each of the above five leadership qualities? The people at my discussion table reflected mostly on their teams’ Scrum practices and compiled lists of positives on the left and negatives on the right.

Now, if you know me, I’m a coach and trainer from the school of thought that departed from the three-question team stand-up a long time ago. Our approach avoids the dysfunctions of the three questions and makes the daily meeting faster, more engaging, and can induce multiple acts of leadership within minutes. So, I asked my discussion group what would they change in your daily meetings to diminish the negatives on the right and increase the positives on the left?

One of them answered, our behaviours result from the rules we have for our daily meetings. We could tweak the rules.

That was a good answer.

Posted in Kanban | Tagged , , | Leave a comment

KDP Example #2: Training and Courseware

In my previous two posts, I showed how we can understand a delivery process as a knowledge discovery process. As knowledge workers do their work, a sequence of dominant activities enables knowledge creation and accumulation. The initial post contained an example of diagramming such process for a generic Agile software delivery team. The follow-up post had an example of understanding how a lean startup produced its validated learning through hypothesis testing.

Our next example takes us to the world of training and courseware. It is due to my colleague Travis, who manages a Training Department for a high-tech company. Travis’ department delivers many services, but we’ll consider only one of them in this example: developing courses.

In the process of creating a course, Travis and his colleagues have identified five dominant activities:

  • fact finding
  • instructional design
  • drafting
  • beta-testing
  • publishing

Fact finding is a highly collaborative activity. Knowledge workers from Travis’ department collaborate with Research and Development, Customer Support, Technical Writers and System Engineers. As we saw in other examples of dominant activities, this one creates a lot of knowledge initially, but eventually starts to produce diminishing returns and yields to the next one.

Instructional design is handled largely within the Training Department, but Technical Writing and Sales have a say in its approval. After that, drafting begins.

Drafting the course material eventually reaches the point where a different activity begins to dominate the process of knowledge creation. Beta-testing brings together yet another different group of collaborators, including Marketing, Field Engineers, product line management and, of course, actual beta users. Testing produces another layer of knowledge and eventually yields to the final activity, publishing. This involves creating videos, printed media, presentations, handouts, and so on.

From the previous knowledge discovery process diagramming examples, you may know what to expect here, but it’s a busier diagram this time:

Knowledge discovery process diagram of a process of creating a training course, showing five dominant activities.

Next (although it won’t be the next post in this blog’s sequence), we’ll consider the practical issues with creating such diagrams and using them in improving service delivery.

Posted in Kanban | Tagged , , | Leave a comment

KDP Example #1: A Startup’s Measure-Learn Process

I showed in my previous post how we can understand a delivery process as a process of knowledge discovery.

The resulting process diagram showed how knowledge continuously arrives and accumulates through a sequence of dominant activities. The points separating those activities are not handoffs between functional specialists, but rather shifts in collaboration patterns. There was an example of such process diagram for a generic Agile software delivery process.

Now is the time for some examples of looking at processes this way. And I want to give some examples from the world outside software delivery. We’re going back to early 2003 and my first build-measure-learn loops in what we would now call a lean startup. I lived in New York City at the time and was one of the few engineers in a startup Internet advertising firm.

What Are We Delivering?

The endpoint of this process is the business validation of the next, updated version of our product. Note that what we’re discussing is not the process of creating and delivering the product itself. The product is already made and ready to meet its users. How did we produce validated learning from that point on?

The diagram of this process could look like this:

Knowledge discovery process diagram.  The activities are, in sequence: establishing baseline, measuring improvement, client validation. Three different, overlapping groups of collaborators do the work.

One activity dominated this process early on: ensuring that our VP of advertising operations didn’t have to yell the next morning, “Dude, where’s my revenue?” This potential exclamation can be rephrased as a statistical hypothesis and tested on a small percentage of users, with a control group, of course. We aimed to prove that our latest features didn’t do any harm. We wanted to be 100% sure that our advertising campaign managers could take the updated product, run the same portfolio of ads and earn the same revenue for the day as the control group using the previous product.

Note this had nothing to do with regression testing, which was already done as part of building the product. We could extrapolate our confidence of regression testing to our hypothesis testing, but one of the rules on Madison Avenue is, don’t assume.

Running such experiments involved a core product engineer (usually me), the VP of Advertising Operations, a senior Advertising Campaign Manager, and an Operations guy. As statistically-significant results came in and our confidence grew, the activity began to fade and a new activity started to dominate.

Our next activity was to measure the improvement due to the new features, such as the increased revenue per user. A different hypothesis: the test group, using new ads or a new algorithm, would perform better than the control group. The new experiment required a new group of collaborators. We needed new ads, so we brought in a Graphic Designer, a UI Programmer and our Creative Director. The experiment could prove, for example, that the new geographical targeting algorithm would yield higher click-through rates in the travel category. As the results rolled in and we gained confidence for the full user-base rollout, this activity also eventually faded.

We then faced the last test: Could we use the improved product and the proof of improvement to attract more paying customers? For example, there was a regional airline at the time, flying out of one hub airport to several vacation destinations. They would never buy a nationwide advertising campaign, spending like American, United or Delta Airlines. Could our new product, targeting ads with high precision, turn this airline into our customer? (It did.) This activity required yet another collaborator, Sales, to work with the same advertising campaign managers and the creative staff, while the role of engineers was minimal. So we saw yet another shift in the collaboration pattern.

Once Again

In this example, we’ve looked at a delivery process in a knowledge-work field as a knowledge discovery process. We’ve visualized it as a sequence of dominant activities. All once-dominant activities fade and yield to new activities. Each time that happens, it signals not a handoff of work to another functional department, but a shift in the collaboration pattern.

Another example to come.

Posted in Kanban | Tagged , , , | Leave a comment

Understanding Your Process as Collaborative Knowledge Discovery

There is a general trend and desire to make work more collaborative. Yet when I ask teams to draw a diagram of how they work, they often come up with something like this (I’m simplifying it):

Boxes and arrows. Functional specialists hand off work to each other back and forth as they try to deliver something.


In this view, the workers form an assembly line. But their work doesn’t really flow like an assembly line. For example, a Software Developer may find a logical inconsistency in a feature specification and send the work back to a Business Analyst. A Quality Assurance specialist may do the same when testing the implemented software. The BA will update the spec and send the work back to QA. QA may find a bug in it and send the work back to the Developer. The Deployment Specialist may find something in the code to be an impediment to deployment. The Developer then makes the necessary change. The code now needs retesting, so it goes back to QA, after which it goes again to Deployment.

So the team members draw many arrows going back and forth between them to show all these handoffs.

Some try to visualize this process on a board they call “kanban”:

Visual board hiding handoffs and backflows.

Then they ask, what if, for example, testing hands the work back to BA or Dev? Should the card stay in its place or move? What if we have WIP limits? (Those numbers in the column captions.) What if that column is already filled up to the limit and another card needs to move back?

Is There a Better Way?

This problem is fairly common and rooted in the misunderstanding of the nature of knowledge work. Rather than a series of handoffs between specialist workstations, it is mostly about creating information and knowledge. It may be limiting to try to make such process look like a block-diagram.

In our example of software feature delivery, the following knowledge may get created, not necessarily in this order:

  • the exact configuration of the production environment (OS, Web server, database server, third-party software)
  • key examples of how the software feature will behave, use cases, acceptance criteria, executable specifications, etc.
  • how to integrate the new feature with the pre-existing software functionality (upgrade procedures, data migration, etc.)
  • what will design and implementation of code exactly look like
  • what tests are needed to support the implemented code
  • how the integrated software behaves with respect to its performance and other quality (non-functional) requirements
  • results of usability tests and exploratory testing sessions
  • etc.

Anyone in any knowledge work field can come up with their own list of knowledge they create in their own delivery process. When the work is complete, all of such knowledge is there. But when we only get started working on a request to deliver something, it is not there yet.

If we tried to visualize the process of accumulating this knowledge, the result could look like this:

Knowledge discovery process. The knowledge accumulates due to a sequence of collaborative activities.

In this example, specification activities dominate the early phase of the delivery process. The Business Analysts may lead the analysis of the feature, decomposition, fleshing out requirements. But other specialists can contribute at the same time. Testers may help turn acceptance criteria in to (executable) tests. Deployment specialists and Developers may weigh in on what may have what impact on the codebase and infrastructure.

This activity produces a lot of knowledge from the start, but it fades eventually. We can’t analyze our way to delivery. So, code construction becomes at some point the main way to accumulate knowledge.

A lot of code construction falls on Developers’ shoulders, of course. But others can help, too. Requirements may still need refinement and clarification (hello BAs). A Tester may take the partly finished software, test it and give feedback to a Developer. Developers can collaborate with Deployment specialists to see how the emerging code changes may impact deployment.

But this activity will fade too. We can’t make further progress by polishing the code. So, we switch to testing it and focusing on getting any remaining bugs out. Another knowledge-creating activity begins to dominate. Testers lead it, but they get help from Developers fixing bugs, and others as well.

Note that the three inflection points in the new process diagram are not handoffs between functional specialists or departments. They are changes of the dominant activity and the corresponding shifts in the collaboration pattern.

Conclusion

We don’t have to look at processes as networks of specialists and handoffs. When trying to understand our processes visually, we don’t have to diagram them as boxes depicting the specialists and many arrows connecting them every which way.

We can instead consider our delivery process to be about information arrival and knowledge creation. By asking ourselves, what activities do we perform to discover knowledge to deliver what we are delivering, we can visualize our process as a sequence of collaborative activities.

What’s Next

In the next several posts, I would like to give some examples of such Knowledge Discovery Process maps, mostly for processes outside the world of software delivery. I need another post to give guidance on how a process coach can go about mapping such processes with real teams of knowledge workers. For those using kanban systems, this approach has some implications for how to design and operate those systems.

Posted in Kanban | Tagged , , | 5 Comments

Kanban’s Organizational Patterns

Header Image - Pizza ShopI’ve received an email from my friend Stan looking for an outline of ideas on how to spread his Kanban implementation from one unit/team to the rest of his company. I get asked this question often and there are patterns with what Stan is trying to do. So, I’m copying and pasting from my email response to him here, with all private information deleted, obviously, and the rest of the message adapted somewhat for the broader audience.


Remember service orientation. We create Kanban systems largely so that we can understand and improve some service that we’re delivering. Therefore, organizational Kanban systems should reflect some services that we’re delivering as a whole organization. They should not merely radiate or “roll up” information on tasks everyone is doing.

Keep eyes on the prize. What challenge are you answering: to increase throughput, decrease delivery time, improve quality, predictability, due-date performance, relieve some sources of unhappiness? When you know your challenge, it informs the design of each kanban system. It also helps find the next evolutionary steps.

Scaling up with two-tier Kanbans. There is an example of this pattern in the Chapter 13 of the blue book. It is also covered in the Foundation-level class. (Stan and several his colleagues took the class and saw this pattern emerge during the kanban system design exercise.) The workflow is hierarchical. At the upper tier, work items are coarsely grained (e.g. feature sets). For some part of the upper-tier workflow, those large work items break down into more finely grained items (e.g. features, user stories), which flow through the lower-tier workflow.

Scaling up with Portfolio Kanban. Pawel Brodzinski’s blog is a good starting point. Pawel also made a good presentation on Portfolio Kanban at a recent conference.

Scaling out by joining Kanban systems. This means gradually joining two or more kanban systems separated by infinite (no WIP limit) buffers into a single kanban system. At the early stages of using Kanban, you may find yourself in a situation, where WIP is limited for each (most, some) workflow stages, but these stages are separated from each other by unlimited buffers. Stringing together multiple WIP-limited workflow stages into a single kanban system may be culturally difficult early on in Stan’s company or may create an unsafe-to-fail experiment.

Scaling out in the service-oriented fashion. Various departments and teams have their kanban systems, delivering services to external customers as well as to each other. One system’s external dependency or output could be another system’s source of demand/input. Each system seeks its own balance of demand and capability, but they’re interdependent. Interdependence helps unlock improvements. Russell Healy’s Obeya project is the cutting edge in visualizing this interdependence (link to a video of Russell’s recent conference talk explaining it).

Scaling by learning. Designing kanban systems in various departments, sustaining them on the daily basis, evolving them cannot be taken for granted. It takes people real effort and the people need training, community support and coaching.


Which of these patterns do you find most helpful in your company? What other pragmatic advice can you give to Stan?

Posted in Kanban | Tagged , , | 1 Comment