Simplicity of Measure

October 18, 2014


I got a fitbit bracelet the other day. It’s a pretty nifty gadget. It tracks the number of steps that I take in a day, as well as measuring movement while I’m asleep. I’ve been very impressed with the number of things that you can derive from a simple measure of the frequency of movement. You get number of steps, activity level, calories burned, sleep periods, and a few other metrics. All of that from one simple measure of how often my hand moves.  Admittedly, some of those measures are inferred based on some simple assumptions like how many calories that the average person burns in a fixed period of time. However there is nothing wrong with that, The measure doesn’t have to be 100% accurate in order for it to be useful to me. I can see the trends and understand if my calories burned is changing for the better or for the worse without having the exact number of calories that I burn in an hour. An approximation is certainly sufficient.

It’s really quite impressive that you can derive so much from a single metric. It made me wonder about the metrics that we keep on Agile teams. Whether it’s velocity or throughput, there are metrics that we use for a lot of different purposes. We use velocity to tell us how much work the team can take on per sprint. We derive duration using velocity. I like the notion of having a small set of metrics like velocity that we can use for a variety of measures.

The Agile Experience and The 5 Rules of Accelerated Learning

October 4, 2013


How do you experience Agile?

I’m not talking about the process, the rituals, or the artifacts. I’m certainly not asking you to regurgitate any of the usual Agile jargon. I’m talking about how it makes you feel. It usually starts with a question like, “Are you using Agile?” and I catch myself saying things like, “Yes, we do scrum.” Answers like that probably miss the point on a very fundamental level. What I think some people are really asking is, “What does it feel like to work at your company.” What is the experience like?

All too often, that’s as far as the conversation goes. I find myself frustrated by that. You see, I want people who come to work with me to have an experience that is different from the traditional corporate environment. I want them to feel differently. I want them to interact differently. You see, I think a different experience was behind much of the promise of agile methods. Agile provides this groovy toolbox of collaborative methods in order to help change the way working together feels. It promises to change the experience of work.

Just using Agile methods won’t necessarily generate a different experience. You can just go through the motions and not change the feeling of the experience at all. A planning meeting where everyone is seated at a conference table falling asleep in front of some task board on a projector feels a whole lot different from a planning meeting with everyone standing up talking and trading sticky notes back and forth. Its a visceral difference in the experience. You can call them both agile planning meetings, but one feels very different from the other. I see this all the time in daily stand up meetings. Poorly handled stand up meetings usually have all the life and energy of a funeral.

How do we change that experience?

That’s where Willem and Diana Larsen have some interesting ideas. They are working on a book enigmatically entitled, Name This Book that among other things introduces the Five Rules of Accelerated Learning. These rules offer a foundation for techniques that we can use with our teams to enrich the kind learning they have to do every day. These are ideas for improving the learning experience along 5 different dimensions: Alive, Fluency, Signal, Focus, Setting. Each of these dimensions interacts to contribute to the power and effectiveness of the learning experience.

Willem puts it best “I always recommend thinking of the Five Rules as two Values (Alive and Fluency) and three Principles /Tools (Signal, Focus, Setting), and listing them in a consistent order for that purpose (Alive, Fluency, Signal, Focus, Setting). This also makes them easier to recall for new folks”

They also have a smaller 99 cent book that just gives a summary of the Five Rules that you can find here: If you are just looking for a quick intro, this is where you could start.

In brief, here are the rules:


This is about the feeling of energy in an experience. As Willem and Diana put it, this is that feeling of having a peak experience. That moment of total engagement or achieving flow. There is an element of playfulness to it. We want to maximize this feeling in order to enhance  learning.


This is the assessment of our skill at actually doing something. In order to provide the right learning experience, we need to assess the fluency of the learners, and perhaps more importantly, create simulations that challenge and allow them to exercise or experience that skill.


Changing the signal is about amplifying the message so that the learner is most likely to receive it. This can involve reducing distractions, increasing repetition, upping the emotion – using every tool at your disposal to get their attention.


Keeping learning going requires steadily adjusting the focus so that you accomodate the varying attention levels of your audience. This involves changing the pace, breaking things up and adjusting based on the overall energy level (see aliveness).


Altering the setting is creating the environment that promotes learning. It’s all about an environment that enhances or amplifies the learning that takes place.

Putting the 5 Rules to Use

First, if you are interested in this sort of stuff,  you should check out their book. They do a fabulous job of laying out all of the rules and putting them in context. Second, if you have a chance, you should definitely catch a presentation on the topic by either Willem or Diana. They are two very engaging speakers and I’ve heard them speak on this subject – it’s worth it. Finally, even if you don’t do any of the above, it’s interesting to note that Willem has put all of this theory into action with Language Hunters – a learning group dedicated to using these techniques to help with teaching and learning rare languages. Check them out.

So obviously, I’m a big fan of their work. The question is: how can you and I apply it? Here are a few places I’ve tried:

Teaching (training, workshops, presentations)

So, I had an experience not very long ago where I saw these ideas in action. It just happened that I was delivering a very interactive workshop at XP2013. I asked everyone in the room to help me generate what I like to think of as an idea cloud at the beginning of the workshop. The experience was like this: as soon as you entered the room, I was there saying hello and inviting you to help me add ideas on note cards to a wall. My goal was to convey a feeling of “Come play with me!” Soon we had a large crowd of people all standing in front of a wall adding ideas. I was jumping in and out of the group, collecting ideas, offering new ones, handing out note cards and generally dancing like a madman (it all felt a bit maniacal). I had music playing, people were talking and the room got pretty noisy pretty quickly. They were competing for space at the wall, helping me facilitate, and generally helping to contribute to a wonderful atmosphere of barely controlled chaos. Folks seemed to be pretty deeply engaged. They were showing me ideas I had never seen before, and I even managed to toss a few originals into the mix. We were teaching each other.

I remember turning around at a key moment to talk to the group. I had my back to the wall and I was surrounded by about 40 people all standing about two feet away and looking right at me. Staring into this sea of expectant faces, I had a moment of panic (it was a little intimidating). I put up my hands and almost reflexively said, “OK everybody, let’s sit down.”

Immediately I realized I’d just made a huge mistake.


All at once I could feel the energy drain out of the crowd. There was almost a palpable sense of disappointment as people searched for a chair. I could almost feel the energy in the room go “Poof!” and disappear. It took me another 10 minutes to get everyone back up on their feet and fully engaged again. The rest of the workshop went great, but that moment where everyone sat down made a huge impression on me. I realized that I had created a critical element of aliveness and engagement that felt almost magical (people told me afterward that they thought it was one of the most energizing workshops they had attended). I think I had managed, for a brief time, to create that alive learning experience in a group of people. Referring back to the 5 Rules, perhaps I had a combination of focus, aliveness, and setting (3 of the 5 rules!) working for the group.


I wrote about an experience with interviewing recently in Bob the Naked Agilist. In that interview I introduced a drawing and asked the participants in the interview to help me clothe a hypothetical Agilist with the things that they would need to survive out in the corporate jungle. It swiftly turned into a very engaging and dynamic dialog where we were generating ideas together and asking each other spontaneous questions about the things we thought were important for our work. For me, it felt like the conversation opened up.

Compared to the traditional interview where we all sit around the table in combative postures and quiz each other, this felt like we were collaborating on building something together. The energy was completely different (and honestly, quite refreshing compared to the usual drudgery of an interview). All I did was walk up to a white board and start drawing pictures. Next time, I’m going to get everyone up at that white board drawing too. I want people to experience interviews differently.

Dear God I must be nuts.

Fire Writing

So I managed to use the aliveness, focus and signal rules to improve the interview. Now that I think of it, an interview is a very intense learning experience for everyone. It makes a lot of sense to try to improve them.


One of the things that I think we have done particularly well in the Agile community is rethinking the way meetings are run. For instance, I believe that when I’m doing a meeting well, there are rarely any projectors or PPTs. The walls are usually completely covered with sticky notes, diagrams and all in a bewildering array of handwriting. That’s because everyone in the room has been contributing. Chairs are kicked out of the way against the wall. Tables are piled high with collaboration tools: sticky notes, sharpies, and stickers. None of this is particularly new or extraordinary – these are all the attributes of what I have come to expect from any experienced facilitator when they are dealing with an Agile team. It could be a retrospective, or a planning meeting – it really doesn’t matter. Why is this important? Because we have a body of techniques that makes our meetings feel distinctly different from the usual meeting. The experience is manifestly different.


Recently I was working with a team and just happened to be observing one of their stand up meetings. As a coach I was watching and waiting to see how the team dynamic would play out. As I stood there quietly, it occurred to me that I could use the 5 rules to help me asses the outward experience of the team as an outsider. I quickly jotted the 5 rules down in my notebook, and then asked myself some questions: Does this meeting feel Alive? Joe over there is bouncing up and down on the balls of his feet over there. There’s a lot of energy pent up there. Either he has to go to the bathroom or he has something he really wants to say. Nobody else is moving. What’s up with that? Are these people alive or in zombie mode?

Then I switched to the next rule: signal. What message is this person trying to send. Is it clear enough that I can understand it as an outsider or is it encoded in jargon. How are others receiving his message? Is he mumbling? Why?

For each rule I discovered a lot of interesting questions that were open for me to ask. After the team finished I pulled them together for a quick huddle and shared the 5 rules model with them. As I did so, I offered a few questions that I felt would offer seed opportunities for further exploration or introspection. With the judicious use of a few funny examples from my own past, I set the hook. What would you change to increase the liveliness of the meeting? How would you change the environment to improve the learning that takes place? What could you do to improve focus?

So the 5 rules served both as a source for assessment as well as a roadmap for improvement.

Where next?

These days I ask myself, does this feel different? Is this the experience I was hoping to create? Sometimes the answer is no. When that happens, I feel like what Willem and Diana have given us in the Five Rules of Accelerated Learning is a set of strategies I can use to create that new experience.

Slowing Down

February 12, 2013


Last week I led a session at Agile Open Northwest called, “Slowing Down”. The idea for this session was inspired by my own struggles with becoming quite over-committed to a variety of things (my job, my hobbies, etc.) and the resulting stress and crisis it has created for me. You see, the funny thing about it all was that even though I was perfectly aware of what I was doing by over-committing like crazy, I couldn’t seem to stop.

The Introduction

So I came to this session, not as an expert selling a solution, but rather as a novice seeking help. Since I really didn’t know where things were going to go, I simply started with the session title. I wrote “Slowing Down” on the whiteboard and introduced myself to the small group of people who had joined me for the session. I started with a story of my own. It was a bit like what I imagine an Alcholics Anonymous conversation starts like, “Hi, my name is Tom and I can’t slow down…”

Fortunately for me, many in the audience had a similar story. Since we are a bunch of software development types, it didn’t take long for the concept of sustainable pace to be mentioned. Of course we all knew full well what sustainable pace means. It is a term that I originally encountered in Xtreme Programming. I could ramble on for hours about the importance of keeping the pace and duration of your work under control so that you can sustain your creative energy and not burn out. Easy. But I can’t seem to do it worth a damn. That’s the interesting bit. Why? Why is it that, even knowing the importance of maintaining a sustainable pace, I and others like me seem to struggle so hard with it?


A few interesting ideas for why we get sucked into this dynamic were suggested during the session:


Ownership – Feelings of ownership can make it hard for people to let go of tasks and delegate them to others. For example, it is very easy for project leaders to feel a very strong sense of ownership and commitment to the success of projects that they are working on. This can be quite normal – often our organization want this kind of commitment from us. However, like many things, this can go too far. The undesired dynamic plays out as a feeling that you and only you are personally responsible for the success or failure of the project (what happened to the team?). When challenged, people who struggle with ownership issues will often look with incomprehension when asked to give up some part of a project, “If I don’t do it, who will?” I think that in some cases this inability to give up ownership can also manifest as heroism (ownership + adrenaline junkie). Perhaps at its heart, ownership issues are tightly tied to ego. They seem to manifest as a very selfish view of project success or failure.


Bad Habit

Habit – We form all sorts of bad habits that contribute to the stress in our lives. For example, I’ve gotten into the habit of checking my email compulsively throughout the day. Often even when at home. Habits like this that tether us to the office and constant communication serve to raise our overall stress levels. Other examples include habitually taking home the laptop with you every night and carrying the work phone with you wherever you go.

Culture – One major reason for difficulty with slowing down is the work culture you live in. People shared many different stories of how the expectations at work made it hard or almost impossible for them to escape the pressures of the office. Everything from evil bosses that demand attendance over performance to co-workers who make snide comments when a colleague dares to leave the office at 5:00. Some places even provide rewards for those who make decisions that put work above any other activity. Examples of these sorts of influences in the workplace abound.

All of these influences are very common reasons why people find it hard to slow down. It is no wonder that there are many who struggle to maintain a sustainable pace of work at the office. Understanding why you are feeling that pressure is critical to understanding what strategies to use to manage the problem. The strategies where where we ended up going next.


As we moved along in our discussion, people identified strategies that could be used to deal with slowing down and establishing a more sustainable pace. We captured and expanded upon those strategies as we wove the narrative of slowing down.

Setting Boundaries


The first strategy that came up was setting boundaries. Setting boundaries is fundamental to establishing control over your own schedule and pace. Fail to do this and all the rest really doesn’t matter. People told many stories about how they managed to establish meaningful boundaries in their work lives that helped them to keep a meaningful sustainable pace. Some made their 9 to 5 work hours non-negotiable. They never offered the longer hours that many fall into. You get me for 8 hours a day, and the rest of my life is not for sale. It was remarkable to hear the strength of some of these voices. Others refused to take work home or turned off the cell phone after 5.

Basically, what I heard were people establishing a service level agreement for their participation. One benefit that I noticed from this sort of boundary was that it made visible to everyone just what they could and could not expect from you. Visibility is a strongly held value in the agile community and it struck me that making my boundaries more visible would be a uniquely agile way of dealing with the issue (I’m closing the door now…). Another way of making my boundaries and limits visible would be to use a personal task board mechanism like personal kanban in order to not only make my existing commitments visible, but also to review them myself and keep tabs on how the work load is balanced (or not).


Diana Larsen did a great session last year at Agile2012 on personal retrospectives. As team facilitators, we are pretty well versed in running team retrospectives, however I never do them by myself. That is exactly what Diana proposed: do self-retrospectives on a periodic basis in order to reflect on your progress toward your goals, and where you want to go next. I think this would be a useful tool for many, whether it is only at the end of the year or much more frequently. I know that my own responsibilities feel like they have changed quite dramatically in the last year. Stopping to assess those changes might just give you the opportunity to recognize stressful trends and start to do something about it. You can start to do it now, or wait until a crisis imposes that reflection. Your call.

This is just my summary of what I saw and heard during our talk. Looking at the sheer number of topics that we covered it’s quite apparent to me that we covered a broad number of subjects. Many of them are worthy of deep investigation. Perhaps, as the mind map suggests, we have created a map of the terrain of the topic of slowing down. Others may have different take aways. I certainly hope so. I appreciated everything that the group brought to the conversation and I hope that I was able to serve as a reasonable scribe for what was said.

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

January 4, 2010

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

September 10, 2009

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?

Give the 360 Back to the Team

January 26, 2009


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:

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

Inspired by Executable Design

December 16, 2008


A post on “Executable Design” from Chris Sterling inspired me today. I’ve started running TDD workshops with the teams that I work with. It’s one of the most challenging things I’ve done in a while. Part of the challenge lies in exercising my technical skills – nothing exposes you to a group like coaching directly on coding techniques. Developers can smell your fear…

However I find that technical issues aside, acceptance of TDD lies in doing a lot of listening. And I mean a LOT of listening. As Chris states so eloquently, TDD is not a silver bullet that should always be used regardless of the circumstances. When someone is objecting to using TDD, there is often a darn good reason for it. Sometimes they just fear change, but as often as not, I find that people have realistic concerns about the appropriateness of using TDD in the particular environment they work in. Ignore them at your own peril.

Most of the time people understand the merits of TDD quite quickly – let’s face it, it’s really quite simple: Test. Code. Refactor. Repeat.

The merits of the process are not what people usually have problem with. Usually they are envisioning what happens when they try to apply it to the environment they are currently working in. That’s where the rubber meets the road. You have to be willing to listen to them, take their reservations seriously, and venture into the dragon’s lair (the environment they work in) to understand what they are dealing with. It’s very hand’s on. Very messy. Fraught with challenges.

Very quickly you can discover that TDD is not an all or nothing proposition. If people feel like you hear and understand their reservations and concerns, then they will probably be willing to follow you down a path toward some sort of adoption – if there is measurable  benefit. They may be willing to explore a variety of useful but perhaps imperfect solutions. On the other hand, if you are just regurgitating the benefits of TDD and dismissing fears…well, I’ve tried it and not had much success.

Swarming System Analysis Tools

September 10, 2008

What if we could model the interaction of teams the same way that we model the behavior of slime-molds, ants, and other simple organisms? What if we could specify some rules and then watch our artificial system run. What would we look for in our patterns that would indicate a desirable outcome?

This is certainly not an original idea on my part – In Swarm Creativity: Competitive Advantage through Collaborative Innovation Networks Peter Gloor talks about a tool they used to model these “Innovation Networks”. Of course you might say that the “Sim” games are a classic example of this sort of tool (Spore, theSims). Another example can be found at BioTeams where Ken Thompson focuses on the role of new communication tools to foster swarm like behavior (cell phone texting, IM, Twitter, Friend Feed, etc.).

Cool stuff. Check it out.

Using the Agile Cookie Cutter

August 2, 2008

How would you set up your next project? What would you require? I know what I’ve tried in the past – here’s a brief inventory of my standard Scrum Toolkit:

New Artifacts:

  • Team Working Agreement
  • Team Definition of Done
  • Task Board
  • Burn down chart
  • Impediments list
  • Release Plan
  • Backlog

New Meetings:

  • Sprint Planning
  • Daily Standup
  • Sprint Review
  • Sprint Retrospective
  • Backlog grooming

New Concepts:

  • Stories
  • Story points
  • Sprints
  • Releases
  • TDD
  • Continuous Integration
  • Cross Functional Teams

New Roles:

  • Team Members
  • Scrum Master
  • Product Owner

Boy, that’s a pretty long list of stuff. Looking at it, it sort of gives a guy cause to pause and wonder just how any team could absorb all of that. I guess that explains the deer-in-the-headlights look I get sometimes when I introduce teams to Agile processes. Do you need all of that to write good software?

This list is what I might call my “Agile Cookie Cutter”. It is the common set of ideas and practices that I try to role out with every team that I work with. But lately I’ve been thinking that slapping all this on a team all at once isn’t so smart. What I often see is teams going through the motions, adopting these practices whether or not they really need them. People get frustrated when they adopt processes wholesale and then run into problems with subsets of practices. What ever happened to gradually introducing practices and empirically testing their effectiveness?

Frequent Small Releases

July 11, 2008

With scrum, we try to deliver business value every sprint. That’s easier to do with some projects than others. If you have a mountain of technical debt facing you, delivering business value every three or four sprints can be a huge achievement. You might get lucky and find the occasional creative way of delivering business value quickly and easily, but most of the time you simply aren’t going to be able to manage it. Forget about it.

There are a lot different factors that make up a technically mature team, and they often take a long time to put together. Until you overcome those lower level issues, you won’t be able to properly address the higher level issues related to delivering business value quickly. Here is a graphic that I use to help make my point:

There are different levels of technical competence that need to be in place in order to support the rapid delivery of business value. If any one of these levels is missing, it is very unlikely that a team will be equiped to manage their work efficiently enough to deliver business value on a rapid and consistent basis. Teams need to be using source control tools and practices. Until they have source control, a team will not have the technical foundation in place to begin to put continuous integration in place. Once you have continuous integration working, you really aren’t getting the full benefit unless you can provide automated tests with every build. So on the technical side, a team has to have a lot of infrastructure in place in order to even think about delivering business value quickly.

There is another side to this issue that is very much tightly releated – how large are the releases that we make? Here is another diagram:

Here, instead of talking about technical maturity, we are looking at deliverables. At a relatively low level of process maturity, a team is really only capable of delivering files and resources with any real frequency. As the team becomes more technically adept, they are able to deliver components more frequently. As you can see, as the team becomes more and more efficient, they are able to deliver features and ultimately meaningful business value on a rapid schedule. These two hierarchies, the technical maturity and the deliverables maturity are linked tightly together.

So what’s the point? Well, if you are working on a team that is just adopting agile, don’t let anybody tell you that you are going to be delivering significant business value frequently – especially if you are like most teams and have a fair amount of technical debt accrued. It’s not that you can’t get there – you can, but it’s probably going to take a lot of work before you are able to deliver on that promise. People tend to expect immediate results when they switch to agile, and I’m here to tell you that often it just doesn’t work that way. If your teams are anything like the ones that I have worked on, you have a significant number of technical, personal, and other issues to overcome before you are going to be able to deliver the promised frequent delivery of business value. It’s definitely the way to go – I’m not saying it isn’t worthwhile, I just think expectations should be reasonable.

In the meantime, instead of trying to deliver business value every 5 mintues, why not focus on Frequent Small Releases (FSR) instead? Yeah, you heard me right. Learn how to deliver something – anything – frequently first. It’s all part of building a mindset of frequent releases that will ultimately (once the team is ready) culminate in the hallowed goal: the frequent release of business value.