Slowing Down

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?

Why?

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.

Strategies

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

Reflections

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

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

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

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

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

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

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

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

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

What I Learned From My Daughter’s First Grade Classroom

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Inspired by Executable Design

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

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

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

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.

Amen.

A few experiments in Agile

Here are a few ideas for things we could try out to improve our teams:

1. Work on only one story at a time
2. Minimize square footage of the team area
3. Daily Design Review
4. Change the way you do retrospectives (a coffee chat rather than an inquisition?)
5. Bring one new idea to every stand-up meeting
6. Daily interaction with other teams (ping pong tournament, sports book, whatever)
7. Utilize ambassador pattern between teams
8. Get to know I new thing about a team mate each day
9. Focus on a single practice in each review until the practice is mastered
10. Swap roles every sprint

Like anything else, they probably would be best supported by some acceptance test of some sort. It would be some what of envisioning what the success of a given experiment would look like. There is no point to trying something out if you have no idea what the benefit will be…

Just a thought,
Tom

Information Density and Project Tracking

One complaint that I hear from people who don’t like a given project tracking tool is that there is actually too much information on the screen at once. They find it distracting and it makes it hard to find the really relevant information. In response, usually I nod my head sagely, mumble something obscure, and move on.

But when I give my talk on the pros and cons of using physical vs. electronic project tracking tools I neglect to mention this difference. If I stop for a minute and take a good hard look at the task board our team is using right now, it doesn’t say a whole lot compared to the electronic tools we use. For one thing, the team and I keep a pretty sloppy task board. Stuff gets crossed out, notes are written in the margins, extra stickies are tacked on top of other stickies. We know what it all means, mostly, but I’m not sure that anyone else could easily parse it all out. There’s a lot written between the lines in both a literal and metaphorical sense.

On the other hand if I use my electronic tools, they pretty much force me into a much more orderly state. There is a lot of explicit information displayed – it takes a while to setup. But it’s neat and orderly. If I need to make notes, then I can put something in the “notes” field. Unfortunately the notes field is not normally displayed. I have to “open” a story to view the notes. Information is cleverly hidden. Like I said, it’s neat, it’s tidy, there is lots of information, but some parts are hidden.

Hmmm…Of course there is hidden information in my physical task board too. I have a confession to make: As a team, we’re pretty lazy – and proud of it. We’re firm believers in helping our environment by practicing the conservation of syllables. Why use two words when one will do? Mike Cohn said it best, The user story is a placeholder for a conversation. Amen brother! It’s remarkable how much we can read into so few words!

So both types of tools have their own forms of information density. And they both have different types of data that is “hidden”. Of course, I have more control over the physical taskboard than the electronic one. I’m pretty much forced to display certain data using electronic tools – even if it isn’t necessarily relevant to me. That’s probably where the information density argument comes in. I don’t mind information density if it is exactly the information that I want to see. However, if it’s not relevant to me, then it only serves as a visual impediment.

Something to keep in mind the next time you are tool shopping.