Tuesday, June 30, 2009
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"
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
Monday, June 29, 2009
Sensory <--> Intuitive
Visual <--> Verbal
Active <--> Reflective
Sequential <--> Global
These learning styles show a preference for:
Sequential: details or steps used to build the big picture
Global: use the big picture to figure out where the steps should fit
Friday, June 19, 2009
- 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
Thursday, June 18, 2009
- 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)
Monday, June 15, 2009
Thanks to my colleague from Philly, Nolan, for coining this phrase!
- 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
Friday, June 12, 2009
- 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)
- 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
- 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!
Tuesday, June 9, 2009
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.
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.
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).
Friday, June 5, 2009
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.
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!