September 04, 2006
Pair Problem Solving - Sudoku!
In a training course I recently delivered, I tried a new simulation exercise. Using the game Sudoku, I divided the class into two groups: a group that would solve the game in pairs, and a group that would solve the game solo. My hope was that I would be able to demonstrate some interesting aspects of working in an agile team, particularly around communication and problem solving.
The setup for the simulation exercise was fairly simple: print out the same Sudoku puzzle multiple times, give the group basic instructions about how to do the puzzle, divide the room (1/3 are solo, the other 2/3 pair up), hand them out flipped upside down, make sure people had pencils, and then let people work on the puzzles for ten minutes.
After ten minutes, everyone put down their pencils and we listed out how many spaces had been filled in for each solo/pair. Since some people did not know how to do the puzzle, there was a large variation in the actual times.
The interesting part came with the discussion.
One important observation was that a person who was experienced at solving Sudoku puzzles felt hindered by having to work with someone who wasn't experienced. It was difficult for the experienced person to take the time and explain every time why he was putting a number in a particular spot.
Someone else mentioned that she felt time-pressure and did not enjoy that.
These two observations together led to a good discussion about how agile methods timebox everything and therefore there is always time pressure. However, scope pressure is meant to be relieved somewhat so there should be time to help bring junior / new team members up to speed. The frustration we feel when trying to work with someone who doesn't know how to do the work is often because we feel time pressure - we are impatient. Agile methods use timeboxing as a counter-intuitive way of relieving the time pressure.
There was also some discussion about how problem-solving for Sudoku may be easier in pairs because it is easier to search the overall solution space. Some of the pairs tried putting numbers in randomly and then seeing if the placements resulted in inconsistancies. Although no one solved the puzzle in the ten minutes given, there was a feeling by the pairs that their approach may have been able to solve the puzzle fairly quickly. This is something to explore further!
One person working solo said that she had felt frustrated because she did not understand the puzzle. That immediately led to a pair piping up and saying that even though both of them had never done Sudoku before, they felt mutual support and therefore it was fun rather than frustrating.
The next time I try this, I would like to try solo, pair and trio work. I would also like to give better instructions: that the puzzle should be solved purely using logic, no guessing, that the puzzle has exactly one correct solution (and making sure I have it available for comparison). I would also like to give the class fifteen minutes instead of ten minutes to work on it. I will start collecting times to see if there are any statistically significant relationships between group size and number of cells correctly filled in.
Posted by Mishkin Berteig at 03:15 PM | |
August 24, 2006
Waterfall, Lean, Agile Simulation Exercise
Last December, I wrote about a nice simulation exercise that can be done in a small group to demonstrate the difference between waterfall, lean and agile approches to work. I have now run this exercise approximately 40 times and I would like to share the results.
I should note that these results are eyeball statistics, not carefully tracked statistics.
For Round One, using a waterfall large-batch approach to processing pennies, the results are such that the first and all pennies are completed simultaneously. Typically, the processing time is as follows:
1st Done: 55-65 seconds
All Done: 55-65 seconds
Once in a while there are outliers on the long side: up to 130 seconds. This is usually caused by a team member misunderstanding the instructions or making a large error e.g. dropping all the pennies.
For Round Two, using a lean production line with small batches, the results are substantially better for all the pennies being completed, and much much better for the completion of the first penny. This corresponds to the early and continuous delivery of value that working in small batches can enable. The processing time is typically as follows:
1st Done: 4-8 seconds
All Done: 25-35 seconds
People in my courses are usually astonished by this difference. But it gets even better.
For Round Three, using an agile team working simultaneously on all stages of the penny processing, the gains continue, particularly in how quickly all the pennies are processed. These excellent processing times are as follows:
1st Done: 3-5 seconds
All Done: 15-20 seconds
Although proportionally, this isn't as big an improvement as that between rounds one and two, it is still a substantial change.
Usually in discussing this exercise, the group is concerned that processing pennies is nothing like developing software, managing a business, etc. because there is so much knowledge and skill required to do these real-world things.
Although this concern is legitimate, nevertheless, my own real-world experience confirms that these levels of improvement are possible. One large organization that I worked with has tracked many projects using waterfall, lean and agile approaches and has observed these types of improvements in terms of initial delivery of finished work, and final delivery of all scheduled work.
Posted by Mishkin Berteig at 07:11 PM | |
May 31, 2006
The Human Touch
If you are given a problem to solve, how much does the presentation of that problem matter to your ability to solve it? Imagine that it's a simple problem... imagine that it is presented in two different ways, both of them simple. It turns out that presentation differences can still make a huge difference. In fact, there is a way to present problems that makes them substantially easiers to solve: make them people problems.
In The Tipping Point: How Little Things Can Make a Big Difference
Consider the following brain teaser. Suppose I give you four cards labeled with the letters A and D and the numberals 3 and 6. The rule of the game is that a card with a vowel on it always has an even number on the other side. Which of the cards would you have to turn over to prove this rule to be true?
Go ahead and take a few moments to figure that out before continuing on to the answer, and keep track of how long you work on it...
The answer is two: the A card and the three card. The overwhelming majority of people given this test, though, don't get it right. They tend to answer just the A card, or the A and the six. It's a hard question. But now let me pose another question. Suppose four people are drinking in a bar. One is drinking Coke. One is sixteen. One is drinking beer and one is twenty-five. Given the rule that no one under twenty -one is allowed to drink beer, which of those people's IDs do we have to check to make sure the law is being observed?
How long does it take you to figure that out?
Now the answer is easy. In fact, I'm sure that almost everyone will get it right: the beer drinker and the sixteen-year-old. But, as the psychologist Leda Cosmides (who dreamt up this example) points out, it is exactly the same puzzle as the A, D, 3, and 6 puzzle. The difference is that it is framed in a way that makes it about people, instead of about numbers, and as human beings we are a lot more sophisticated about each other than we are about the abstract world.
Now unless you had heard about this before, I suspect you were pretty suprised. I know I was! I always considered myself to be a very good abstract thinker/problem solver. In fact, I considered myself to be well above average in that regard for a number of reasons: I was always very good at math without every memorizing a single formula (I always made them up as I went along as long as I remembered the _idea_ of the formula), I was an excellent programmer in a number of different computer languages including assembler, Miranda, Java, Prolog, Pascal, and Objective-C, and finally, I'm always solving problems by moving the problem to a new level of abstraction - solving the meta-problem first.
So what does all this have to do with agile work methods? Quite a few things actually:
1. Obviously, if you can frame a problem as a people problem, it will be easier to solve... and most problems start out this way!
We tend to try to abstract problems, make them more generic or general purpose in the hopes that they can be communicated more precisely and can be solved in a way that will accomodate contingencies we haven't thought of yet. But all the effort we put into abstracting the statement of the problem ends up costing us doubly: in the initial abstraction and in the difficulty of solution that results. So if you have a team that is solving a people problem, make sure to keep it a people problem when you give it to the team!
2. If you have a problem that is given to you in an abstract form, try to convert it to a people problem before trying to solve it.
In all likelihood, the moment you do the conversion, you will quickly see the solution. It may even feel like the process of de-abstraction is a problem-solving process. You may have to make really odd connections to make the problem a people problem but it will likely be worthwhile.
3. Dealing with people rather than abstractions on a day-to-day basis will always result in a more effective interaction.
Sending printed documents, writing emails, manipulating symbols are all interesting ways to communicate, but fundamentally, you are communicating with other people. If you can make that communication as direct as possible - phone, video conference, in-person - then there will be far less effort involved in understanding the communication, and far more effort can be allocated to high-bandwidth communication. This obviously has special relevence for teams: get people in the same room as much of the time as possible.
In the software world, there is one technique that I give teams and that is the use of Personas to assist in solving a software problem. The place I first encountered Personas is in the excellent book The Inmates Are Running the Asylum
The bare essense of the Persona is to create a fictional person who represents a user or actor or stakeholder or customer of whatever it is you are building. This fictional person should have a name and all conversation about the thing being built should be couched in the personal language of these Persona's names. A Persona should also have a short history, a photo and some description of their needs, goals or desires. All of this helps to frame everything about a software project as a people problem... and thus makes it much easier to discuss and solve.
Posted by Mishkin Berteig at 11:12 PM | |
August 10, 2005
Optimizing a Team Room
Some less-obvious hints for creating a team room that promotes collaboration and effective communication.
- don't underestimate the importance of plants and natural light for overall morale and health
- encourage the team both individually and as a group to personalize the team space: kid's art, photos, trinkets, food, special chairs/ergonomic stuff
- encouraging a playful atmosphere if your group is quiet and shy is easier in a bullpen and this in turn leads to better morale
- encourage the team to notice traffic patterns (both physical and communication) and optimize the space to account for these patterns
- play games in the team room during lunch breaks or after-hours and have the results of the games as part of the visual environment
Posted by Mishkin Berteig at 03:13 PM | |
July 18, 2005
Sociometry and Team Building
I was recently introduced to the term "sociometry". As it turns out, my introduction to it was a little mis-defined. If you follow the link, you will find that sociometry is basically a measurement of relationships between people. What I was introduced to has some aspects of sociometry in it. I tried it out on a team that I am coaching. Here is what we did:
Team Building
1. If the members of the team have not worked closely together previously, start with introductions, name and role/experience.
2. Go around the group again, this time each person describes something about themselves that the others likely do not know. It could be something personal, like a hobby, or it could be something professional, like a previous career. The idea here is for everyone to learn something new about everyone. This usually can end up with exclamations of suprise, laughs, and general fun for the group.
3. Simple self-organizing starts with a group exercise of sociometry. The people in the team organize themselves into a line based on length of time they have been involved with the current organization/workplace/community/association. This is a fairly easy exercise since it is an easily quantifiable measure. Sometimes interesting things come up like that everyone has "been there" for a long long time, or that everyone is really new.
4. The team then does another sociometric self-organizing exercise. Here, each individual asks themselves what proportion of the creative or innovative capacity is actually put into use in their current role. How much opportunity is there to be creative? Again, the group organizes itself into a line from least creativity to most creativity. Note: this is not a self-assessment of how creative one is, just how much of one's creativity is in use! After the group gets lined up, it is important for the facilitator to get people to describe why they placed themselves in their location and to encourage discussion around creativity in their work.
Posted by Mishkin Berteig at 11:09 AM | |