To keep pace with cloud innovations, my team at Dell drives aggressively forward. Agile is essential to our success because it provides critical organization, control and feedback for our projects. One repeating challenge I’ve had with the Agile decorations (aka meetings) is confusion between the name of the meeting and the process objectives.
The Agile process is very simple: get feedback -> decide -> act -> repeat
People miss the intent of our process because of their predisposition about what’s supposed to happen in a meeting based on it’s name.
Some examples of names I avoid:
Demo – implies a one-way communication instead of a feedback loop
Post-mortem – implies it’s too late to fix problems
Retrospective – implies we are talking about the past instead of looking forward
Schedule – assumes that we can make promises about the future (not bad, but limits flexibility)
Person-Weeks – focuses on time frame, not on the use cases we want to accomplish
Names that work well with Agile
- Planning – we’re working together to figure out what we’re going to do.
- Review – talking over work that’s been done with input expected.
- Roadmap – implies a journey in which we have to achieve certain landmarks before we reach our destination.
- Story Points – avoids time references in favor of relative weights and something that can be traded.
- Velocity – conveys working quickly and making progress. Works well with roadmaps.
We have recognize the powerful influence of semantics for people participating in any process. If people arrive with the wrong mindset, we face significant danger (IMHO, soul numbing meetings are murder) from completely missing critical opportunities to get feedback and drive decisions. Since We rarely review WHY we are meeting, so it’s easy to have people not engage or make poor assumptions based on nothing more than our word choice.
The most powerful mitigation to semantic confusion is to constantly seek feedback. Ask for feedback specifically. Ask for feedback using the work feedback.
Does this make sense? I’d like your feedback.
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:
- All that talking and listening and improving takes time and attention.
- Post mortem or “lessons learned” meetings that never make any difference because they happen after the work is done. (well, duh).
- No one has a methodology that makes the meetings productive.
- 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:
- Write everything down. All our planning meetings are documented. This is ESSENTIAL because we review our past notes.
- 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.
- Go until your team runs out of yellows.
- 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.
- 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.
- Go until your team runs out of blacks. This may take a long time if you’re just starting out!
- 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.
- 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.
- 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.
A friend of mine is part of a business that wants to use Agile and he was asking me how to introduce agile to a team that has never used it before.
Even before asking, he’s already well on his way because his team wants to drive it as a business process not just for development (win #1), has a committed product owner (win #2) and likes the Agile Manifesto (win #3).
My advice surprised him because it was pretty simple and did not include ANY REQUIRED MEETINGS. Here’s what I suggested:
- Have the product owner create a 1 page advertisement for the product that you are working on.
- Create a prioritized feature list (1 to N, no ties) that covers immediate and longer term items.
- Meet (ok, that’s a meeting) regularly to argue about the priority list as a team. I omitted that these would be sprints or iteration – the team will figure that out itself.
That’s it. I also strongly recommend including retrospectives but I always recommend retros and he knows that part of the team building subterfuge that is Agile.
His primary question after this was how to schedule and estimate work. My suggestion was to use a date driven release plan because it’s easiest to estimate billing if you use a calendar – cost = time * rate. To make that work, you must give frequent demos to the customer so they are on board with the deliverables. That’s the “easy” way.
If you want to predict when features will complete then use “story point” estimates. Basically, each feature is estimated on an exponential scale (1,2, 4, 8, etc). Big scary features will get big scary estimates. When you are closer to starting, then you can decompose the big scary estimate into smaller units. Ideally, you can decouple the work so that parts of the larger feature get done earlier and proven in the market. It all ties back into your ranked list.
Splitting large features into smaller component may create a very useful interweaving where high value parts of features get done quickly where “bonus” components never get done. Of course, this will drive engineers crazy because the don’t get to add those extras that create bloatware.
Overall, the goal of Agile is to create product the sells. Now, that’s not too hard to understand is it?