Exploring The Project Jungle

January 14, 2010

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

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

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

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

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

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

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

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

Will Using Agile Get You Promoted?

January 6, 2010

What a dreadfully shallow question! You ignoramus! How superficial can you get? You’re not using Agile practices to make the world a better place?

Hell no! Anybody who blows that smoke up your skirt deserves the slapping they get. If we’re really honest, we use Agile methods because they directly benefit us in one of the following fashions:

  1. Using Agile gets you promoted
  2. Using Agile gets you a raise

Any other reasoning is just propaganda used to keep the proletariat happy, right?  Why else would you do it? The idealist in me has a ready response: We use Agile practices because:

  1. We produce a better quality product
  2. We deliver faster
  3. We are happier with our work

But how do we measure these benefits? If using Agile helps us produce a better quality product, then presumably our customers would be happier – and happier customers = more revenue. If you’re team is delivering more revenue, then isn’t it reasonable to expect some sort of reward? A raise? A promotion? The same argument applies to answers 2 and 3. I’m sure there are other ways that people express appreciation, but in modern corporations today there are really two predominant ways to recognize success: a promotion or a raise. Otherwise you are just a tool for somebody else getting the promotion or the raise.

So what if you are using Agile and you are not getting a promotion or a raise? Well, I would maintain that Agile isn’t really benefiting *you* much. I can use a lot of different methodologies and still not get a promotion or a raise. Why use Agile if it doesn’t benefit you in some material way? Because it makes other people happy?

I know this is all sounds terribly, awfully, cynical of me, but I can’t help but ask the question (OK, so I’m a bit of a curmudgeon sometimes – I’m probably going to regret it). However, I do think that every once in a while we need to step back and ask ourselves, “Why bother?” So please forgive the cynical nature of the post. For me, using Agile often gets me raises, so I should have no complaints. But it doesn’t always work that way. How about you?

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.

On Human Thought and Planning

January 3, 2010

Over the holidays I’ve been reading “The Design of Everyday Things” by Donald Norman. It’s a wonderful read, but dense – it’s definitely “armchair and a pipe” material – you can’t rush it.  I came across this interesting quote regarding the nature of human thought:

But human thought – and its close relatives, problem solving and planning – seem more rooted in past experience than in logical deduction. Mental life is not neat and orderly. It does not proceed smoothly and gracefully in neat, logical form. Instead, it hops, skips, and jumps its way from idea to idea, tying together things that have no business being put together; forming new creative leaps, new insights and concepts. Human thought is not like logic; it is fundamentally different in kind and spirit. The difference is neither worse nor better. But it is the difference that leads to creative discovery and to great robustness of behavior. [p.115]

In this paragraph Norman is talking about the fickle nature of human thought. When he refers to planning as a close relative of human thought, I couldn’t help but think of project planning. As Norman suggests, human thought is not the orderly process we might like it to be. If that is the case, then project planning is not the neat and tidy system that some people would like to sell you. If thought and planning are truly akin to one another, as Norman suggests they are, then I would suggest that any system that attempts to turn planning into some sort of logical, deterministic process is destined to fail. The intriguing idea here is that planning needs to accommodate creativity, intuitive leaps, non-linear processes.

I think there are a lot of people who grasp this notion, and I think there are many others who have a great deal of difficulty with it. Those who don’t accept this notion tend to try and wrap more and more layers of process around the problem. Those who accept the need for creativity and intuition in planning – people who are more comfortable with uncertainty – are more likely to treat the planning process as a dance: You know what the steps are supposed to be, but you are prepared to change at any moment.

Dirty Agile

January 2, 2010

I attended the Rally Agile Success Tour a few weeks ago. I didn’t know what to expect, but it turned out to be remarkably good. As I listened to the speakers talk about their experiences implementing Agile projects, I was reminded of just how tough this work is. I think that often, as leaders (project managers, scrum masters, coaches, dev leads, managers, etc.), we tend to harbor idealistic visions of what an Agile team looks like and how it performs. It reminds me of the “Retro-futurism” that I think Brian Marick refers to in his ARxTA presentation at AgileRoots 2009. We harbor these notions of a future where the team possesses the ideal tools, the ideal solutions, the ideal environment. There is certainly nothing wrong with all that. We need these goals. We need to have that expectation that Brian characterized with the question, “Where’s my jet pack?”

But the reality is anything but clean and ideal. There is no jet pack. The reality of working with teams is dirty and messy. We don’t have the ideal team, we don’t have the ideal requirements, we don’t have the ideal schedule. In fact, we never will. That’s OK though, it’s the imperfection that provides the team with the creative tension needed to make the job interesting.

Happy (Dirty) New Year!

If You Give An Agilist A Cookie…

January 1, 2010

If you give an Agilist a project, He’s going to ask for some stories.

When you give him the stories, he’ll probably ask you for a sprint.

When he’s finished he’ll probably ask for a retrospective.

Then he will want to reflect on his work and look to improve.

When he reflects on his work he might notice he can do better, so he will probably ask for a pairing session.

When he’s finished with the pairing session, he’ll want some unit tests to validate his work. He might get carried away and write tests for the whole application. He may even end up automating them all as well!

When he’s done, he’ll probably want to collaborate with his peers. You will fix a common work area for him, with a task board and a lava lamp. He’ll crawl in and make himself comfortable and break the build a few times.

He’ll probably ask you to read him a story, so you pull one off the backlog and read it to him, and he’ll ask you to see the tasks. When he looks at the tasks, he’ll get so excited he’ll want to implement one. He’ll ask you for an IDE and a CI server.

He’ll create a build. When the task is finished, he’ll want to review it for acceptance with the PO. Then he’ll want to update the task board. Which means he will need…sticky notes.

He’ll update the taskboard and stand back to look at it. Looking at the task board will remind him that he can do some more cool stuff, so…He’ll ask for another sprint.

And chances are if he asks for another sprint, he’s going to want another story to go with it.

The end.

Paraphrased from the marvelous children’s classic, “If You Give A Mouse A Cookie”, by Laura Joffe Numeroff & Illustrated by Felicia Bond