Mapping Your Process as Collaborative Knowledge Discovery – Part 3 (Thinking)

This will be the last post in the series about process visualization in creative industries, specifically within the context of applying the Kanban method and one of its core practices, visualization. Earlier in this series:

Now it’s time to write about the thinking behind the knowledge discovery process, the mapping techniques I presented, and the explanation of what I observed by applying them.

Simply put, we have to respect the complexity of the system – and the group of people working together to perform some creative tasks to deliver their service is a complex adaptive system. Basic understanding of the Cynefin framework is essential here.

Cynefin framework

The problem of evolving processes in our complex system and discovering its future improved state falls into the Complex domain. The Cynefin framework informs us of two kinds of things what should not be doing:

  1. implementing best practices, which belong in the Obvious domain
  2. applying expert analysis, which would be appropriate in the Complicated

A Model of a System Will Affect the System – How Weird Is That?

The Kanban method is an evolutionary method appropriate in the Complex domain. When we introduce a kanban system within the context of the Kanban method, the kanban system is essentially a probe launched into the complex system of workers, their organizational partners and customers. The probe will co-evolve with the system. How well or poorly this probe is designed may affect the effectiveness and success of the evolutionary change. Designing the kanban system and introducing it appropriately in the given context is one of the key skills of Kanban coaches.

System, its model and the process of creating the model all affect each other.

The goal is to provoke improvement in the system, not merely creating a model or map of the system.

In the last several decades, an approach known as Value Stream Mapping (VSM) has become very popular. A value stream map lets us see value-adding and non-value-adding activities that make up the process of delivery of value to the customer. The implication here is that we can improve the process by reducing the non-value-adding activities or waste. This has been done so many times as to create a wide-spread, though not accurate opinion that Lean is about eliminating waste. The hidden assumption here is that we are treating our process improvement problem as a Complicated-domain problem. It is the Complicated domain that permits such reduction and aggregation.

The process visualization we are trying to create as part of our kanban system introduction is a model of our system of work. In the Complicated domain, a good model would be detailed and accurate enough (and VSM certainly delivers that) to enable us to expertly analyze the system and find improvements. But in the Complex domain, which does not permit an approach based on reduction and aggregation, the quality of our model is determined primarily by what response it provokes from the system.

It was observed by Alisson Vale, one of the pioneers of Kanban in creative industries and a 2010 Brickell Key Award winner, that kanban systems with too much detail lead to inertia. If a Kanban board has too many columns in it, perhaps appropriately considering the number of steps in the accurately mapped process, it fatigues the workers and slows down the pace of evolutionary improvement.


The approach to Kanban visualization and observations of using it in practice that I presented in the earlier posts in this series (1 and 2) are largely consistent with complex nature of the problem and the heuristics of the Complex domain.

One such heuristic (a negative one) is retrospective coherence. It warns us about the danger of trying to replicate successes from one system to another. A more effective approach is not to repeat the causes of failure. Inertia due to kanban board detail is one clear example. Mapping the process by a small group of experts is another. Yet another example: steering the conversations in front of the board away from “hey, this is waste, let’s eliminate it” towards safe-to-fail experimentation. Well, in kanban systems visualizations based on the knowledge discovery process, all dominant activities are value-adding!

Other heuristics (positive) are fine-grained objects and disintermediation. Indeed, groups of people participating in the mapping exercise find the right granularity of activities for them. The resulting workflow visualization comes directly from them, and not through an intermediary such as expert process analyst.

Complex systems are also known to be path dependent. We have seen this with “dev” and “test” captions on software delivery Kanban boards. Whereas in a naively visualized process these columns may continue to visualize functional silos, the groups that have taken the path through the knowledge discovery process mapping have a deeper understanding of them as collaborative knowledge-producing activities. “Dev” and “test” are merely convenient shortcuts.

As other kanban system users and Kanban method practitioners try the knowledge discovery process visualization approach, I expect their own ways, recipes and observations to differ from mine. However, I predict that we will have a lot in common when it comes to the complexity thinking behind what we do and the use of Complex domain heuristics. I would love to hear their stories.

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

Mapping Your Process as Collaborative Knowledge Discovery – Part 2 (Observations)

Fig. 1 - Naive process visualization as hand-offs back and forth between functional silos

Fig. 1 – Naive process visualization as hand-offs back and forth between functional silos

Fig. 2 - Pseudo-Kanban board resulting from naive visualization

Fig. 2 – Pseudo-Kanban board resulting from the naive visualization

Fig. 3 - Process as accumulation of knowledge and information through a sequence of dominant activities

Fig. 3 – The process understood as accumulation of knowledge and information through a sequence of dominant activities

Fig. 4 - Kanban system design resulting from understanding the process as knowledge discovery and identifying the dominant activities

Fig. 4 – Kanban system design resulting from understanding the process as collaborative knowledge discovery and identifying the dominant activities

I’m continuing the series of posts dedicated to visualization of creative processes. Earlier in this series, I wrote about:

  1. understanding such processes as sequences of dominant collaborative activities, resulting in knowledge discovery and information arrival – with an example from software delivery
  2. examples of such processes from other fields (one example, another)
  3. mapping an existing process with a group of people working in it

As a reminder, what we’re interested here is mapping the process as it actually happens – through the daily interactions and irrational decisions of the people involved. Instead of naive, siloed visualization of the process (Fig. 1), which can lead to ineffective information radiators (Fig. 2), we try to understand the process as collaborative knowledge discovery (Fig. 3) and incorporate its identified dominant activities into our kanban system design (Fig. 4).

Because my last post only presented a recipe for process mapping, the purpose of this one is to present the most important observations, surprises and pitfalls, what was learned from using this approach in practice.

Map the process with as large a group as possible

This is probably the most important bit of advice and it’s an easily avoidable pitfall. The knowledge accumulation chart (such as the example in Fig. 3 with three dominant activities; you are likely to identify anywhere between two and six) looks very simple. But no matter how simple it looks, resist the temptation to draw it alone as a process coach or consultant or manager, or to do it with a small group of people, such as managers or team leads. Invite the largest practically possible number of people actually involved in the work.

What I observed with the groups I coached when we did try to map processes in smaller groups is that those few people would eventually come to dominate the conversations happening on the daily basis in front of the Kanban board. People who were not included in the mapping exercise were less engaged. Inviting them is a very cheap (and therefore, high-return) investment into the health of your evolving process.

Durability instead of “board churn”

I had many opportunities to compare stories of groups who used this approach with those taking a more simplistic approach: “let’s just visualize our work, we kind of know what our process steps are.”

The groups taking the more simplistic approach encountered the following situation much more often. Soon enough after designing their Kanban board, a work item would arrive that would need some variation of the process visualized by the board. It might need more process steps, skip some steps, or sometimes even need a separate swimlane. The group would change their board accordingly, but another work item would arrive soon enough and upset their new board design. Such Kanban boards exhibited evolutionary behaviour, but most of their changes didn’t constitute improvements – they were simply rework of earlier visualizations.

By contrast, the groups using my knowledge discovery process mapping techniques found their boards to be more durable. The changes were less frequent, but there was very little churn as changes mostly resulted from meaningful process improvements.

Short Captions and Collaboration

As groups chose captions for Kanban board columns representing the dominant activities of their processes, they often preferred shorter ones. “Dev” and “Test” were very popular.

Surprisingly, even if the group understood, for example, the code construction phase of their process as a collaborative, cross-functional activity, they preferred to label it simply as “Dev.” Similarly, the collaborative, cross-functional activity of exploratory testing would get labelled simply as “Test.” So, there would be “Dev” and “Test” next to each other on the Kanban board as if there was a functional silo of developers throwing batches of code over the wall to testers.

This observation contains two lessons. First, it is important not to judge groups of people by the looks of their visualizations. “Dev” and “test” next to each other may or may not be functional silos. Two visual boards may look the same, but the respective groups of people may have taken very different paths that to get there. Second, the mapping exercise I described in the previous post and continuing to reflect on in this one, can be used to promote cross-functional collaboration.

Manage work, not the workers

Managing work and not the workers is what we try to do with Kanban and other modern management methods. It is easier to do when the Kanban board columns represent activities and not functional groups.

“Linearized” workflow; easier to limit WIP?

The Kanban systems created by mapping the knowledge discovery process seem to be more linear. A better word is “sequential.” Indeed, since we’re visualizing accumulation of information, it should be sequential, as the information continues to accumulate during the process. It is important to remember that the arrival of this information throughout the process is still accomplished through complex, non-linear activities.

The sequenced order of dominant activities tends to eliminate one problem that people often ask about in training. If we found a problem in the work item at a later phase of the process and need to send it back, do we move the ticket back? For example, if the tester found a bug and needs to send the feature back to the developer, do we move the ticket from “test” to “dev?” (The answer: since the ticket was in “Test”, that means we have already exited the dominant activity of coding, which means our current dominant activity is getting any remaining bugs out before the release, therefore, “Test” is the right place of the ticket, although we might want to place a sticky note on it to indicate blockage.)

Reducing the backflows may also help some groups limit work in process. Tickets that flow back to Kanban board columns already filled to their capacity usually complicate attempts to limit WIP.

The Minimum Viable Process?

One of my workshop participants expressed the need for what she called “the minimum viable process (MVP).” It would be a process definition that doesn’t need a complicated block diagram in Visio, extensive documentation in SharePoint or enforcement by the process improvement office or the logic of application lifecycle management (ALM) software. She wanted the process to fit the brain, perhaps with the help of a few visual aids, not overburden the brain with information, and let her and her colleagues focus on the real work and not on the process.

Knowledge discovery process visualizations with sequences of two to six dominant activities, previously implicit policies turned explicit can be close to meeting such needs.

Integration with STATIK

The process mapping techniques I’ve presented are fully compatible with STATIK (the systems thinking approach to introducing Kanban). After taking the first two steps of STATIK – first, understanding the existing sources of dissatisfaction, and second, the demand analysis, after which we know all work item types – the third step is mapping the process for each work item type. This is where we can use these process mapping techniques. The introduction of the kanban system can then be completed by identifying the classes of service that are provided for each work item type, designing other kanban system elements and rolling the system out.

As the STATIK process tends to be iterative, the coach and the working group may choose to apply it again in the future to refresh the design of their kanban system. When it comes to step three, these process mapping techniques can be applied again.

I have observed that the demand analysis exercise with groups of people working in creative fields often reveals more work item types then people think they have. Each work item type represents some organic connection to either external customers or an internal work group. It is therefore more important to find all work item types than to map the process of any of them more accurately.

Simple, but not simplistic

The process visualization techniques I’ve presented so far are really uncomplicated. But they are grounded in the understanding of groups of people doing some creative work as complex adaptive systems. The simpleness of these techniques comes from appreciating this complexity and finding the few useful heuristics and constraints we need to manage in the Complex domain. This simpleness is not the same as the simplicity of best practices or the simplification of complicated analysis performed by experts.

I plan to explain this thinking in the last post of this series.

Posted in Kanban | Tagged , , , , , | 1 Comment

Mapping Your Process as Collaborative Knowledge Discovery – Part 1 (Recipes)

With this post, I return to the topic of process visualization in creative industries. I wrote previously how we can understand such processes as collaborative discovery and enrichment of knowledge and gave some examples. They key part is the focus on knowledge creation and information arrival through a sequence of collaborative activities rather than work centres, process steps and handoffs. (Additional examples can be found in the posts that followed: here and here.)

Now let’s turn to a different, related problem: how to start with actual existing processes and actually create such maps for using them in visual management systems. For teams and organizations using kanban systems, such visualization would be the visible part of their kanban system. For those evolving their ways with the Kanban method, it would be substantial part of their visualization practice, which is one of the methods’ practices.

In a nutshell, given a knowledge/information accumulation chart like this,

The diagram shows accumulation of knowledge through a sequence of three dominant activities

we could turn it into a Kanban board looking like this:

Kanban system incorporating the same three dominant activities

The method for mapping processes has three important aspects:

  1. What to do, actually, and how – the recipe.
  2. Observations made by actually doing it with groups of people, dos, don’ts, surprises and pitfalls – and we can only learn this by actually doing it.
  3. Rationale behind doing or not doing things a certain way – what we need to understand to be more like chefs and not cooks.

It is also worth noting here, before we proceed, that we have already departed from the notion that a process is a prescribed sequence of steps. There is no block-diagram drawn in Visio and stored in SharePoint. The process is what actually happens and it happens largely through countless daily decisions (mostly irrational decisions) made by fallible human beings. What actually happens is the standard that we want to improve upon.

The simple stuff: what to do and how

To start mapping our process, we need the following information:

  • identify the organizational unit and its boundaries: usually a business unit, team, department or several related teams
  • identify the interfaces and services this groups delivers (to external and internal customers) and its work item types
  • find several examples of recently delivered work items of each type

It is very important to use actual examples. Without them, people can only debate their visions of ideal process, refer to any existing process documentation or argue how the process should be happening. With examples, we can trace what actually happens: various activities and decisions along the way. Three to six items for each work item type is usually enough. People who actually did some work on those items should be in the room. Don’t leave this to the manager, team lead or a process coach.

Large whiteboard, divided into four horizontal lanes; ten sticky notes are lined up on the right-hand side represent ten recently-delivered work items of four different types

The examples should be lined up on the right hand side of a large, empty whiteboard. In this example, we have ten examples of recently delivered work items of four types.

Then every person in the room takes a stack of sticky notes, writes down the activities they performed or the decisions they made leading up to the delivery of each of these specific work items, and places their note on the whiteboard. The focus should be on what knowledge or information was gained as a result of such activities, rather than the mere fact of procedures and meetings taking place. The facilitator should ask the participants to do this one sticky note at a time and place them in the chronological order. We are tracing back what actually happened in the delivery process.

This activity turns out to be complex and social. People do not remember most of what they did, but they tend to activate each others’ memories. For example, a software developer may write a note that they wrote the code for the delivered feature. A tester may then recall they actually tested an incomplete feature, found several bugs in it and provided feedback to the developer. The developer may then recall that the feature was indeed incomplete at that point, that they consulted their colleague and devised some automated checks to prevent occurrence of such bugs, and that there was some coding to do after that. It is through this complex, co-operative game that the visualizations of the existing process’ dominant activities, turning points, collaboration patterns, and explicit policies emerge.

Collaborative mapping of actual activities and decisions in the delivery process.  This is a complex, social process.

As the timelines emerge, the group should start notice similarities between them (within the same work item type, of course). The facilitator should consult with the participants to line up the sticky notes with similar activities. Sometimes, this becomes obvious quickly enough so there is no need to write down every single step for every work item example on a sticky note. The major, dominant activities can then be identified by reading out the timelines and clustering the sticky notes accordingly. As a reminder (this has been described in detail in the earlier post), one major activity dominates knowledge creation at any time, but eventually fades and is replaced with a new dominant activity.

Lined-up timelines for six recently delivered work items of the same type, revealing a sequence of five dominant activities.

In this example, the group reconstructed the timelines of six deliveries of a particular work item type and identified five dominant activities.

Explicit Policies

The results of this workshop can be easily transferred onto the new Kanban board. Each identified dominant activity will be represented by a column. The group should decide how to name each activity – these names become column captions on the physical board. Since there may be multiple work item types and each may have different sets of dominant activities, the Kanban board will in the general case have several swimlanes, each having a somewhat different column structure to reflect those differences.

This workshop also helps reveal the previously implicit policies of the process. Remember, one of the key practices of the Kanban method is to make policies explicit. These can include:

  • definitions of ready
  • definitions of done
  • sequencing or selection policies (some may refer to them as prioritization)
  • input and delivery cadences
  • and so on.

These can be immediately captured and transferred onto the new board.

The workshop typically takes two and a half hours. In my experience, it is best not to rush it, explain it well, facilitate it with good questions, and give people enough time to pick each other’s brains and reveal their process. Only in simple cases, we finished it in less than two hours. But we never took three hours or longer – I suppose the complicatedness of the process is offset by the limited attention span and degree to which people should care about details.

What’s Next

For the sake of keeping this post compact (more than 1000 words, but not much more), I only present recipes here. I plan the next two posts to be about:

  • the dos, don’ts, observations, surprises and pitfalls of mapping creative processes using this method in practice
  • the complex nature of the processes we’re trying to understand, visualize and improve – this is the rationale for doing certain things this way

Stay tuned.

Posted in Kanban | Tagged , , , , , | 2 Comments

The Still Elusive 20% Time

The long-time readers of my blog may remember this old post: The Elusive 20% Time.  It turned out to be quite popular as people revisited it, tweeted it and struck conversations about it for a long time after I posted it.  Its text will soon appear as my contribution to the upcoming book by Lisa Crispin and Janet Gregory, More Agile Testing: Learning Journeys for the Whole Team.  For the new readers, here is the updated text (that will be included in the book), shortened, cleaned up by copyediting and less software-centric.

The topic of 20% time has become popular in creative industries in recent years.  Many have heard of companies that have 20% time or know someone who works there. One example is Google, where engineers spend 80% of their hours working on what the company requires them to do and 20% on their own projects. Or so we have been told.

A shop across town is doing it and now we want to do it too. Those who have tried to introduce 20% time in their workplaces found it surprisingly difficult. So, how can we do it? What are the dos and don’ts?  Is there some theory behind this practice?

The main reason for 20% time is to keep the average capacity utilization at 80% rather than at 100% to build in slack time. We can think of a knowledge-work organization as a system that turns requests into delivered products and services. We can then model its behaviour using queuing theory.


If requests arrive faster than the system can service them, they queue up. When arrivals are slower, the queue size decreases. Because the arrival and service processes are random, the queue size changes randomly with time.  But, on average, the queue size looks like this:

queue size as a function of utilization - rapid rise after 0.8

The average queue size remains low while utilization is up to 0.8, then rises sharply and goes to infinity. We can understand this intuitively by thinking about our computer’s CPU: when its utilization is low, it responds instantly to our inputs, but when a background task pushes its utilization close to 100%, the computer becomes frustratingly slow to respond to every click.


The slack – the gap between the utilized and full capacity — keeps the system responsive.  So, for those who want to have it in their organization, several practical conclusions follow immediately – and they are about what not to do:

  • Cost accounting (engineers’ time costs X, but the company may not be able to afford it). The economic benefit comes from reducing the cost of delay.
  • Setting up a 20% time project proposal submission-review-approval system
  • Tracking the 20% time by filling out timesheets
  • Using innovation as a motivator for the 20% time. While new products have come out of 20% projects, they were not the point. If your company cannot innovate during its core hours, that’s a problem!
  • Relying on the 20% time to encourage creativity. Saying you’ll unleash your creativity with 20% time begs the question why you’re not creative enough already during your core hours.
  • Allocating the 20% time to a Friday every week…

Those are All Don’ts, Where Are the Dos?

OK, what about doing it right? Let’s answer with the best question heard while discussing this subject with practitioners: “If 20% of your capacity is mandated to be filled with non-queue items, then you’ve just shrunk your capacity to 80%, and 80% is your new 100%. Right?” Right, “80 is the new 100″ highlights the main problem with the attempts to mandate the 20% time without understanding the theory. You want to escape the utilization trap, not to stay in the trap and allocate time differently. Utilization depends on two processes: the arrival process (demand) and the service process (capability). You can’t really choose your utilization. It is what it is because the processes are what they are. You can, however, work on the processes by improving your organization’s delivery capability and shaping the demand. As you make progress, slack will emerge.


Posted in big picture | Tagged , , , | Leave a comment

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?


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