I respectfully disagree – we are totally aligned on your lack of understanding

Team FacesOccasionally, my journeys into Agile and Lean process force me down to its foundation: cultural fit.  Frankly, there is nothing more central to the success of a team than culture. That’s especially true about Lean because of the humility and honesty required. If your team is not built on a foundation of trust and shared values then it’s impossible keep having the listening and responsive dialog with our customers.

Successful teams have to be honest about taking negative feedback and you cannot do that without trust.

Trust is built on working out differences. Ideally, it would be as simple as “we agree” or “we disagree.” In an ideal world, every team would be that binary.    Remember, that no team always agrees – it’s how we resolve those differences that makes the team successful.  That’s something we know as “diversity” and it’s like annealing of steel to increase its strength.

Unfortunately, there are four  modes of agreement and two are team poison.

  1. Yes: We agree! Let’s get to work!
  2. No: We disagree! Let’s figure out what’s different so that we’re stronger!
  3. Artificial Warfare:  We disagree!  While we are fundamentally aligned, everyone else thinks that the team does not have consensus and ignores the teams decisions.  We also waste a lot of time talking instead of acting.
  4. Artificial Harmony: We agree!  But then we don’t support each other in getting the work done or message alignment.  We never spend time talking about the real issues so we constantly have to redo our actions.

I’ve never seen a team that is as simple as agree/disagree but I’ve been at companies (Surgient) that tried to build a culture to support trust and conflict resolution (based on Lencioni’s excellent 5 dysfunctions book).  However, there’s a major gap between a team that needs to build trust through healthy conflict and one that wraps itself in the dysfunctions of artificial harmony and warfare.

If you find yourself on a team with this problem then you’ll need management by-in to fix it.  I have not seen it be a self-correcting problem.  I’d love to hear if you’ve gotten yourself healthy from a team with these issues.

Signs of artificial agreement syndrome include

  1. Lack of broad participation – discussions are dominated by a few voices
  2. Discussions that always seem to run to the meta topic instead of the actual problem
  3. Issues are not resolved and come up over and over
  4. People are still upset after the meeting because issues have not been resolved
  5. People have different versions of events
  6. Lack of trust for some people to speak for the group
  7. Outcomes of decision making meetings are surprises
  8. Lack of results or missed commitments by the team

Go read “Liquid Leadership” (@bradszollose, http://bit.ly/eaTWa6): gaming=job skillz, teams=privilege & coopetition

I like slow media that takes time to build and explain a point (aka books) and I have read plenty of business media that I think are important (Starfish & Spider, Peopleware, Coders At Work, Predictably Irrational) and fun to discuss; however, few have been as immediately practical as Brad Szollose’s Liquid Leadership.

On the surface, Liquid Leadership is about helping Boomers work better with Digital Natives (netizens).  Just below that surface, the book hits at the intersection of our brave new digital world and the workplace.  Szollose’s insights are smart, well supported and relevant.  Even better, I found that the deeper I penetrated into this ocean of insight, the more I got from it.

If you want to transform (or save) your company, read this book.

To whet your appetite, I will share the conversational points that have interested my peers at work, wife, friends and mother-in-law.

  • Membership on a team is a privilege: you have to earn it.  Not everyone shows up with trust, enthusiasm, humility and leadership needed.
  • Video games position digital natives for success.  It teaches risk taking, iterative attempts, remote social teaming and digital pacing.
  • Netizens leave organizations with hierarchal management.  Management in 2010 is about team leadership and facilitation.
  • Smart people are motivated by trust and autonomy not as much pay and status.
  • Relationship and social marketing puts to focus back on quality and innovation, not messaging and glossies.  Broadcast (uni-directional) marketing is dead.
  • Using speed of execution to manage risk. Szollose loves Agile (does not call it that) and mirrors the same concepts that I expound about Lean.
  • Being creative in business means working with your competitors.  My #1 project at Dell right now, OpenStack, requires this and it’s the best way to drive customer value.  The customers don’t care about your competitor – they just want good solutions.

PS: If you like reading books like this and are interested in a discussion group in Austin, please comment on this post.

Black Hat Feedback Essential For Cloud Success

It’s been too long since my “Agile in the Cloud” blog focused on the agile process side of the equation.  Since my theme for 2011 will be “Doing is Doing” (meaning, attending meetings and building powerpoint is NOT doing); it’s vital to embrace processes that are action and delivery focused.  Personally, I tend towards the Lean side (Poppendieck & Ries) of the Agile process spectrum.

Let’s start with something so obvious that most teams don’t bother with it:

The secret to improving your performance is to regularly work to improve your performance.

There is no further magic, no secret sauce, no superhero team member, and no silver process bullet that substitutes for working together to improve.  A team that commits to improving will ultimately transform into a high performing team.  Hmmm…that seems like a desirable result.  So why is it so uncommon?

Unfortunately, many teams skimp on improvement because:

  1. All that talking and listening and improving takes time and attention.
  2. Post mortem or “lessons learned” meetings that never make any difference because they happen after the work is done.  (well, duh).
  3. No one has a methodology that makes the meetings productive.
  4. Lists with more than 3 items on them have too many items to be productive for improvement activities because of reader’s limited attention spans.  Doh!

So #1 and #2 just take some resolve to resolve.  My (atypical) team at Dell spends 1 to 3+ hours every biweekly sprint talking about process improvement (aka retrospective).  That’s nearly half of our planning day and a pretty significant investment; however, it’s the one part of the meeting that no one is willing to shorten.  It just that damn productive, important, and enlightening.

If you’re committed to taking the time to improve then finding a methodology (#3) is a piece of cake by comparison.  I highly recommend De Bono’s Six Thinking Hats the framework for retrospectives.  Michael Klobe taught me this process and I’ve used it successfully on many teams.  Here are some guidelines to retrospectives (we call them “Hats Meetings”) using De Bono’s hats:

  1. Write everything down.  All our planning meetings are documented.  This is ESSENTIAL because we review our past notes.
  2. Start with “Yellow” hats from all team members.  Yellow hats are accolades, complements, thanks, generally positive news, and anything that the team can celebrate.  Yellow hats get the meeting opened on a positive note.
  3. Go until your team runs out of yellows.
  4. Write down and number the “Black” hats.   Black hats are things that impacted team performance.  Ideally, they are concrete and specific examples of a problem and a cost.  Black hats are NOT solutions or suggestions hidden as complaints.  If you’re frustrated that people are late to meeting then a good hat would be “people being late to meeting is costing us 10 minutes of productivity because we have to restart the meeting 3 times.”  Hats like “The vendor messed up” are not as helpful as “The vendor’s late delivery of the futz dinger caused us to work over the weekend.”  Good black hats are a learned skill and are essential to success.
  5. Do NOT record every detail when writing down a black hat.  You just need to capture the ending understanding of the person who brought up the item (not of the team).  I’ve seen many hats that would have been a huge HR problem if we wrote down the starting idea but the ending hat was perfectly ok.
  6. Go until your team runs out of blacks.  This may take a long time if you’re just starting out!
  7. Come up with a “Green” hat for each Black hat.  Green hats are ways that the team or individuals will solve the problem addressed by the Black hat.  Solutions should be practical and immediate.  The team must discuss the solution (free fall) - it cannot be imposed by one member.  In many cases, solutions will go in steps: “everyone will try to show up on time” would be a good hat for my example above.  If that does not work, then future hats may involve “the late person pays $1/minute late.”  The point is that the team agrees on how they will improve.
  8. Don’t worry about White (data), Blue (new ideas), or Red (frustration, issues beyond your control) hats for now.  They are not critical for retrospective meetings.  Sometimes our team has a black hat that is really red.  If you’re arguing over a hat, then it may be red.  Stop fighting and move on.
  9. At your next meeting, review your past Green hats.  This is where accountability and improvement happen.

Please don’t expect that these meetings will be easy – they are messy and potentially emotional.  Since we’re talking about teams of people, we have to expose and resolve issues.  Investing the time upfront allows for continuous improvement and prevents building up larger issues.

Hats provides a durable structure for getting issues on the table in a productive way.

Screening Recruits for Agile Savvy

We’re hiring new managers and developers into my team and its important (to me) that we find people who will embrace our Agile processes.

Sadly, many people experience with the fluffy Agile decorations and not its core disciplines; consequently, interviewees will answer “yes, I’ve done Agile” and not really (IMHO) know what they are saying.

So I wanted to craft some questions that will help identify good Agile candidates even if they have no experience (or negative experience) with the process.

  • Explain a time that you did not agree with a design decision that was being made. [Good candidates will tell you that they had a healthy debate about it, made sure they were heard, and then supported the team decision.  Excellent candidates will give you a specific case where they were wrong and the outcome was better their suggestion.]
  • How have you handled the trade-off between shipping quality software and getting a release done on time? [Good candidates will be pragmatic about the need to release but own quality as their responsibility.  Excellent candidates will talk about implementing TDD and automation so that quality can be maintained throughout a release cycle.]
  • How have you made changes to your work habits based on retrospectives? [Good candidates will tell you about items where they had to acknowledge other people’s suggestions and change their behavior.  Excellent candidates will be excited about having ownership in their team’s continuous improvement and can give examples.]
  • Why are sprint reviews important? [Good candidates will say that it’s important for a team to show progress to other groups.  Excellent candidates will tell you that it’s how a team shows that it is meeting its commitments and getting feedback to improve the product.]
  • Is it possible to achieve the objective to be “ship ready” at the end of each sprint? [Good candidates will say that ship ready is a great target but only practical in the last sprints before a release.  Excellent candidates will explain that being ship ready is a core driver for the process that ensures the team is focused on priorities, quality, and breaking work into components.]
  • Tell me about the best performing team that you’ve been part of. What made it a great team? [Good candidates will tell you about having quality people or a very tight focus.  Excellent candidates will tell you have the shared goals of the team and how people gave up individual recognition to accomplish team objectives.]
  • What does it mean to for a team to be transparent? [Good candidates will talk about status reports and documentation.  Excellent candidates will talk about being willing to take risks and fail fast.]

If they can’t pass theses questions then go buy a lifeboat.  You’ll want it for that that waterfall you’re going to be riding down shortly.