My Personal Andon Cord

April 29, 2019

Have you heard of an Andon Cord? On the assembly line it’s that cord you yank on to stop the entire line when a problem is found. The idea is to stop everything until the problem you encountered is fully understood and fixed. That way we take the time to improve the function of the assembly line so that those sorts of problems never slow us down again. It’s a little example of that “slowing down to go faster” that those crusty old software curmudgeons blather on about.

But who listens to those old cranks anyway?

I was thinking about a recent Product Owner training I was running where I was told that the product owners didn’t actually sit anywhere near the team (that was assuming they had a product owner to begin with, but I digress). It turns out that the product owner for a given team was very likely located in another building or even perhaps another state or country altogether! This kind of colocation issue is fundamental to improving a teams performance. Address it and you will see meaningful improvement quite quickly. Fail to address it and you will be wrestling with the side effects and consequences forever without dealing with the underlying problem. 

So what did I do? Well, this was just the start of a two day training, so I had at least a day and a half more of training that I was expected to deliver. So I tossed that issue on the mountain of other issues that I was uncovering and moved on. Trainers gotta train, kids gotta eat. I raised concerns, told the right people, and moved on. Everyone kept moving.

Now in hindsight, I’m not sure if I should be proud of dismissing something that important. However, I know it happens all the time. But it makes me wonder, is there an issue sufficiently important that I would call the whole class to a stop in order to address it? What would cause me to stop the line as a trainer? Where is my trainer Andon cord?

If a fist fight broke out in class, I’d certainly stop the class. So there’s that. But what else? If someone was crying, I’d stop the class. If I found out someone was being hurt, I’d stop the class. But if I found out they were doing something stupid…I wouldn’t necessarily stop the class. I might pause long enough to mention that I wouldn’t recommend doing that. Maybe I’d hand them a Darwin Award (oh, now there’s an idea…). But stop the class? No.

Let’s look at that example of the product owners in a different location than the team. Colocation of product owners or customers is pretty fundamental. You would stop the line if you found out that the car’s tires are missing. If someone told you,”It’s OK, we keep them in another building.” You would probably be well justified in insisting that the tires get brought in pronto. There’s not much point in leaving silliness like that alone. So I’m asking myself, if the customer has paid me a few thousand dollars for the training, but instead of delivering the training, I stop the training to focus on that one problem…what would happen? Fixing that problem could probably mean a huge return on investment for them. Something far beyond the paltry amount they have spent on the training. It’s food for thought. 

On the other hand, typically these types of organizations are not in a place where they are accepting or tolerant of radical change. Usually few if any folks in the room are actually empowered to do anything to change the situation. Furthermore, even the folks who hired me may not have that power. You have to have a lot of credibility in an organization before you can even start talking about that sort of change. Credibility takes time, and that’s something that most trainers don’t have. You’re in, you do the training, and you’re gone. Poof of smoke. Vanished.

So in the big picture it probably depends on your context. If you are just in for a quick one-time training, then you really don’t have the credibility to stop and attack problems like this. On the other hand, if this is part of a long term engagement, then there is the real possibility of being able to deal with problems like this in real time. To be able to pull your Andon cord and stop the line. What a marvelous thought.


Is Improvement really Continuous?

September 4, 2014

DT-09-final-infinity

 

 

 

 

 

 

I don’t want to get on a rant here, but…In the Agile community and perhaps in the IT community in general there is a tendency to use the term “Continuous Improvement” to describe some sort of mythical state where teams are constantly evolving toward some state of perfection. At least that’s what I think of when I hear the term. Now I don’t know about you, but I don’t think I’ve ever seen such a creature in the wild (or even anything close to it). Furthermore, I’m concerned that using such terminology sets an unrealistic expectation for performance with our customers and stakeholders.

As an example, I’ll use myself. Right now, despite a host of good intentions on my part, I am not continuously improving. I’m typing – my spelling and grammar are showing no discernible sign of improvement (as I’m quite sure you, dear reader, are all too painfully aware of). Honestly, I’m just not improving right now. In fact, I haven’t done anything to improve my blog writing since the last time I wrote one a week ago…a month ago…6 months ago…

“But Tom don’t be so hard on yourself!” You say, “Just by writing more you are improving your writing skill and the content of the blog.” To this my answer would be, “So just writing more code is improving too?” We all know the answer to that question. So no, the only thing writing does by itself, is make the number of words on the page grow.

In fact, I have a confession to make. Nothing I plan to do in the next 24 hours has anything with improvement. Not even:

  • Attending meetings (generally the opposite of improvement)
  • Writing status reports (ditto)
  • Cleaning the house (status quo – just fighting entropy is not improvement)
  • Commuting (status quo)
  • Watching TV (gently sliding toward entropic oblivion)
  • Sleeping (mandatory, but not improvement, at best it’s re-establishing the status quo)

You see, true improvement is really hard work, therefore I don’t do it very often. I certainly have never been able to do it “continuously”. Hah! What a ridiculous notion that is! Nobody can improve continuously. We all need to take a break. Taking a break is actually necessary in order to improve! So the very term “continuous improvement” is at best misleading and at worst an idiotic notion. It can’t be done! Combining the terms continuous and improvement is like the old joke about the term military intelligence – it just doesn’t exist!

Up to this point I’ve just been ranting about continuous improvement, but in the Agile community we use the “continuous” word everywhere. There’s continuous integration, continuous delivery, and I’m sure there are a few more I haven’t even thought of. Take any one of those continuous activities and look at it closely enough, and guess what? Not much is happening. I’m willing to bet that your continuous integration server isn’t constantly running builds all the time (at least I hope not). I’m sure the average integration server spends a lot of time just waiting for the next build request. I hope by now it is pretty apparent that very few things are really continuous. I think we need a better term to describe these processes. I would propose: Periodic, Frequent, Event-driven or my personal favorite – on demand.

I know, I really do get it – continuous sounds just better. Continuous has an aspirational sort of quality to it which you can’t help but admire. I think that it’s just a little disingenuous to use that term for things that may not even take place for an hour or even a day at a time. If improvement is really continuous in nature, I want to see evidence of improvement taking place as I’m watching, when my back is turned, on weekends, and perhaps even when visiting the bathroom. Is that too high a bar to set? I don’t think so. I make that demand of my lowly alarm clock. I’m not saying improvement doesn’t take place. It happens – for some of us it happens pretty frequently. For others, it happens on demand at the end of the sprint.

Improvement may be a never-ending quest, but it is rarely, if ever, continuous.


Culture Eats Impediments Too

March 3, 2014

hippo

I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.

Some signs you may have a problem introducing a change:

  • Taking action requires getting permission (this is straight from Pawel)
  • Action can’t be taken because projects are too important to risk
  • Only certain people can take action

I have a great example of this happening recently: The group I was with raised an impediment. I had a nifty new impediment display that I wanted to try out (impediments displayed on a big monitor that everyone in the company could see). I sat down to add the impediment to the list, and then I had to pause…because the impediment called out something that might upset some folks. It might REALLY upset some people. I ended up not displaying that impediment. Why not? Was I just a chump? Was I too scared to make an impediment visible? Maybe…

Or perhaps I understood the culture well enough to know that certain things were acceptable to display as impediments, and others weren’t. That’s just the way it works at some places.

The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.

 


Punctuated Disequilibrium

August 22, 2011

I’ve heard people talk about the gradual gains that agile teams make over time as they engage with continuous improvement, but I’m here to tell you that isn’t what I see in the real world. I guess the expectation (perhaps my own included) is that when teams start to improve they will make many small changes over time and reap corresponding gains in performance. You know, a little change here, a little gain there. I guess I envision it looking a little like this:

However, I see something different. What I’m witnessing with the teams that I work with appears nothing like that. Instead the teams seem go for long periods with no evident change in performance or productivity. They just seem to trundle right along and then BANG! You see a dramatic improvement. It sort of looks like this:

The team is trying out different things the whole time. They’re failing at some things and succeeding at others. They are continuously playing with the chemistry set we call Agile Development. From the outside you don’t see much happening. Sometimes for long stretches of time – we’re talking years here. The point is that my experience is that often, it’s a combination of many things that leads to significant performance gains by a team. Finding that combination of what works can take a while. But when it does happen, it is reflected in a rather dramatic improvement in performance. It’s not a slow gradual change.

Of course there is a flip side to this change. Here’s another example:

Some teams that I’ve worked with have made great gains and then “jumped off the cliff.” What goes up can come down. I call this “Tom’s First Law of Team Performance”. Just as there is sudden improvement, there can be an equally sudden decrease in performance. Team’s can make a change that kills performance just as easily as they make a change that improves it. I’ve seen it work both ways. Sometimes it is change outside the team, within the corporate culture at large that causes these radical swings in performance. Software teams work in a complex ecosystem. When change happens, I think it tends to either be suppressed by the system or, when the conditions are just right, lead to dramatic changes in performance.


Exploring The Project Jungle

January 14, 2010

Grab your pith helmet and join me for a little journey. Shhhh! Be vawy, vawy quiiiet, we’re hunting for projects! We move through the jungle with exaggerated stealth, placing each booted foot with care. We stop before a bank of thick fronds and I gently part them. On the other side lurks a horrifying creature: a man sitting alone at his desk staring intently at a monitor. I stifle a scream.

Our programmer (Mr. Livingstone I presume?) is obviously engrossed in something interesting. Every once in a while he starts typing furiously, keys clattering at an astounding rate – and then he stops. This pattern repeats itself over and over. You look around at his environment: his desk is clean, his walls have a few quick reference cards taped to them. Maybe a picture of the kids. Just your standard programmer – usually found in isolation, seldom socializing, and rarely breeding.

But wait! If we look a little closer some interesting details are revealed: it turns out that he has an IM client open on the monitor. He’s actually collaborating with someone! Furthermore there is a row of telltale lights in his task bar that keep him informed of the status of all of his continuous integration builds. Wow! This guy has a lot more going on than is revealed at first blush. I wonder what else is going on here…This is obviously a workspace that is oriented around the electronic screen. That’s natural enough in the software business. What about the wall space, why isn’t that space being used more?

I love sneaking about the office and looking at what other teams are doing.  You can find the most amazing things. Teams using different techniques, alternate presentation of the same material, etc. There is a rich supply of ideas lurking in those other teams. Go ahead, steal one of their trash cans and rifle through it. What are they doing that you might benefit from trying out? I’m not talking about espionage here…OK, maybe I am. The point is, there are a lot of things we can learn from the other teams that we work with.

What can be a lot of fun is to take others along on the hunt with you. Get the team together as a group and act as their guide. Don’t forget to get them hats too.  Sneak up on other teams and observe where they live and how they behave. When I do this, we debrief together after observing each group. The debrief is an opportunity to ask some great questions:

  1. What did you see?
  2. What did you hear?
  3. How is it different from where we work?
  4. What do you like/dislike?
  5. What can we steal?

Each of these questions can serve to bring up some great conversations about how you work together as a team. Then you can follow up by returning to your own work area at the end. Don’t just pile back into the office though – take a moment to observe your own work area. What does it say about you as a team? Usually at this point the team is primed to re-evaluate the way they work, the way their area is organized, etc.

So have a little fun and try out becoming a Project Anthropologist. It’s a fun and gentle way to open up the conversation regarding how the team works and how it is organized. And you get to spy on your co-workers. What could be better?


Standard Work for Personal Improvement

August 16, 2009

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


Continuous Improvement & Risk

July 1, 2009

I witnessed an interesting pattern today while running Boris Gloger’s “The Ball Game” exercise with a team. The basic idea is to iterate a team activity, stopping to make improvements each iteration. The idea is to practice and measure the impact of continuous improvement on team performance of a task. In general, the team did as you might expect: the first iteration things were pretty rough and their performance wasn’t very good. In subsequent iterations, their performance continued to steadily improve until they were nearly perfect at peforming the task.

Here is what I think I saw happening: with each iteration the group became more stable. They eliminated variation until they reached a plateau in their performance. They found stability, but they also reached a plateau where they were not making significant additional gains with each iteration. It felt very much like they were playing it safe. They didn’t want to do anyting to risk their “score” each iteration of the game.

Now I knew something that they didn’t – as facilitator I knew about other rather creative ways of configuring the group that would have given them a quantum leap in performance. There was an opportunity to take a chance and rethink the problem and make some stunning gains in performance – but at a very real risk to their short term performance. What I saw was a group that was tweaking the small stuff and missing the opportunity to change the big things that would make dramatic differences performance. It felt like there were competing pressures that were impeding the teams ability to see opportunities for performance improvements. Now of course this was just an exercise, so there really was no risk if they didn’t perform well – so any pressure they were putting on themselves was basically self imposed. And that may have been enough to blind them from seeing the opportunity for greater change.

How often do we do this on our own teams? We make improvements that fine tune the status-quo until it feels reasonably stable – and then we stop. I know it happens to me. Add a little pressure from management, and I very quickly can’t discern the forest from the trees any longer. There may be opportunities for change that offer dramatic improvements, but I will very likely not even consider them if it means potentially risking my team’s established performance.

I think this is all the more reason to focus on making the team feel “safe”. As managers we sometimes need to protect our teams external pressures so that they can keep relaxed and flexible – open minded enough to see all the possible alternatives.

Or I could be nuts. You decide.