Porter's Five Forces

Another interesting idea from MindTools.com:

In business, power comes from these five forces.

Supplier power: more suppliers, less power for each one
Threat of new entry: if it's a profitable business, someone is likely to jump in to compete
Buyer power: big buyers can dictate terms (think Wallmart forcing Coke to give them a discount 10% lower than any other buyer, or Amazon taking 70% of newspaper revenues)
Threat of substitution: if there's another way to meet the customer need, maybe the customer will use that solution instead
Competitive rivalry: competitors tend to drive down the price to the "marginal cost of production"

Geert Hofstede cultural dimensions

While stereotyping can be misleading, sometimes it's practical. I just learned about Geert Hofstede's cultural dimensions study, started in the 1970s, where he categorized different cultural values. I was surprised, for instance, to see that the French have a lower rating for gender roles than Americans, but then again, my house is in the Mount Airy section of Philadelphia, a progressive haven that is not at all typical of the U.S. Still, this study rates dozens of countries along four or five axes, and may help us understand what is more valuable to people in different cultures:

PD: hierarchal vs cooperative leadership/power
IDV: individual vs community
MAS: clear, different gender roles vs gender equality
UAI: avoid uncertainty, like formal structure vs informal and tolerant of risk
LTO: long-term orientation, value family and education vs valuing shorter feedback and innovation

capitalize on learning styles to communicate effectively

When you're planning a meeting, retrospective, discussion, or training session, try to incorporate activities for each topic that cater to people that learn in different ways. While there may not be a scientific basis for the following categories, considering them can make your presentation more likely to engage more of the audience. The following are the Felder/Silverman learning style axes:

Sensory    <-->  Intuitive
Visual     <-->  Verbal
Active     <-->  Reflective
Sequential <-->  Global

These learning styles show a preference for:
Sensory: feeling/detail
Intuitive: theory
Visual: pictures
Verbal: words
Active: experiments
Reflective: plan
Sequential: details or steps used to build the big picture
Global: use the big picture to figure out where the steps should fit

Key characteristics of a performing team

Thanks to Gary Derbier for this concise summary... a performing team has these characteristics:

• everyone takes care of themselves
• everyone fully connects with each other
• everyone unanimously agrees on one objective and how to achieve it... this unanimous agreement should be so strong that every member of the team believes that this objective is the best real option, right now for reaching both our individual and group goals
  
• everyone expects that perfecting the team will perfect the product
  

Once a person has been part of a performing team, it is hard to enjoy team work without it.

Herzberg Motivation-Hygiene Theory

Today I read a bit about the the Herzberg Motivation-Hygiene Theory, which in a nutshell, expresses that there are two levels of needs for employees. If we want people to stick around, we have to prevent job dissatisfaction by meeting:

• their basic needs (keep the work environment sane, fair, with competitive benefits)
  
• their motivational needs (job satisfaction comes from challenge, recognition, autonomy, interesting work, and room for growth)

I used to say that a good manager does two things: gives employees autonomy (read: room to make mistakes), and challenges employees to grow. I'm finding out there are some prerequisites to this, and am trying to learn how to verbalize them.

deleting your way to success

Every once in a while, we get a story card that allows us to simplify a requirement or interface, and we get to "delete our way to success"... that is, we end up removing more code than we add, and maybe we don't end up adding any code at all. Today that's what my pair and I did for the first half of our card, and it's so liberating. We don't need to think much about code rot, tests, or any of it... just remove and verify we didn't break something else. Quick win!!!
Thanks to my colleague from Philly, Nolan, for coining this phrase!

effective delegation

Esther Derby's when to stand back, when to step in touches upon delegation. I'd like to comment on that, by merging some of what www.mindtools.com had to say about it. When we delegate, it's necessary to:

• describe the need/ultimate goal
• encourage sign-up for responsibility
• define authority depending on skills, how critical success is, and whether there's room to clean up any mistakes--should this person act independently, review plans with you, or review intermediate outputs before proceeding?
• once you've given out authority, you must hold back, even if mistakes are about to be made... being given the room to make mistakes is how we learn
  

my favorite lines from Derby/Larsen's Agile Retrospectives

A retrospective needs to happen in several phases:

• setting the stage (why are we here, time line, and check-in)
• data collection (put all the facts in front of the whole team)
• interpretation (as a group, look for patterns)
  
• decisions (propose options, then decide on what can be done by whom, when, and define acceptance criteria for the work)
  
• closure (ensure tasks have been assigned, thank participants)

The authors have lots of hints on how to facilitate group discussion (now we'll see if I can do all this in French):

• ask the group to build working agreements, and then just remind them to follow their own rules when necessary
• at every meeting, get every person to speak in the first 5 minutes
• check your assumptions... ask people what they think! pose clarifying questions to make sure you understand!
• to help everyone have a voice, incorporate small group work in the meeting
• retrospectives are for creative thinking--so do use innovative meeting formats
• when the facilitator speaks, this often stops group discussion
• when the group is stuck, ask them questions, e.g. about when they saw a similar problem in the past
  
• when things get heated, try asking "what is going on?/what just happened?"
• use a change in venue when the team bombs an iteration

They also present lots of group exercises, that I won't repeat here... I keep the book handy for retrospective preparation. These are a few general hints for leading group activities:

• most people can't absorb multi-step instructions
• debrief every activity
• after giving instructions, ask for questions
• shuffle time--it takes a few minutes every time we switch tasks in a meeting to get everyone on board with the next meeting--it could be 15 percent of the time!

tour de témis (taay-mees)

To promote shared vision in a team, to anticipate or ease over problems, and to help individuals deal with stress, I set a goal to spend at least 10 minutes in conversation with each team member every week. In practice, sometimes I only average 5 minutes, but I start out with something like the following.

Hey, Joe, wanna take a tour de témis? Joe may not be available, but if so, we step out of the team room and find somewhere quiet--outside or inside depending on the weather and mood. Then I'll ask one of the following questions, and record responses on an index card:

What are the strong points/weak points in the team?
What do you think about how we've been using timeboxing for meetings this week?
What will you do next week to help us finish the iteration by Thursday afternoon (instead of our normal Friday)? Do you think it's a good idea to finish early?

Then I use Appreciative Inquiry to dig deeper into what is going on with each team member.

story observer

The "story observer" role is something new to me--maybe only exists in my current team--but anyway, at least once a day this person walks around the room to remind pairs to consider whether they're blocked, ensures they're clear about the goal of the end-user, and asks whether they're still in scope of the story card. This observer, I suspect, is not necessary in a gelled/disciplined team, but in the early stages of forming, I think it can be helpful.

fixed-cost vs fixed-scope stories

When I first joined my current team, the team culture was that a story card's scope was non-negotiable. In accordance with the classic tradeoff triangle (scope-time-cost), that means they were constantly exceeding the story card estimates. I slowly distinguished between two types of ways of looking at a card, and I learned something in the process.

Fixed-scope: We understand the end-user's need, and we'll spend however much time it takes to meet that need. In this case, we value a well thought-out solution over feedback--so we should choose this only when end-user needs are well understood. The end-result of this process is a story card that is done-done, and the subject will likely not be revisited.

Fixed-cost: We understand the end-user's need, but the schedule is more important than functionality. We'll cut out features, robustness, or complexity so that we can deliver something that at least partially satisfies the end-user's need. As a by-product of this process, we'll write new story cards for everything that we temporarily cast aside. In this case, we value timely feedback from the timebox over completeness--so we should choose this option when we're unsure of the best solution or when doing research.

Pomodoro your way through Tuckman's FSNP model

As I mentioned previously, Agile can't be done without a performing team (Tuckman's Forming, Storming, Norming and Performing model), and I think this explains why I've been having so much difficulty getting our team to be more productive. We're more a loosely-coupled group of two-and-three person teams, each with different work styles and objectives. I've been working on bringing us together for 8 months now, and I've tried a few things. To clarify, when I say I, it really does mean we. That is, usually when I see something I don't understand, I go to another team member to find out if I'm the only one who saw it or not, and to find out if it's a problem. Often I work directly with my manager (Olivier) to get a feeling of the value/impact of the problem. Other times I work through the team, by asking the group a question during stand-up or a retrospective, or by speaking to people individually. Through this process, my original take on the situation is inevitably enhanced, and ultimately we build a new vision on how some of our work will be done.
The first thing I tried was to use retrospectives to find real pain points in the team... but not everyone agreed on what the highest priority items were. Then I tried using positive reinforcement of goals that I'd chosen. I wish I could say we chose these goals but there was no common consensus, so these goals were usually the collaborative output of Olivier and I, or the output of several team members... but for simplicity's sake I'm saying that I worked for the following. Please note that most of these changes were introduced to the team one at a time, and allowed to become habitual before moving on to the next item:

• more pair-swapping
• shorter story cards
• avoidance of black holes
• lighter-weight story card estimation
• emphasis on TDD rather than Test-After
• up-front face-to-face discussion with the client for every story card
• introduction of fixed-cost story cards
• focus on fewer changes so we can do those few well
• Agile Thought of the Day

None of this really created a gelled team, in fact much of it was probably just a distraction from our real problem (at least from my current perspective). It probably wasn't a waste, since these changes have become a valued part of our daily work, and have also helped to establish a level of trust in the work I'm doing. Still, this more effective group work didn't translate into a performing team. Why?
I felt like if I could get everyone to see and focus on one single problem simultaneously, that would become the shared vision that defines a performing team. I concluded that I needed to construct an unambiguous definition of success... which, again, I pushed for. I believe it would have been more effective to have the team define this success, but I couldn't get the group to agree on one goal. So, I said that an iteration was not a success if we hadn't moved all the story cards over to the DONE column by the end of the iteration. I shared this vision consistently and regularly at stand-ups, my turn as story-observer, at retrospectives, and with my pair. Slowly the team adopted this vision... slowly means it took 10 weeks! Since then, however, there's been clear consensus on whether an iteration is done or not... yet that didn't make a gelled, performing team! Now what?
I needed more information, more ideas. So I started doing one-on-one interviews with every person (12 total) in the team, every week. That's been effective at understanding how people feel, and in making other types of changes (like finishing our iteration before 8pm Friday nights... now we're done Thursday afternoon or Friday morning). So with these interviews, I discovered I wasn't alone in feeling like we weren't a gelled team... people wanted closer cooperation, stronger teamwork, but we just didn't know how to get there.
As I said before, XP Day France was a great opportunity for me. I now know we need to get through forming, and I figured that if I shorten the cadence, we'd learn quicker, we'd have more pressure, and communicate more... all setting up fertile ground for team forming and agile growth. So I suggested we try the Pomodoro technique (as a team) last Thursday. Afterwards, we decided that the practice was too complicated to evaluate in just one day, and Olivier decided we should try it for an iteration. Well, that iteration began this Monday, and few people actually read the free 40-page book (hooray--some people are giving it an honest shot), but for the rest I've been using the first long pause of the day to explain the practice in more detail.
Everyone uses the same, 25 minute timebox. After each pomodoro, we pause, then have a mini-standup, where the sole objective is to find out how the team is going to attack the remaining story cards. If someone is blocked, we might send help to that pair; if someone has something interesting to share, they do; otherwise, we may resume the task we were on before. The object is to efficiently select the most important tasks that remain.

The breaks are ad-hoc, and may involve a team-building game, drawing on the white board, or a walk outside. This has become self-organizing already--different people propose games or set up the timers. Just to note, we play games that stimulate the creative, left-brain, so that when people go to sit back down they're more likely to see creative alternatives in the new pomodoro.

On a larger scale, the objective is to add so much discipline that we start to storm.

I'm hoping that before this month is over, our team will just be able to sense when a pair goes dark, will know when to swap pairs, will know how to focus on the core need inside a story, and will hum like a hive, producing a continuous flow of honey (err, business value).

Alan Cooper's Keynote speech at Agile 2008

I've just been reading Cooper's keynote address from Agile 2008, and have found several interesting insights. First, he argues that we shouldn't be iterative in the implementation stages of software development... we should be only incremental. I see the waste of being iterative at the implementation level, but I don't know how to validate software reliably without deploying to the customer... but that is where he says Interaction Designers come in. They know how to reliably define the customer needs, how to interpret discussions, and then to translate them into what the developers can understand. Hmmm...



Then he starts talking about some of their training, training I know I don't have. Interaction Designers learn about common reasoning flaws, like (the following is paraphrased from Cooper's slides 82 and 83):

• Loss Aversion


• Value Attribution (initial perception counts more than contradictory evidence later)


• Commitment Bias


• Pygmalion Effect (self-fulfilling prophecies)


• Tyranny of small decisions (too much choice is paralyzing)


• Evolutionary Psychology (we're not machines, and don't always act logically)


• Abilene Syndrome (groups make choices that no one in the group even wanted)


• Memory Distortion (bad things are easier to recall)


• Hawthorn effect (just paying attention to people improves their performance)


• Stockholm syndrome (hostages fall in love with captors)

Interaction designers are designed to distill "requirements" into a clear definition of business need. I can identify with this idea, as I've heard of teams that thrash from one set of whimsical story cards to the next. When I worked in Philly, we had a product owner who was also visionary, who strongly defended the vision against customer requests that were inconsistent with this vision. At my current position we've been saying that we need that vision to be more effective, but no one is playing the role.

Next he argues strongly for prototyping. He says a prototype is necessary for validating the design... and it should be built in a very agile, lean fashion. Then once it's done, rebuild the whole thing from the ground up... I thought that refactoring was supposed to avoid rebuilding to such a large extent. There's a lot to think about here.

before you can do Agile

Before you can do agile with a team, you need a team! At XP Day France last week, a colleague and I started talking shop with Yves Hanouille, who re-introduced Tuckman's model of team growth to us. I've been frustrated for a while, trying to figure out how to get us to follow our own rules, and even suggested throwing out all the rules and starting over. Now I think we need to get through Storming before any of these rules have meaning... You can probably find better info online, but these notes will help me remember the key goals of each phase :

Forming: agree on goals/vision as described by leader (team lead is directive at this stage). Members hold back their own opinions in order to be polite, they mostly work independently on tasks.

Storming: (directive leader) there's a lot of competition for ideas, the team begins to select a leadership model, and roles are clarified

Norming: (collaborative leader) members compensate for each other, agree on rules/standards, and hold each other accountable

Performing: (collaborative leader) interdependent individuals with established conflict resolution mechanisms.

A group in N or P will fall back to S under stress, in which case the team lead will need to be directive again.


So I think a team needs to be at either N or P to do agile. It's possible that at F or S the directive leader of the group will impose an agile process... but it won't be self-organizing!