The Fractal Beauty of Process

There is something about a well designed process that I find mesmerizing. It really doesn’t matter if it’s XP, Scrum, Lean, or Kanban the end result is the same: for some brief period I find myself seeing the patterns of the process everywhere I look. For example, a few months ago I finished reading yet another book on Lean (Poppendieck’s latest or something like that). There I was in the kitchen washing the dishes after dinner and wondering…

…why I always did the dishes in such large batches?

…and what would happen to our dish throughput if everyone washed their own dishes? Is that one piece flow?

…and would my family understand the benefits that would accrue from such a change? Would an experiment back this up?

…should I use a kanban board to reflect my weekly dishwashing progress?’

And so it goes. Sometimes it’s like a fever. Process Geekitus. I guess for some folks a process has the allure of helping to explain how the world should work. That’s a pretty seductive proposition when you stop and think about it. What’s wrong with being passionate about your work? Nothing! I can think of some great examples:

1. Personal Kanban
2. GTD (Getting things Done)

These are examples of processes that people have incorporated into their day to day lives. They’ve managed to take a process that works for groups and make it work for individuals or vice versa. I’ve seen it done both ways and I find it equally compelling. Patterns within patterns. It’s really rather lovely.

How Others See Us Is Important Too

I was having a conversation once with an executive sponsor who was frustrated by friction between competing organizational silos. One silo adopted Agile, the other stuck with more traditional plan driven development. Each side mocked the other’s “head in the clouds” or “lost in the past” approach to projects.

When I was asked what I thought about the situation I found myself saying something along these lines,

“We (the Agile teams) have become very good at being open and collaborative with each other. We have created these marvelous cross-functional teams and have done a great job of breaking down the walls that used to exist between team members. From an insiders perspective on any given team we have made dramatic improvements to the way we work.”

“However, from the outside we don’t look that much different. In fact from the outside, we still react with hostility when provoked and we don’t offer much transparency into our work beyond using a handful of project tracking tools. It’s just not enough. I have high expectations of an Agile development team. I believe that an outsider who works with an Agile development team should come away from the experience feeling like they were welcomed, informed, and energized. I want a team using plan-driven methods to welcome an Agile team, because they will be that much more likely to succeed. The experience will be one of openness and a general willingness to work together.”

“But that’s not often what we get. Instead we get fear, hostility and resentment on both sides. Some of that is human nature. Some of that is silos. And some of that is because we focus too much on the process. I think we should leave the process out of it. Working on a project is a chance to make friends and meet new people.”

“What I need are people who are friendly, open and honest. People who smile when I walk into the room. People I can crack jokes with. If I lead with friendship, I can make more ground than if I lecture them on Agile practices. People should feel at ease when they work with my teams. They should know that they are safe.”

At this point in the conversation I was:

1. out of my chair
2. pacing the room
3. and gesticulating wildly

The first two meant I was feeling emotional, the last one meant I was talking. I was surprised at the heat of my own passion on the topic. In writing it down, it even sounds naive. But here’s the thing: I’ve worked with enough Agile teams to know that they can be real jerks to outsiders…and that is a shame. I would have hoped that all of that vaunted openness and transparency would make that go away, but it doesn’t.

If Agile in whatever form is ultimately to be successful, then both people inside and outside the team need to feel safe and respected. If you are starting a new team, please realize that getting things working smoothly within the team is critical, but don’t forget to look at how your team interacts with others to – in many ways it’s just as important to the success of your team – perhaps even more so.

Silo Busting Strategy #2: Attend, Befriend, Defend

There is a simple slogan that we can use when trying to approach groups in silos: attend, befriend, and defend. The idea works like this:

Attend

The first thing that we need to do is make ourselves available to the group as much as we can. We need to show up for the team meetings or events. In lean terms, you might think of it as going to the gemba. You need to be where the action is. This may involve getting yourself invited to meetings, usually the most boring and uninteresting meetings. You take anything you can get. Then you have to be there all the time, religiously. They have to come to believe that you are genuinely interested and part of their process.

Befriend

Once you have the attendance part down, then it is time to make a few friends. You need to be that smiling face in the room that is ready and willing to help with even the most inconsequential problems. In fact, beginning with the small problems is probably the best way to start. We need to be there to offer help, and then when the offer is accepted, deliver. This is really all about building up trust with the new group. It is just trust with only you, but you have to start somewhere. You do everything you can to build that relationship. Go out for a beer, Invite them to your team meetings, join the softball team. Do whatever it takes.

Defend

Finally, it is inevitable that they are facing challenges; this is where you can really make a difference. When the opportunity arises, be there to defend the group. Make sure that you radiate the fact that you trust and support the work the group does. Not only does this serve to cement the trust you are trying to build within the group, but it also informs the rest of the organization that you are working together and share common goals.

 

Personal Value Stream Mapping

As a project manager, a scrum master, a team lead, or even as an agile coach I’ve wondered from time to time about the true value that I bring to a team. You see, to me it is entirely plausible that a team could work just fine without any of the aforementioned roles being present. In fact, I know that there are many teams that are quite successful without a project manager on the team. That goes for scrum masters too. It has always been a difficult question to face with any intellectual honesty.

Recently I picked up Mary and Tom Poppendieck’s latest book, Leading Lean Software Development. She uses frames to illustrate some of the successful and unsuccessful approaches to software development over the last 40 years. She deals rather harshly with what she calls the Project Management Frame. Basically, if you accept their take on modern project management it is wrong-headed on a number of different levels and is the source of a great deal of waste and very little value in the overall business value stream. Speaking as someone who basically operates in this role, it’s a pretty harsh toke. Having spoken with her about it, I get the impression that when she talks about project management, she doesn’t make any distinction between scrum masters, XP coaches, or traditional project managers. They are all separated from the work and using “management” to manipulate or measure the teams with metrics that at best serve no useful purpose and at worst cause a great deal of harm. Now I know there are those who might argue these points vociferously, but Mary and Tom are pretty darn smart, so I think there is some merit in considering their viewpoint seriously.

What value do project managers provide to the business value stream? Please note that I’m using the term project manager very loosely. It includes Scrum Masters and other leaders of that ilk. Well, perhaps the best way to answer that question would be to build your own personal value stream map. Take a recent project and see if you can list all of the activities that you engaged in as part of delivering that project. Line ‘em up in chronological order, identify the wait steps and the queues and see what your personal efficiency, from the perspective of the team value stream is. It might look something like this:

1. Release Planning
2. Sprint Planning
3. Daily Standups
4. Retrospectives
5. Reviews/Demos
6. Resolving Impediments
7. Release Coordination
8. Change Control
9. Tracking (taskboard, etc.)

So…if I look at that list, what activities are value adding from the customer’s perspective? Oooh, that might be a pretty short list:

1. Reviews/Demos
2. Resolving Impediments
3. Release Coordination

All the other stuff is just “process” overhead without any intrinsic value. That leaves a pretty darn short list. Facilitating reviews/demos is certainly not much of a unique skill. You can do that without a PM. Easy. How about resolving impediments? Well, that sort of depends on how many you resolve…and even then, resolving impediments is not the exclusive domain of the PM/Scrum Master. Finally, there is only release coordination. Some people do that, others don’t – it depends on the organization. And does release coordination represent value to the customer? Would they pay for it? Maybe…

Perhaps that’s a brutal assessment of the value of a team leader. I tend to be that way. Others may be more forgiving. What it tells me is that, at least in my case, if I’m not eliminating a LOT of impediments, I’m probably not contributing much direct value to the team. They really don’t need me for those other activities. It’s the impediment removing that represents the real value. And you don’t need a PMI certification to remove impediments…or a CSM certification…or a title…

Interesting.

The Heart of Business

I stumbled across a great quote from Dan Roam,

“The heart of business is problem solving.”

This is a great phrase. Why did he use the words he did? Take “heart” for example: it could refer to the central nature of problem solving – it is at the core of what we do in business. But when I see the word heart other associations arise for me. To me, heart refers to a sense of passion about something. It speaks to something that I love. Problem solving is a passion that we pursue – something that we love to do.

It reminds me of another great quote from Ken Schwaber,

“Work can and should be an ennobling experience.”

I remember the first time I saw that quote – it blew me away. How can work possibly be ennobling? I’m sure there are many ways, but here’s one for your consideration: work can be ennobling if we are allowed to pursue our passion for problem solving.

I’ll take it even one step further – I pursue my passion for resolving impediments. Isn’t that what you want in project leadership? Take your favorite methodology and rephrase it in those terms and see if it fits:

1. The heart of scrum is resolving impediments
2. The heart of kanban is eliminating waste
3. The heart of XP is solving the customers problem

It really doesn’t matter which project methodology/framework you choose, just follow your heart.

When ToDo, In-Progress, and Done Aren’t Good Enough

On a task board there are two places that we can capture additional detail regarding the tasks we are working on:

1. In the tasks and stories
2. In the categories that we use to organize the tasks and stories

The common starting point for categories on a task board are: ToDo, In-Progress, and Done. Obviously this works for the great majority of cases because the categories are so vague. It’s the starting point for most teams that are using a task board for the first time. However it isn’t long before we discover that some things don’t fit this model well. For instance many tasks commonly take place in multiple ordered steps. Look around you, it happens all the time. Trying to capture tasks that have more than three steps to them on a task board starts to feel awkward. People start to ask if there should be another column on the board. The answer is probably yes.

You see, if you resist and decide not to track additional legitimate state for a task, then in essence you are keeping that information invisible. State is important. Hidden state violates the principle of transparency that we are trying to promote on agile projects. So you need to find a way to represent it on your board. There are lots of mechanisms to reflect additional state on a task board:

1. Add new swim lanes
2. Use color on the task/story cards
3. Use labels or stickies on the task/story cards
4. Additional text on the card
5. Additional task cards

All of these techniques will provide additional state information to your task board. A common symptom of a board that isn’t conveying enough state information is when the stories tend to get “stuck” under the In-Progress category for long periods of time. Now there are lots of reasons this can happen, but one reason the task/story may not be moving is because you don’t have an adequate way to express the state of the progress being made on the work. The developer may be making lots of progress, but none of it is reflected in the task board. When this happens, you need to consider that perhaps the board is not displaying information that would make the progress visible.

I was reminded of this today when looking at a team’s task board. Stuff was sitting in the In-Progress” category for too long. However I knew that the team was making great progress. So they weren’t lazy. And they were keeping the board up to date. So what was the problem? There wasn’t enough information on the board to properly reflect the work that the team was doing. As a result, there were impediments that we couldn’t even recognize because we didn’t have any way of showing progress on the hidden states. Being blocked on “In-Progress” is not very informative. Being blocked on the “certification request” is much more explicit.

So the next time that the team seems like they are stalled with their task board, consider changing the way the information is presented. Adding a few new categories could help the team identify some of the hidden issues that are currently blocking them.

What I Learned From My Daughter’s First Grade Classroom

The new school year is beginning and my daughter is starting first grade. I had an opportunity to go to her elementary school open house the other day. A word to the wise: never let an Agile development geek into a first grade classroom. I thought I had died and gone to information heaven. I took a camera with me and took some pictures of the kinds of information that they put on the walls in a children’s classroom. It was amazing! In the meantime, my wife fervently denied that she was with the dork taking all the pictures of the walls. Here’s what I discovered before I was escorted from the building:

The first grade classroom is the prototype for a learning environment. These folks are the undisputed masters of the information radiator.  Everywhere you look there is information being displayed. The variety of different kinds of information displayed is amazing! The density of information here is incredible! In one corner of the room I see the following information:

• Monthly calendar
• Weather graph
• Password(???)
• The alphabet
• A tally of how many days they’ve been in school
• Numbers from 1-10
• Days of the week
• A chart of all numbers from 1-200
• A list of who has lost a tooth (Try that on your team! If the number is greater than five, you may be working in a biker bar)
• And a few other things I can’t quite interpret

What else can we see going on here? Well for one thing, there is LOTS of color. It catches the eye, calls attention to certain details, and livens things up quite a bit. It’s like an interior decorator went nuts in the place. Next, you may observe that much of the information is presented using multiple modalities. Multiple modalities? OK, they use pictures AND words AND color AND shapes. A lot of effort is being made to transmit information in a variety of different ways. Now, just for giggles, what if you were going to put together this exact same board for your team at the office? What would it contain? Here’s how I might do it:

• Monthly calendar – team vacations, releases, events, barbecues
• Release graph – How many releases per week are we doing?
• Word of the day (“Spurtle” – yeah, it’s a word)
• A quick reference containing all of the major Ruby commands (pick your API/Language, etc)
• A tally of how many days they’ve been working on a project/sprint/release
• Numbers from 1, 0 (hey, it’s computer science, you only need two numbers!)
• List of major business holidays (they always sneak up on me)
• A chart of all error codes used in our project
• A ladder of World of Warcraft names/rankings

Hmmm. That’s actually not a bad list. Give it a little color, play with the “modalities” and I just might have some pretty compelling information there. I wonder what else the first graders have to teach us? How about this:

I see at least three things here that I could try out with my team back at the office. First, there is information about today: we have the date, and then  below it is the day’s schedule. Now, I don’t know about you, but back at the office, I don’t have anything like a daily schedule posted on the wall with my team. We all have outlook, and perhaps some would say that’s enough, but for me it’s not quite the same. Outlook reflects MY schedule, not the team’s schedule. And there are significant team events that could use some advertising: Planning meetings, releases, retrospectives, reviews, scrum of scrums, and so on. I know that where I work, everyone is left to their own devices to manage these things and show up or not. Nothing wrong with that, but what if we had a daily schedule, a reminder if you will, that sat next to our task board at our standup meeting? Frankly, I think it might be useful. As a scrum master, it might be a way for me to rather subtly remind the team of the big commitments for the day. Or not.

Let’s move on from the schedule stuff. What’s up with the bottles of ketchup, mayo, and mustard? OK, it may be a little cheesy, but if you look at the image closely you will see that these are clever little symbols for “Catch-Up”, “May Do”, and “Must Do’s”. Do you track Catch-Up work on your team? No? Me either…wait a second…we do keep a list of technical debt. Isn’t technical debt a kind of  Catch up work? So keeping that list of catch up items makes a lot of sense to me. Also, the “May Do’s” and “Must Do’s” make a lot of sense to me as well. I think that defining work as “Must Do” will help the team prioritize the work that is most important (assuming you don’t abuse it) and the “May Do’s” gives the team the ability to identify the things that are available to be pulled on their own initiative. Adding may do and must do to a team’s daily activities would certainly be interesting to try out. I can see pros and cons to doing it. Maybe we could even use these criteria to categorize our backlogs? It’s a possibility…

How about the noise level trumpet off in the corner there? In the wonderful Agile Open Space that you work in, do you ever have issues with noise? Here is your answer! I wonder how well that actually works in a room full of first graders? OK, I’m not going to give them grief for this – it’s probably an experiment.

Here’s another gem that I captured before being chased out of the room by a rather menacing looking old battle axe with a broom (where DO they get these people?):

Would you look at that! They use the “Fist of Five” in first grade too! I was wondering where that technique came from! I need a copy of this poster for my team!

Ooh! Look here! They are graphing their moods over time! Cool! I’ve seen other teams do this, but I’ve never tried it myself. It seems like an idea with some real merit. It certainly makes sense to track the teams mood. It would be very interesting to review information like this at team retrospectives. It would certainly provide an interesting metric to compare against recent “improvements” or other team experiments. One other thing I want to point out here: these teachers seem to think that these information radiators are so important that they will try and cram them just about anywhere! Anyplace is game: the backside of a bookshelf, the side of a locker, the face of a cabinet – any place they will fit. Look around your office. Are you using all the space you have available?

Here’s a quick challenge: So what do you think this is?

Well, as my daughter ever-so-patiently explained to me, this is their “Job Wall”. I like the beehive image – after all we Agilista’s like to “swarm” don’t we? It seems that everyone has regular tasks that they are responsible for. These are tracked here. I like the way it makes responsibilities explicit for everyone involved. It makes me wonder where the teachers get all this stuff? Of course if I were to show up with this silly little beehive, I’m pretty sure that the team would laugh me out of the room. Of course that never stopped me in the past…

You know, if they ever  lift the restraining order and let me back on school property again, I’m definitely going to take some more pictures of the classroom walls. How come more offices don’t look like this? Why aren’t the environments we work in as information rich as the ones that children work and play in? I presume that in the office we are learning too, right?

Using Lean Techniques to Improve Your Presentations

I’ve found myself applying lean techniques to some of my writing and presentations. Here are a few of the techniques I’ve used:

1. Splitting large things up into small batches: This one is a beauty. Queue theory tells us that when processing work, lots of small batches are easier to process than a smaller number of large batches. All too often in my writing and in my presentations I tend to unconsciously go into “Large Batch” mode – the document gets larger and larger and I start to lose the tight cohesiveness that you would find in a smaller document. As the presentation or the paper gets larger and larger, I find it increasingly difficult to keep my focus, and it is harder to keep the quality high. So I break my presentations down into separate “modules” – groups of slides with a common theme and work on them in relative isolation (I break out each one as a separate slide deck, then merge them later). The same principle applies to writing. I break the document down into individual paragraphs and treat each one as an independent deliverable.
2. Applying the “5 Whys”. If you know me, then you know I tend to be the kind of person who is most comfortable talking about the big picture. Often I find it difficult or tiresome to dig down into the myriad supporting details needed to support the argument that I’m trying to make. This is where the “5 whys” come in. I look at the problem I’m trying to solve and ask myself, “Why is that a problem?” Usually one or more underlying issues are at play and they are often revealed by asking this question. But I’m not done, so I repeat the process, you guessed it – 5 times. The idea is to drive down to the root cause of the problem. Using the “5 whys” technique helps me to constructively drill down to the important details that I need to bring to the attention of my audience. It’s also useful for irritating the crap out of people.
3. Applying 5S. 5S stands for:
   1. Shine – go through your document or your presentation and make sure that it is clean. By clean I mean that not a single excess word is present, every concept is clear, every image is well presented, every paragraph aligned – you get the idea.
   2. Sort – make sure that all of your slides are in the right order. Insure that the concepts flow smoothly from one to another. Everything needs to be in its place.
   3. Standardize – Use a common theme or style that ties the whole thing together. It may be the corporate logo on every page, it may be some document standard (IEEE).
   4. Systematize – Make building this document into a process. It may be something that you iterate over time and time again. Even a simple process will allow you to see opportunities for improvement.
   5. Sustain – Schedule your time for working on the document. Make sure that you regularly take time to improve the process you are using and check your work

So there you have it – a complete system for lean document development!

Standard Work for Personal Improvement

Standard work is a notion from the lean manufacturing world that refers to having some sort of pre-defined standard way of doing things for a given activity or process. Actually, in the lean lexicon there is an awful lot related to standard work. Perhaps the most concise definition I’ve seen is this:

“Standardized Work is an agreed upon set of work procedures that establish the best method and sequences for each process. It defines the interaction of people using processes to produce a product. It is centered around human movements, it outlines efficient, safe work methods and helps eliminatemuda/waste.”

- cited from The no-nonsense guide to Standard Work

It can be as simple as simply documenting the work that is already done. It can also be used as part of a continuous improvement effort (you have to have a standard process so that you can measure the impact of changes). In much of the literature that I have read, the typical examples of standard work are taken from processes from the floor of a manufacturing plant. It seems pretty easy to define all the steps in a process when all you are doing is processing widgets. Compare that sort of work to the kind of work that is typically done by your average knowledge worker. Naively, they seem as though the two contexts are worlds apart.

For example a worker in a factory may do the same thing over and over again all day long. On the other hand, a knowledge worker never does the same thing twice – and certainly never the same way. Consider also that a typical factory worker works on a fairly rigid schedule that does not admit to many interruptions. The knowledge worker by comparison is sometimes referred to as “interrupt driven”, often suffering a non-stop stream of interruptions and changes in focus (depending on your situation of course). So how is it that we can apply the same sort of techniques for standard work to the knowledge worker that we would apply to the factory worker?

There was an interesting article over on InfoQ, Lean ‘Standard Work’ Applied to Software Development, that outlined some of the issues in trying to understand what it really means to apply the concept of standard work to knowledge work (or more specifically to software development). A few things become clear from this discussion:

1. There are different ways or levels of understanding how standard work can be applied to knowledge work. For example: scheduling, task completion, process performance, coding standards, etc.
2. Some would even assert (I believe incorrectly) that standard work does not exist in Agile software development.

I might even argue that in order to really understand how standard work can be applied to software development we have to take it down to the individual level. The question becomes: Where can each of us find standard work in our everyday lives? Here are some ideas:

1. The daily schedule – imagine standardizing your daily calendar in outlook. I saw an amazing version of this in a presentation done at the LEI lean conference by the folks at Group Health.
2. Meeting management – a well run meeting can be run according to a standardized structure. In fact that’s what a lot of management books are all about.
3. Quality checklists/templates – what are the criteria that we use to assess the quality of the work we have done?
4. To do lists/chores – what are the things I need to accomplish each day?

As you can see there are an awful lot of opportunities for standardization in a person’s day. Right now I’m playing with these ideas. This standard work stuff seems to border on time management (Stephen Covey, David Allen) as well as with Lean, and other process management methodologies. Exploring this sort of thing, especially at the individual level is a form of self-experimentation that can be very valuable. It can help reveal the principles behind these concepts in ways that our deeply meaningful to us in personal ways. It is through discovering that deeper meaning behind many of these principles that makes each of us better at bringing these concepts to bear in a work context. So I’m going to continue to play with this stuff, and if it interests you I would encourage you to do the same thing. You might find a lot of standard work lurking in your life.

Day 1 of Agile Roots Conference

This conference has an awesome speaker lineup for its relatively small size (~200). It’s really great! Great first day. Lots of notes. I’ll have to take some time to try and synthesize some of it and share. My presentation is tomorrow, so I’d better get my beauty sleep!