Tuesday, January 24, 2012

Sea Star Wars: A lesson in organizational change

Sometimes in order to make a change happen, all you need to do is change the environment.

This summer I witnessed a great example of this in a small but fantastic aquarium in Ucluelet, BC. When you see a sea star in the ocean or at the aquarium, you rarely or if ever see them move. However, the staff at the aquarium instigated a sea star race by changing the environment. They put the feared Morning Sun Star in the same tank with other sea stars including the very large Sunflower Sea Star. Once the other sea stars detected the presence of the Morning Sun Star they all started to move away from it as fast as they could. The sudden reactions and speed of those sea stars was a sight to see – a turtle would have been proud!

If you have analysts, developers, testers and users who don’t communicate very well you can help encourage better communication by changing the environment. Create a co-located space and then have them all work in that space together. The environmental change forces them to acknowledge each other’s presence and begin working together. Instead of “Hey, there’s a dangerous Morning Sun Star in here and I have to run away before it eats me”, you should get reactions like “Hey – there’s a user in here, I guess I’ll show them the changes I’m making to this screen to get some feedback”.


Subscribe to Winnipeg Agilist by Email

Wednesday, January 18, 2012

SOPA Blackout

I couldn't find a SOPA gadget for blogger, so in solidarity with all the other blackouts today here is a link to an article on why SOPA should concern you:

http://blog.reddit.com/2012/01/technical-examination-of-sopa-and.html

Here is the conclusion of that article:

"In Conclusion

It is my strong belief that both PROTECT IP and SOPA:
  1. Will not stop the piracy they are targeting
  2. Contain language that is highly ambiguous and extremely broad making them ripe for abuse, and
  3. Introduce regulation and enforce censorship on what should be a free and open internet."

Sunday, January 15, 2012

Estimating tasks in hours is local optimization. Stop doing it!

This weekend I was listening to Eliyahu M. Goldratt's "Beyond the Goal" where he expands on the Theory of Constraints. In chapter three I listened to him explain how estimating in hours is in fact local optimization and therefore "idiotic". Here is a portion of that chapter loosely transcribed:
"The way to ensure that the project will finish on time is to ensure that every task will complete on time. This is the local optima policy that leads to a huge conflict. Placing a person on such a project jeopardizes the most important thing for them - their own image.

Suppose you are this person and you are asked how much time will this task take? You are extremely reluctant to give any number. And when you give that number the Project Manager will try to squeeze it. Why are you reluctant? Because you know that the number you give is an estimate but that it will be converted to a commitment - because the project needs to finish on time.

So what situation does this place you in? This common procedure of turning estimates into commitments puts you into a huge dilemna. Why? The objective of every person is to be regarded as a reliable person by your boss, by your peers, by people. But what is the meaning of being reliable? For example, if you give a commitment and you don't meet it - once is ok. But if you give a commitment and many times don't meet them do you expect to be regarded as reliable? Of course not. So one of the conditions of being a reliable person is to meet your commitments.

Also - if you are fighting for something (an estimate) and then it turns out that you have exaggerated by a mile? If it happens once, fine. If it happens frequently, then you will get the name of someone who exaggerates wildly - so kiss goodbye the image as someone who is reliable. In other words, another consideration for being a reliable person is to not be considered as someone who exaggerates. Now look what is happening when I come and ask you how long it will take to finish this task?

Now look - whatever you do, you are doomed. This is a huge personal conflict. How do we in reality deal with this conflict? Let's face it - this conflict is so important we must find a way to break it. We want to not only be reliable, but to be considered reliable. How do we do it? We cheat.

So we finish our estimates on the nose and sometimes a little more. They become self fulfilling prophecies. If there is a danger of finishing too quickly we add some more tests, do a more thorough job, we add another function in, we check things a little more thoroughly, and we finish on the nose. Do you see what's happening?

Due to the result that our local optimization turns any estimate into a commitment, we have developed the habit of giving estimates which includes in it the safety. If murphy (i.e. Murphy's Law) doesn't hit, we waste the time rather than giving it to the next link in the chain or project. If we do give it to the next link then we are declared as exaggerating and next time they won't give us the extra time. So look what a horrible situation this is. And this... is what kills the project. This is totally idiotic"
When you read this story the first time you will likely notice there are several examples in there of how not to run a project, of poor leadership, and his concluding statement is a little harsh. As many commenters have pointed out, this style of project management is not similar to how we typically run agile projects. However, at the core of the story is the desire of each person to be reliable by meeting hourly estimates whether they are created by the team, by yourself, or by someone else. When I first listened to this argument I was fascinated by that part of it. So, if that part of his argument is correct, then what alternatives do we have if we need to estimate? (This paragraph has been updated based on the comments - thank you)

If your project requires an estimate:
  • Stop estimating tasks - hopefully the argument above has already led you to this conclusion. 
  • Don't estimate user stories in hours or convert relative points to hours. OK - I do understand that it can be valuable to look historically at hours vs. points, but don't use this conversion for guessing how long a task or user story will take.
  • Where possible, avoid asking how many hours are left for a task or user story. I understand why and how this information can be valuable, but understand the risk you take when you ask this question. 
  • If possible, estimate at higher levels (epics) rather than lower levels (user story).
  • Give broad project estimates with ranges like 1-2 months, 3-6 months, 1-2 years instead of doing detailed estimates. Most projects don't need a detailed estimate in order to determine if they should be completed or not. For many projects on our list we already have a good enough guess about their size to understand their value compared to the cost. (Unfortunately, as a consultant that usually doesn't include the projects I work on).
  • This logic also suggests that relative estimating might be dangerous. I still have to think about that one as there are significant benefits to exercises like planning poker even if estimates are not created as output.
If your project does not require an estimate:
  • Do a little song and dance!  
In either case, continue to break down your project into smaller projects and small deliverable pieces of value and working code. Build the high priority pieces first in an iterative  fashion. Make a decision about whether the project is done after each completed story or each iteration to avoid the problem described above - the temptation to finish on your estimated completion date. Continue measuring your progress using completed stories but consider using cycle time (average time to completion for all stories) vs. velocity (average number of points completed in a given time frame) to avoid some of the local optimization that could occur for each user story.

For further reading on the Theory of Constraints, check out any of Goldratt's books. I highly recommend starting with The Goal which is also available on iTunes Canada as an audiobook for $2.95.

Subscribe to this blog by Email

Monday, January 9, 2012

Silent Brainstorming

I read an interesting article earlier this week that summarized some of the latest research on brainstorming. The research found that group brainstorming (out loud) doesn't restrict the amount of ideas generated, but it does restrict the variety of ideas. By contrast, brainstorming as individuals allows a greater variety of ideas to be generated. They also found that once the ideas were generated, having a group discussion about the ideas was beneficial in order to combine and improve upon the ideas. Here are some interesting quotes:
"Cognitive fixation causes people to focus on other people's ideas and are, inevitably, unable to come up with their own."
"If the goal is to come up with a bunch of unique ideas or solutions to problems, then the group should be split up so that individuals can come up with their own ideas and these ideas can later be combined with other members' ideas."
"...a group session after an individual session might be the optimal brainstorming technique."
So how can you combine both individual and group brainstorming? Here is an approach that I have been using that I've put together based on my experiences facilitating and participating in other sessions. This approach can be used for any brainstorming session whether you are trying to generate user stories, ideas for a retrospective, or strategies for your community group.

Step 1: Establish the goal.
Make sure everyone understands the purpose of the brainstorming session. For many sessions this can be communicated to attendees before the meeting begins.

Note: If your group is larger than 10, I would recommend splitting the group up into several smaller groups for steps 2 through 5. The groups can present their best ideas to each other at the end of the exercise and re-open the discussion and voting at that point if appropriate.

Step 2. Individual (and silent) brainstorming.
Hand out post-it notes to everyone in the group. Ask each person to write down one idea per post-it until they run out of ideas. This part of the session should be performed in silence. There are a few cues to look for to understand when the group is done but the most consistent one I use is to watch their body language. When most of the group is leaning back or looking up, they are probably done. If you are having trouble reading their body language, a good rule of thumb is to wait until most people have at least 3-5 ideas written down. Also - be prepared with extra post-it notes in case someone runs out. I once had a participant say "I stopped thinking when I ran out stickies" ;).

Step 3. Describe your ideas
Once everyone has finished writing down their ideas, choose one person and ask them to describe their best idea and then place that post-it on the wall or the table. Continue going around the table asking each person to describe their top one idea until all ideas have been presented. It should take several rounds and each person will have the opportunity to present several ideas - one during each round. While the ideas are being described encourage everyone to keep writing additional ideas down. This allows the group to combine and improve upon ideas presented by others.

Step 4. Group the ideas
There are several ways to group the ideas depending on your group size.

a) If your group size is five or less I prefer using silent affinity grouping because it is fast and collaborative. Ask your team to silently group the ideas. Things that are similar to each other should be moved closer to each other. Things that are dissimilar to each other should be moved farther apart. Groups should form naturally and fairly easily. Once again, body language will help you see when they are done - usually 2-3 minutes.

b) If your group size is more than five I prefer to have one person group the post-its as they are presented because it is faster. Simply put the post-it near other post-its with similar ideas.

Once the groups are created you can name each group with a short title.

Step 5. Silent Voting
If you need to vote on the ideas or on the groups, I prefer using silent voting. Number each post-it and then ask each person to write down their top three on a post-it. Once all the votes are in, tabulate the votes to identify the top ideas.

Summary
This method of brainstorming combines the best of both individual and group brainstorming techniques and is consistent with the latest research. However, I initially started using it not because it conforms to the latest research but because it allows everyone to have a voice - the loud people can't dominate the conversation and the quiet people are given a way to contribute. That it reduces the effect of cognitive fixation when generating the initial list of ideas is an added benefit.

References:

Friday, January 6, 2012

User Scenarios and Lean Solutions

After reading the book Lean Solutions a few years ago it was easy to see that agile methodolgies are "Lean Solutions" in comparison to traditional methodologies, but I wondered how we could apply that knowledge to design and build Lean Solutions for our clients (yes, you can still build bad systems with agile). User Scenarios are one tool that can help.

Well written user scenarios put all the 'features' into a flow that is relevant to the user's value stream. They can help us design a solution as a unified value stream rather than just a bunch of features put together. From Lean Solutions:
"Companies must provide the goods and services consumers actually want, when and where they are wanted, without burdening the consumer."
For more information and an example, check out Jeff Patton's stickyminds article.