Punctuated Disequilibrium

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

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

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.

Continuous Improvement & Risk

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.

Managing Impediments

 

 

 

 

 

As many have already pointed out, identifying, tracking, and resolving impediments are some of the most important things you can do for your team. The question that naturally arises is, “How?” In my experience both observing and working with teams, often impediments are jotted down during the daily stand up on a post-it note or listed on a whiteboard. There is nothing wrong with those techniques if the impediments are addressed in a timely fashion. However, if we really have our act together we can do a lot better than these relatively crude techniques. Impediments play an important role throughout the entire scrum process and I think this is under appreciated by many practitioners. 

I would break down impediment management into the following areas: Process, Tracking, Scaling, and Roles. In each case we can explore how impediments are managed and examine how this benefits the team.

In most texts that describe how scrum works impediments are given pretty short shrift. Impements are described as being captured during the daily standup and then they are to be resolved by the scrum master. There really isn’t much additional attention given to the topic: identify the problem and then magically resolve it. End of story. However in practice, impediments play a much more pervasive role in the development lifecycle and they need to be managed accordingly at different stages in the process.

It turns out that impediments have different lifespans. Some impediments are very transitory and are dealt with or resolve themselves very rapidly. Other impediments, especially those that are related to the culture of an organization are much more persistent and can require substancial time and effort to resolve. It would be convenient if impediments were all resolved the same day that they were found – and that is certainly the goal to strive for (as suggested by Jeff Sutherland). However, my experience is that in practice impediments can take some time to resolve, no matter how dedicated the scrum master may be. This is especially the case in organizations that are just adopting Agile.

Process

So given that impediments are in different stages of resolution (and different severities) it makes sense that we track them throughout the scrum sprint cycle. Let’s start in the middle where we are most accustomed to finding impediments – the daily standup.

Every day the team is required to get together for 15 minutes and answer three key questions:

1. What did you do yesterday?
2. What are you going to do today?
3. What is holding you up?

Of course it is the third question that leads us to the impediments. We need to make a note of these impediments as the team does the standup. Then after the standup we can get together with the affected parties and gather more details about the impediment. Hopefully your team will provide you with impediments. The standup is the primary source of new impediments in the process. However this is just the beginning as far as tracking is concerned.

So we go through our sprint, and we get to our review with the product owner. We can demonstrate our small unit of “potentially shippable product” and gather their feedback. However there is an additional opportunity in this meeting to share the impediments that the team overcame in delivering that product (or realistically, in perhaps not delivering that product). Sometimes the team has to jump through some pretty amazing flaming hoops to deliver the product – the product owner might want to know about these things. Why? First, it will help to set their expectations in the future if they understand the kinds of challenges that the team faces. Second, the product owner is an important ally of the team and may be able to help the team out with resolving those impediments. We should take advantage of that potential. Being transparent means sharing all of the struggles that the team encountered in delivering the product.

Next we go into the retrospective as a team and review our own performance over the previous sprint. What went well, what needs improvement, kudos, and so forth. This is an opportunity to review the list of impediments and the progress that the team made in resolving those impediments – I see this as an important measure of the teams ability to overcome challenges. The retrospective is an ideal place to check in on this performance. Are there impediments that are consistently not getting addressed? Why not? What can the team do about it? We can use the lessons learned from the impediments that we encountered in this sprint to modify the way we act in the next sprint.

So we wrap up the sprint and we take the weekend off. We come back on Monday ready and fired up to start a new sprint and we go into the sprint planning meeting. Impediments can play an important role in the planning meeting too. When the team is reviewing the stories in the product backlog, they will find impediments that prevent a story from being worked on in the current sprint (often the impediment is that the story is not well understood yet). These impediments are important for the team to track as well. The other opportunity we have in the planning meeting is to put in place plans for actions that we believe will help us address or avoid impediments in the upcoming sprint. Sometimes simply avoiding impediments is just as important as recording them after they have hit.

So as you can see, impediment tracking really is pervasive throughout all of the scrum lifecycle. There is real value in making sure that impediments are considered along every step of the process, not just the daily standup.

Treating “Impedimentia”

Why is it so hard to come up with impediments sometimes? I know that impediments are all around me – literally everywhere I look. So why is it that when we do the daily standup and answer the three questions, nobody seems to have any impediments? Obviously the team is having the same problem that I am. I can’t blame them, sometimes impediments are hard to find.

I’ve heard all sorts of explanations for why no impediments come up in the standup.
“Everything is fine.”
“We’ve tackled all the big impediments.”
“We just don’t have any – we’re good!”
I don’t buy any of these answers. You shouldn’t either. I have a few theories to explain why impediments are so hard to discern. It has to do with context, perspective, aclimatization and complacency.

Missing Context
Sometimes we need to have some sort of target to shoot for so that we can recognize our impediments. If I go the to the gun range and use a blank sheet of paper for a target, it will be very hard to tell how accurately I’m shooting. The shots may be grouped well (precision), but it would be hard to tell if they were going to hit what I was aiming for (accuracy). If I paint a bullseye on the target, now I have enough contextual information to judge the accuracy of my shots. So it goes with impediments. We need a metaphorical target that we can compare our objectives to in order to see their impediments.
What would be the equivalent of a target for a set of user stories. It might be a detailed set of task cards associated with those stories. After all, if there are no task details then it’s hard to know if you are blocked on a given issue or not.

Perspective
Maybe we are just looking at things wrong. Perhaps we need to change the way we view the objectives we are trying to achieve. Maybe we should take the advice of Matthew May in “The Elegant Solution”. Instead of asking, “What can we improve?” Perhaps we should be asking “What is blocking perfection?”
To me, the thing that alters my perspective the most is when I’m being a perfectionist. I’ll admit that perfectionism is a distorted perpective, but it can be very useful when we are seeking impediments. When I am in perfectionist mode, I am very sensitive to anything that doesn’t go exactly right.

Acclimatization
Another factor that helps make finding impediments difficult is the fact that we just get used to having them around. It’s kind of like the proverbial frog in a pot of hot water. You know how it goes – the water gets hotter and hotter until the poor frog gets cooked. So to there are a lot of little irritants that get in our way, but for some reason we take them for granted. It’s just how “things are done” We get so used to jumping through the flaming hoops that we stop seeing them entirely. How could it possibly be done any different? Sometimes it takes the perspective of an outsider to help identify these sorts of impediments. Bring someone else into your team for a day. Pay attention when they say, “Why all the flaming hoops?”

Complacency
Is it possible that we just stop caring about things like impediments? Are we just lazy? I’ll answer that: yes, sometimes. As much as I might like to maintain otherwise, I do have days where seeking out impediments to my projects is not at the top of my priority list. I’ve also seen the case where teams neglected to address the impediments that they did find. Not fixing impediments is the quickest way that I can think of to discourage a team from identifying them. Why bother?
There are probably a lot more reasons why impediments are hard to see, but these strike me as the biggest in the bunch. They give us important clues as to how we might start to address our own collective “impedimentia” by taking action to address these issues.

Classifying Impediments

 

 

 

 

Categorizing things can be a very useful tool for understanding the world around us. I watch my 2 year old daughter doing it all the time. She points at a robin in a tree and chirps, “Birdy!” Then she sees an eagle in a book, points and says, “Birdy!” I guess Homo sapiens must be pretty good at drawing these kinds of associations, because it’s apparent that we start doing it at a very early age. We use categorization to discriminate the different things we encounter in the world.

Recently I have been trying to look at impediments with “new” eyes. If you keep an impediments log you can see patterns arise and common themes become apparent as you review impediments with similar causes. When I first started tracking my impediments I used a spreadsheet to keep track of them. I was trying to create a history of impediments that I could review and reflect on both by myself and with the team. At first, I just started out recording the name of the impediment and tracking whether or not it was resolved. Soon however, I started adding more categories to the list of impediments. I wanted to track when I first became aware of the impediment, and when it was resolved, I wanted to categorize the impediments so that I could track themes – impediments that might share a common origin. I also started to track the root cause of the impediment – what had occurred (or not occurred) that had led to the impediment in the first place?

As I tracked my impediments over time, the list of categories grew longer and longer. Here is the list of impediment categories that I track today:

Missing dependencies: This could be software, hardware, or people dependencies. All too often something needs to happen, but something required to make it happen is missing. I want to order a burger at the drive through, but there is no one to take my order at the window. I picked up the idea for this category from Matthew May’s excellent book, “The Elegant Solution”. He outlines a lot of the lean strategies used at Toyota and the principles that support them. In one chapter he categorizes many different kinds of waste that can be found in any process. It was reading this chapter where I had a “eureka!” moment: impediments = waste!

Defects: This one is pretty obvious most of the time. Something is broken. There is a bug in the system. Something isn’t working as intended. The heater in my car seat stopped working. The bugs assigned to the team in triage. The little plastic lid won’t snap on to the top of my latte and stay.

Not enough time: The story of my life. Usually this indicates a scheduling or commitment problem.

Interruption: Do you have your email client setup to alert you as soon as a new email arrives? That’s an interruption. Interruptions can be obvious, like when the phone rings, or they can be subtle, like the way we manage our email.

Incomplete Work: Half done work can be as bad, if not worse than work that was never started at all.

Waiting: This category is everywhere. Try keeping a notepad with you and noting all the times that you wait during the day – for anything. You may be surprised at how much waiting is going on in your day.

Miscommunication: Communication between team mates – between teams – between silos…

Decisions not made: Organizational dysfunctions are impediments – sometimes the toughest impediments to resolve. The good news is that they are also frequently the kinds of impediments that once resolved, deliver the most reward.

Poor Maintenance: OK, I admit it – I was thinking of my car when I came up with this category. Without revealing too much, I realized that there are a lot of things that need maintenance in my life, and they all need to run smoothly (my car, my house, the dishwasher, the servers that run our software, etc.)

Disorganization & Clutter: Anyone who has seen my desk knows where this category of impediments came from.

Over commitment: Sometimes impediments arise from the very fact that we are just trying to accomplish too much. The good news is that this category of impediment is easy to resolve – just back off the throttle.

Lack of control/Discipline: This encompasses those impediments that arise because of something that wasn’t done. Sometimes there is an established process that isn’t followed – that can be a problem. Other times the process itself can be the impediment.

Forgotten: Alright, so my memory isn’t what it used to be. OK, my memory was never that great. The point is, forgetting to do things can be a big impediment to getting things done.

Distractions: email, web browsing, and the three martini lunch – It’s amazing I get anything done at all. It pains me to think that many of the things that we get such pleasure from can also impede use from achieving our goals (such pleasurable impediments). This category of impediments is the hardest for me to see.

This is by no means an exhaustive set of impediment categories. I’m quite sure that there are many more.  The categories can overlap too. An impediment can fit into multiple categories at once (i.e. waiting and decisions not made seem a natural combination).

There is one other benefit of categorizing impediments that I am only now starting to realize – categories provide a language for talking about the impediments for your team. It’s a lot like patterns in the respect that simply giving a name to a class of impediment allows us to discuss the issue as a group without getting locked into specifics. It provides a level of abstraction for the discussion – and dealing with abstractions is where we make unexpected connections to other solutions.

I see working with categories as a tool that we can use to help remind ourselves of the things that we should be looking for when we are seeking to reveal the impediments around us. Categorizing is something that we do very well as human beings. Scientists have been doing it for a long time (Kings Play Chess On Fine Grain Sand). On a cognitive level, categorizing our environment helps to frame how we think about the problems we are facing. It allows us to better discern the similarities and differences in the objects under study.

We need to take a scientific, empirical approach to working with impediments. Categorize them any way you choose – the very act of making the categories will help you to discover new impediments. Uncovering impediments is uncovering problems and it is in the solutions to those problems where you find innovative ideas for yourself and your team.

Defining Impediments

I have a confession to make: I’m a scrum master and I can’t see impediments. It’s terrible – I know I should be able to see them, but somehow they pass right by me every day without my noticing them. Well, maybe “pass right by” is not the right way to put it. Actually, those of us with impediment blindness (I have a name for it: “Impedimentia”) we clamber over the challenges in life’s little obstacle course without out even recognizing they are there. In some sense, my fellow impedimentia sufferers are working really hard to get through the day without even realizing that life could be a lot easier.

Recently I have become determined to find a way to overcome my condition. The first question that arises is “What exactly is an impediment?” Perhaps starting with a definition would help. If I run to the dictionary, I get the following definition:

Impediment: 1.The fact of impeding or condition of being impeded; hindrance, obstruction 2.Something that impedes the function or health of the body; a (physical) defect; an affection or malady

It’s actually kind of a funny word when you look at it. Now that I think of it, I’m not sure that I really use the word impediment all that often. I’m more likely to talk about “blocking issues” or “things holding you up”. Well to be honest, just knowing the definition of an impediment really doesn’t help me much. I know what they are, but I still can’t see them. It’s like knowing the definition of what an elephant is, but not being able to see them (elephantia?). Now that I think of it, it’s too bad impediments aren’t more like elephants – there would probably be a lot fewer project managers out there! Sadly, that would likely include me too.

In truth, much like actual blindness, there are varying degrees of incapacity. In the same way that many people are impaired by blindness, but still have some vision – I also have partial impedimentia. I do see some impediments. I usually see them if they are as big as a truck, with neon letters on the side, proceeded by heralds blowing trumpets. Anything less and I’m likely to miss them. I sometimes recognize impediments long after they have passed by. It’s sort of an “Oh…that’s why it hurt so much” reaction. The point is that I do see some impediments, probably many fewer than most people, but I do see them – even if after the fact.

So in an effort to get better at identifying impediments, I’ve decided to keep a log of the impediments in my life. I review the log on a daily basis to learn more about these creatures we call impediments. By recording them in a daily log, I’m able to capture my impediments under my metaphorical microscope and examine them more closely. My intent is to create a catalog of impediments. I’m compiling a beastiary of these creatures both common and exotic.

Friday

• Too tired to work effectively
• Traffic jam on the way to work
• Late for a meeting
• Not able to contact manager
• Child refuses to get dressed
• Not prepared for meeting
• No time to work on committed project
• Not allowed to join email group
• Not enough time to exercise
• Eating too much

Like any good scientist, it’s tempting to start creating a taxonomy of the creatures that you are studying. So I’m tempted to start categorizing the impediments that I encounter in my log. Some are hairy with great, big eyes. Others have multiple clutching tendrils and sharp, pointy teeth. Some look suspiciously like CEOs.

If I go back and look at the list I created and start looking for patterns, I see categories that look something like this:

• Delays, waiting (traffic jam, late for meeting, procrastination)
• Not enough time (project work, exercise)
• Over consumption (over eating, too many committed tasks)
• Exhaustion (too tired, etc.)

These are categories that apply to me. They might not be the same ones that apply to you (you may not procrastinate nearly as much as I do). However if I take these categories and use them as a check list, I can review my day and inspect it for impediments. After all, I don’t necessarily need to recognize impediments the moment that they occur. I’d be happy to discover them the same day that I encounter them. That would be a huge step forward for someone with a bad case of impedimentia. So I instituted a personal impediment review at the end of each day.

In my review, I look for impediments in a couple of places. Microsoft Outlook is a good start (or whatever calendar you may keep). I start with the calendar and review all of the meetings that I had for the day. Were any delayed or postponed? Was I on time to the meeting? Was I prepared to make a useful contribution to the discussion? Were there any noteworthy events that occurred during the meeting, fistfights, altercations? Then I move to the real impediments gold mine: my email inbox. Eureka! Aside from dealing with the daily deluge of email (impediment #1), I have every issue that was sent to me during the day – impediments galore!

So I record all of these impediments in my log. This gives me a couple of things:

1. A catalog of common impediments (a source of ideas for things to look for)
2. The daily frequency of impediments I find (is my impedimentia getting better or worse?)
3. A place to catalog the types of impediments that seem to plague me

This daily reflection helps to crank up my sensitivity to the impediments that I encounter every day. As I review my daily catalog of impediments, I find impediments that are vague, impediments that actually contain many little impediments.

All of this reflecting and journaling reminds me of Ben Franklin, the original self improvement fanatic. In his autobiography he describes how he kept track of his habits and his…impediments? I wonder if he had impedimentia too. Probably not.

Give the 360 Back to the Team

Tired of doing the same old retrospective every sprint? You know how it goes: what went right/what needs improvement/action items. Are you running out of ideas for improvements?

Here’s an idea: at the end of each sprint do a 360 review. Use a survey tool and have every member of the team review each other’s performance in the past sprint. Just a couple of questions would do it. A good tool would summarize the data for each team member. Then, based on that feedback, each individual on the team would have a really good starting point for a discussion about how they can improve their performance in their next sprint.

Imagine doing a 360 every two weeks. Imagine changing the questions every two weeks to meet changing conditions that the team encounters. Imagine having up-to-date feedback on your performance as seen by your peers every sprint.

I offer this notion as a counterpoint to the traditional 360 review that is run by the corporation/HR. You know the one where you have to review a bunch of people you don’t necessarily know, then sit in an uncomfortable meeting with your manager where they review your personality flaws revealed by your peers. Instead, the 360 is for your use only. You decide what to do with it. Nobody else, not the scrum master, no one else is privy to the results.

I’ve done 360 reviews at a couple of different places (it had nothing to do with Agile). In most cases it was a top-down driven process. Questions were determined by my managers (and their managers) and when the results were tabulated they were given to your manager first. Then your manager would review the results with you. Recently however I found myself at a company where they wanted to do things differently. Privacy was a much bigger concern in this culture. People didn’t want anyone to see their results – not even HR.

At first I found this preoccupation with privacy perplexing (I’m very trusting by nature). However, as we went through the process I realized that the privacy actually seemed to improve the 360 review. It keep the feedback limited to the person who needed it most (the person being reviewed), without exposing it to the judgement of others (managers, HR, etc.). Whether or not you wanted to actually *do* anything about the feedback was purely up to you. It took the pressure off the situation – and I usually find that to be a good thing. If my salary isn’t hanging in the balance, I usually make much better decisions.

The more I thought about it, the more I thought we should be able to do a 360 review as frequently as we want to (assuming we can keep them low cost/low effort). Better yet, if the team controls the questions that are asked, then perhaps the team can change the questions frequently to match the changing nature of the problems they face. That seems to offer a unique opportunity to provide honest, anonymous feedback for team mates. 

An agile purist might maintain that a team should be able to give each other that sort of feedback without the 360. We should be able to critique each other face to face. Perhaps. There are some teams that are very good at that (very few that I’ve worked with). For the rest, the 360 might be worth experimenting with.

What sorts of questions might you ask in this kind of 360? Here are a few ideas for categories of questions based on the Scrum Values as described by Ken Schwaber:

1. Commitment
2. Focus
3. Openness
4. Respect
5. Courage
6. Technical Skills
7. Domain knowledge

If you are thinking of trying this out, here are a couple of tools that might be useful for implementing a cheap 360 for your team:

• Zoomerang
• Rypple

Feedback is good. I’m thinking of using this sort of survey for my presentations.

Measuring Productivity = Continuous Improvement?

How do you measure the productivity of a team? Some answers that leap immediately to mind are:

1. Story Points
2. Throughput
3. Function Points
4. Features

And I’m sure there are dozens more. But as I consider this, perhaps I should re-examine just what the word “Productivity” actually means. According to Merriam-Webster the definition is:

1: having the quality or power of producing especially in abundance 

2: effective in bringing about 

3 a: yielding results, benefits, or profits b: yielding or devoted to the satisfaction of wants or the creation of utilities

4: continuing to be used in the formation of new words or constructions 

5: raising mucus or sputum (as from the bronchi) <a productive cough>

OK, we’ve all probably worked on a few projects that fit definition #5 of productivity. Cough. Ahem. There are a few words in those definitions that catch my eye: abundance, effective, yielding results, benefits, or profits. I’m still no closer to measuring productivity. Hmmm…

Donald Gray has a great blog on applying measures to a teams work. He points out the usual criticism of most measures – namely that you get what you measure (for better or worse – usually worse). However, that really doesn’t help us at all. We’re still stuck without a decent measure for productivity.

You know, the more I think about it, the more I wonder, “Who’s asking for a productivity metric?”

I can think of two basic cases:

1. Some sort of external stakeholder (a manager, a director, a product owner, a CEO, a customer, etc…)
2.  The team

If the answer is #1, some external stakeholder, then the odds are good that for some reason they don’t see the team as productive already. If they thought the team was productive to some sort of acceptable standard, they wouldn’t bother asking in the first place. It could be caused by a variety of things (poor visibility into the team, not understanding how the team measures its progress, or plain good old fashioned cluelessness). Or maybe they are trying to help the team. Pardon me for a moment, a monkey just flew out of my butt…

If the answer is #2, then that’s a team I want to work with! The way I see it, this is the way it should be. It’s the team’s job to be constantly examining their own productivity. They should be fascinated by it. Positively mesmerized. How can we improve our work? Measuring productivity in what ever form it might take is the heart and soul of continuous Improvement. It’s the team’s job, not the customers. That feels right. See? No monkeys!

Personally, I like Ron Jeffries example. Productivity is the team’s challenge and the customer’s right. Let the team find the measure and then they should hold themselve to it. Make it visible. I’m a lot happier with the notion that the team controls the measures of productivity rather than some external stakeholder. Is that wrong? Still no monkeys…*

*I apologize for the monkey references. Pinochio had his nose, I have butt monkeys.