Finding Your Voice

When some people transition from traditional project management to Agile, they seem to lose their voices. These are people who had great, strong, passionate voices. People who felt they were engaged and empowered to lead their teams to success. And then some consultant comes along and tells them that they got it all wrong. The wise consultant tells them that they are part of the problem and need to change their evil command-and-control ways. They need to be a servant leader – one of the most poorly defined roles ever conceived. Guess what happens to these poor bastards?

They get confused! They don’t know what their job is supposed to be. Everything they used to do is suspect, part of that horrible “waterfall” thing. And now they have a team of people who have been told just how evil they are. Nobody trusts you. Why don’t you just remove impediments and stay out of the way? Don’t call us, we’ll call you. If we need you. You don’t code, so you’re not really that relevant anyway.

Soon people are asking questions: where is the leadership? Why won’t these weak Scrum Master creatures take responsibility for the project? It’s the team’s job? That’s funny, I don’t see the team stepping up…and so it goes. Now everyone is confused. What has happened to that rich voice that guided the team? Now it’s a timid peep. It’s a pale, skinny shadow of what it once was.

And so the journey begins. We sit back, watch the chaos ensue and ask ourselves, is this really my job anymore? I’d do it differently, but apparently I have to say it differently too. What should I say? Meanwhile Rome doesn’t exactly burn to the ground. Not exactly. In fact, people make approving noises. Things are better now…aren’t they? After all, we spent 100 grand to get here. Look at our metrics!

At some point, things start to go wrong for the team. Nobody steps in. The pressure builds. The Scrum Master looks around and thinks to himself, isn’t somebody going to do something? The pressure builds some more. Still no action is taken. And then the levy breaks and there is the voice! The voice that demands resolution. The voice that won’t accept mediocrity. A voice that communicates a clear and compelling vision.

Why do we do this to ourselves? Maybe it’s a journey that we all need to make. Perhaps there are no shortcuts. Maybe it was just me hearing voices again.

Moving People Between Teams

So, let’s pretend that you are working someplace where you have two or more teams working on development projects. Furthermore, let’s say that those teams have been in the same configuration (same folks doing the same thing) for 3 or more years. Things might start to get a little stale right? Teams might start to get a bit isolated, each focusing on their own areas of domain expertise. You might find it very difficult to introduce change in this kind of environment – in fact, I can almost guarantee that people will tend to resist change in a scenario like this.

So then I wake up screaming in the middle of the night.

Wait…we’re not talking about me. Really. So this “friend” of mine thinks he has a problem and he wants to stir things up a bit. The idea is to start moving people between the teams. People get experience with different domains, different teams, different technologies, etc. So what strategy should you use that will provide some structure for this type of team swapping that won’t seem totally arbitrary and capricious and will be respectful of the people involved? So I had a few ideas that I shared with my “friend”:

• Musical Chairs: everyone swaps one seat on the team, if you don’t have a seat you go to another team

 

• Playground Picking: just like picking teams for kickball, every once in a while you get everybody together, pick captains, and let them select their own teams

• Core + Float: keep “essential” people on the team together, and give journeymen on the team the opportunity to work with whichever team they like

• Sprint Rotations: each sprint, rotate a different person on the team to another team.

How would you stir things up on your teams?

 

Bad Programmers

There was an article in the CACM recently that caught my attention entitled, “In Praise of Bad Programmers”

Still here?

Apparently the provocative  title really sets off some fire alarms for people. I shared the article, which I personally thought was great, with a team and we discussed it together. I thought the whole conversation went really well and I thought it felt very productive. Afterward, I discovered that everyone in the room had apparently been thinking one thing: “He thinks I’m a bad programmer”. I’m not sure they recalled any of the conversation after reading the article. In fact, I’m quite sure they didn’t.

That reaction probably says a few things about us:

1. We don’t feel safe talking about our skills with each other
2. The team felt some sort of judgement was being made by me
3. How you frame the conversation really does make a difference

Having done this sort of thing for a while, none of the above particularly shocks or surprises me. It’s just a reminder that some conversations with teams are harder than others. You don’t avoid them, but you need to be prepared to set the stage well before the conversation, make sure the team feels safe enough to deal with the conversation, and have a way to check in with them afterward to make sure your read on the conversation isn’t incorrect.

Oh, and if they’re still angry after all that, then it’s really their problem. I’m a coach not a therapist.

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?

What I Learned From My Daughter’s First Grade Classroom

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Using Mistakes to Build Team Cohesion

So I’m working with this team and it’s a really daunting situation. There is every reason for things to fail big time. So I play it safe. I work really hard to make sure that I don’t make any mistakes (social, political, you name it). And I feel like I can’t build up any relationship with the team. Nothing. Nada.

So I scratch my head and wonder, “What’s wrong with these people?”

There seems to be this invisible barrier – they accept me because they have to, but they really don’t want me around. Me? I’m going nuts. Every day feels a little bit more aggravating than the next. Nothing seems to get through to them. Finally, there comes a meeting where I totally screw the proverbial pooch. Nothing major, no fights, no cursing, but something I say really pisses off the whole team. And they are mad, really mad.

So I get the team together, I apologize to everyone involved – take full responsibility for being a jerk (pick myself up off the floor, dust myself off) and we move on. Funny thing happens though…the barrier is gone. That’s right, the quality and tenor of the conversation immediately takes a jump toward the positive.

It wasn’t until I tripped and fell that the team started to show some signs of accepting me. It took me three months. Note to self: I’ve got to remember to fall flat on my face faster next time. I think they were waiting for me to show some signs of being human (and not some sort of Agile Superman) before they were willing to accept me on the team.

Or I could be over analyzing the whole thing. Who knows? All I know is that I feel a whole lot better working with that team since then.

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?

Trust Your (Bleep)ing Team!

Here is an issue that has come up over and over again – scrum masters and product owners that don’t trust the teams they work with. I’ve struggled with this problem myself over the years, so I can definitely relate to the mistrust. Here’s my favorite example:

Sandbagging: The team is not delivering 100% of their stories each sprint. The team is not pulling as much work as you would expect each sprint. Everyone is coming in late and leaving early. No one is staying late nights to make sure that stories are absolutely done before the end of the sprint.

There you are as the Scrum Master, tearing your hair out in frustration, trying to figure out how to get the team to step up and deliver. Well, if this goes on for very long, you end up not trusting the team. After all, their commitments seem to mean little, they just go through the motions, etc. Of course, here’s a news flash – they don’t trust you either. In my experience, teams can almost always read you like a book. They know it when you don’t trust them. They know it when you think it’s “their” problem. They aren’t stupid. This just further increases the sense of alienation between the two sides. It further limits your ability to be an effective member of the team.

I think that often times when we get to that place of mistrust we are doing something very fundamental and very destructive to the relationship with the team. We are making the problems, what ever they may be, someone elses problem. It’s the team’s problem, not yours. It is something that is inherent in their nature – they are somehow flawed. If they would just somehow, “Get it” then our problems would be solved. Of course nothing could be further from the truth. The fact is that everyone plays an important role in this dance of trust. If you really want to address the problem, you have to be ready and able to take responsibility for your part in the problem. Because as scrum master or product owner, you are part of the problem, like it or not.

So what is the solution to this problem? Trust your (bleep)ing team! That’s right, get that mistrust monkey off of your back – take it from me, that particular simian has nothing constructive to offer. Let the team know that you trust them completely – 100%

You’re never going to make significant progress as long as you and the team distrust one another. Guaranteed.

Then start looking for the impediments that are holding them up. Maybe the first and most difficult impediment to remove is any mistrust we may have with the team.

Do Donuts Exert a Gravitational Field?

A few years ago I went to the Apple WWDC (World Wide Developer’s Conference) in lovely Cupertino California. I was kind of a loner at the conference. It was my first time. I was by myself and I didn’t know anybody. But I had a Mac.

Being the person that I am, I often felt like I was on the outside looking in. It was a very sociable crowd. People would get together in the hallway, sit right down on the floor, break out their titanium PowerBooks (OK, I’m showing my age), and start writing code. The halls in the convention center left ample space for this kind of interaction. I suppose, if I were really cool, I would have been in one of those groups. However, often times it was just me reading my email and waiting for the next session.

Sitting there, staring out over the hall, I had an excellent vantage point for observing my fellow Macintosh fanatics. Each morning started the same way. Around 9ish we would all stumble into the main hall. In the middle of the hall would be dozens of tables seemingly arranged at random. Upon each table a pyramid of Krispy Kreme donuts towered nearly 3 feet in the air. Literally hundreds, nay thousands of delicious donut delectations per table. Decanters of coffee lined the walls of the hall. I never saw anyone set them up – it must have been the donut fairy.

You should have seen the feeding frenzy that would erupt each morning. The ravening hordes would descend upon the innocent stacks of fluffy goodness and attack without remorse. But even the starving appetites of the Apple Illuminati could not defeat the towering Krispy Kreaminess. The mighty pyramids of sugary goodness might buckle and sway under the onslaught, but they seldom fell in the first assault.

It was with a sort of sick fascination that  I observed the carnage taking place, the floor gradually getting sticky near each table. I saw a pattern emerge: observe any individual in the crowd and they would act as if the tables of donuts exerted a mysterious gravitational field. They would grab a pastry and and walk away from the table, munching contentedly and bearing an expression usually only associated with hardcore narcotics. Curiously however, their path began to describe a  parabolic trajectory as they arced away from the table, reached the apogee, and then inexorably returned along their orbit to the table they had started at – helping themselves to yet another hit of the sugar filled tranquilizers.

I watched many a poor soul trapped within the sugary gravitational field of those tables, unable to avert my gaze. Good men! Decent men! Men who had families! Doomed men. Sometimes you would see a particularly pathetic example: someone caught in the gravitational tug of war between twin towers of donuts. Orbiting the two tables in a gigantic figure eight pattern. Forever to repeat their path, wearing a hole in the carpet, until either the donuts were consumed, or they were carried off on a stretcher in a diabetic coma by the convention center staff.

I have seen the face of madness and it lies like an alluring young siren in a lush field of all-you-can-eat donuts.

Modeling

Look out Heidi Klume, I’m taking up modeling!

OK, maybe I won’t give up the day job just yet…

Sometimes I think there is no better way to teach something than by doing it. By modeling the desired behavior. Sometimes people just don’t want to trust you. They won’t beleive it until they see it. Especially when you are trying to sell them a new process. Maybe that’s the way it should be.

It’s one thing to believe in a process and share the perceived benefits, but it’s quite another thing to demonstrate those benefits yourself. As agile practitioners I think we need to prove our case to our stakeholders and our teams. To teach by doing. We have to demonstrate what a high performing team looks like. Sometimes people need to see it first. Words simply do not suffice.

Getting down and dirty and working on a team also tends to be a cleansing experience for me. A lot of the B.S. that I sometimes buy into will not withstand the metaphorical blowtorch of a team struggling with real, messy, problems. That’s a healthy thing.

Modeling also helps to remind me that I like working on small teams. I like the commeraderie. I like the challenge. And modeling also reminds me, usually with a swift kick to the head, that process won’t solve all of the worlds problems. Sometimes it doesn’t matter whether or not a team is agile – sometimes there are forces at play that agile development can’t help us with. In those cases, you may model and fail. Call it a learning opportunity.

So the next time that you feel frustrated that “they just don’t get it!” Maybe it’s time you tried a little modeling.