Information Density and Project Tracking

May 29, 2008

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.


Agile Planning Tools Revisited

May 28, 2008

Since my last post listing Agile planning tools a few more have come to my attention including:

Check ’em out. Thanks to those who helped by pointing me toward these products – I appreciate it!

Happy Planning,
Tom


Learning to Shut Up

May 27, 2008

You know, sometimes the hardest part of working with a team is learning to shut up. During the honeymoon phase of a project (forming), it’s easy to deal with the team with a reasonable sense of detachment. If they make a decision that you find questionable, it’s no big deal. When the team steps on that garden rake, Whammo! “Hey, I bet that really smarts!” You just shrug it off and move on.

Here are some real life “rakes”:

  • Maybe we should try CI?
  • What if we documented the architecture first?
  • How about we stick with the simple solution rather than the absurdly complex one?
  • Perhaps we should commit to less work this sprint?

The hard part is when you watch the team insist on performing the same failing maneuver for the 10th time. You’ve gently suggested that maybe they should watch out for that rake…and your words seem to fall on deaf ears! You beg, you plead, and here they go again! That’s when I’m most likely to completely lose it. My face turns red, I sprout horns, a tail, a forked tongue and I’m likely to “Lay down the law” We’re going to do it my way now – you boneheads!

I haven’t read “How to Win Friends and Influence People” but based on my own experience, I’m guessing that this technique is definitely NOT in that book. Here’s what I’ve been trying lately: shutting up. It’s kind of a matter of timing. I watch closely, and thwack! They do it again. I don’t say a word. So I watch a little more closely, and thwack! they do it again (Hey! This is kinda funny!). Once more, not a word. So now that I have the timing down, I wait for that next resounding thwack! Then, I’m there with the arm over their collective shoulders and a metaphorical icepack in the other hand. “I wonder how that rake got there?” I ask. “Geez, I bet that hurt!”

Somehow, the words are better received if I manage to keep my mouth shut and postpone my suggestions. I seem to get more value out of biting my tongue and keeping mum. Observing rather than proscribing. When I catch myself escalating toward a blowout – that’s when I need the most intense focus. It’s hard. There I am in the back of the room twitching like someone with Tourette’s syndrome. Talking to myself in the hallways. Arguing with my coffee mug. Banging my forehead on the filing cabinet. It ain’t pretty. I don’t always succeed at holding it all in. But, more often than not, the team is much more receptive if I have quietly observed and allowed them to have their own experiences.

And so what if they think I’m weird?


Agile 2008

May 24, 2008

Just a little plug for myself. I’ll be giving 3 different presentations at Agile 2008 in Toronto this August:

  1. Drifting Toward Invisibility: The Transition to the Electronic Task Board
  2. The Intermediate Customer Anti-Pattern
  3. Swarming – The Birds and the Bees and Agile

I’m tremendously excited to be given these opportunities to present at such a big event. If you’re attending, be sure to drop by and catch one of these presentations.

Best regards,
Tom

A few Ramblings on the Topic of Swarming

May 22, 2008

Here are a couple of definitions of swarming:

1 a: a great number of honeybees emigrating together from a hive in company with a queen to start a new colony elsewhere b: a colony of honeybees settled in a hive

2 a: a large number of animate or inanimate things massed together and usually in motion : throng <swarms of sightseers> <a swarm of locusts> <a swarm of meteors> b: a number of similar geological features or phenomena close together in space or time <a swarm of dikes> <an earthquake swarm>

From the definition it is apparent that the idea of a swarm is perhaps most commonly used to describe animal behavior. In this particular case, swarming refers specifically to the behavior of insects, namely ants, bees or locusts. However if we look at the broader expanse of animal behavior we can find similar behaviors in many different species. For example birds exhibit flocking behavior and fish are described as traveling in schools or shoals.

flock: a group of animals (as birds or sheep) assembled or herded together

school: a large number of fish or aquatic animals of one kind swimming together

These behaviors, swarming, flocking, schooling are much more than just simple groupings of animals. When observing these groups, there emerge new complex behaviors that serve to benefit the survival of the group as a whole. These groups or throngs form highly complex systems of interaction that are very difficult, if not impossible to predict. For example, from observation of the simple behaviors of any one individual in the group it is impossible to predict the actions of the group as a whole. Therefore, from a micro perspective, the action of the group can appear very chaotic. However, from a larger perspective, the macro view, a cohesive pattern of behavior may emerge.

For example, in the case of bees, when the hive reaches a certain density, the bees will form a swarm and seek a new home. They use a simple decision making strategy to select the optimal location:

The decisive moment didn’t take place in the main cluster of bees, but out at the boxes, where scouts were building up. As soon as the number of scouts visible near the entrance to a box reached about 15-a threshold confirmed by other experiments-the bees at that box sensed that a quorum had been reached, and they returned to the swarm with the news.

“It was a race,” Seeley says. “Which site was going to build up 15 bees first?”

Scouts from the chosen box then spread through the swarm, signaling that it was time to move. Once all the bees had warmed up, they lifted off for their new home, which, to no one’s surprise, turned out to be the best of the five boxes. The bees’ rules for decision-making-seek a diversity of options, encourage a free competition among ideas, and use an effective mechanism to narrow choices-so impressed Seeley that he now uses them at Cornell as chairman of his department. (Peter Miller, National Geographic)

So for the bees, a complex decision making strategy has evolved from the simple behaviors of members of the swarm. Observation of any single bee will not predict the outcome of the decision. It is only by observation of the group as a whole that the outcome can be foreseen. As a swarm, the bees are exhibiting a form of intelligence that is not present in any individual member of the group. This group is exhibiting complex adaptive behavior. The whole is greater than the sum of its parts.

As it turns out, there is an entire sub discipline of mathematics dedicated to describing just this sort of complex system. Chaos theory and complexity theory study the properties of simple systems that demonstrate emergent properties from apparent chaos. In combination with population biology, it is possible to create mathematical models that imitate the behavior of animal swarms in nature. One of the first people to do this was Craig Reynolds. He created a program he called “Boids” that modeled the flocking behavior of birds within a virtual 3D environment. With his program, you can apply very simple rules that control the behavior of a flock. The three rules are:

  • Separation: steer to avoid crowding local flockmates.
  • Alignment: steer towards the average heading of local flockmates.
  • Cohesion: steer to move toward the average position of local flockmates

From these three rules, we see very interesting behaviors in flocks emerge such as a flock that dynamically splits and re-joins to avoid obstacles. There are many of these sorts of models for flocks, swarms, and schools – all with different sets of simple rules that can be applied to the individuals in the group. It should be noted that in swarming theory there is the absence of central control. There is no manager bird that tells other birds how to fit in formation. These groups are self-organizing – obeying simple rules without any higher organizing authority present.

So, if we can use the mathematics of complex adaptive systems and chaos to model the behavior of animals, can we create similar models for the group behavior of crowds of people? Here we enter the field of economics and game theory. We are attempting to create a predictive model for the behavior of groups of people (organizations or markets). In “The Wisdom of Crowds” Author James Surowiecki does just that: he applies simple rules of behavior to individuals in a group to help explain the complex behavior that evolves in crowds.

Swarming theory has also found use in additional domains such as artificial intelligence and military applications. In AI, swarming theory is being used to manage swarms of tiny robots that collaborate to perform tasks (nanotechnology). In the military, swarming has relevance to both military tactics as well as for controlling the behavior of drones that are playing a larger and larger role on the modern battlefield.

So we find the notion of swarming, which originally came from the animal behavior, is actually applicable to a much wider array of domains. In fact, swarming actually has a mathematical models to back it up. So it appears that Swarming has a solid foundation in theory and a broad range of applicability. The question is, how can we apply the principles of Swarming Theory to Agile teams?

One great example of swarming is the Open Space meeting (an activity that is becoming increasingly popular at agile conferences). An open space is organized with the following four principles:

1.       Whoever comes are the right people.

2.       Whatever happens is the only thing that could have.

3.       Whenever it starts is the right time.

4.       When it’s over, it’s over.

These four principles are the only rules needed for an Open Space meeting. If you have an idea, you share it. If people are interested, they listen. If people are not interested, they move on. It enables a group to focus on talking about the most relevant issues for them, rather than being forced to sit through lectures from others that they may not be interested in. Using only these rules allows for unpredictable discussions to emerge. We don’t know in advance who will be talking. We don’t know in advance what topics will be the most interesting. All we do in an open space is create the conditions that allow those topics to emerge.

The key to making swarming work is applying the right rules.


The Planning Meeting from Hell

May 13, 2008

I was facilitating a planning meeting with the team a week ago and it was not going well. We had our stories all ready to go before the meeting. The stories were well formed. All we had to do was come up with a list of tasks for each story. How long could that take? An hour?

An hour later we finished the first of nine stories. It had taken us an entire hour to identify 3 tasks! It was like pulling teeth. I’d ask the team to provide a list of tasks…silence. I’d take different approaches, “how do we break the story down?” I’d suggest different kinds of tasks…silence.

I swear to God I don’t beat my teams with a stick. But the silence was ominous. Why couldn’t they come up with even the simplest tasks? I racked my brain trying to figure out what I was doing wrong. Was I intimidating the team? Was someone else?

Then it hit me. They didn’t know the architecture of the product! Of course they didn’t know what tasks they would need. They simply had no clue! I spent the next week working to make the architecture of the system visible to the team. Information radiators with diagrams of the static class design. Interaction diagrams, you name it. The next time we had a planning meeting, the tasks came quite naturally.