Agile takes discipline: having a strategy means saying “no” more than saying “yes”

With the Crowbar release behind us, it’s time for my team at Dell to do some Capital “P” Planning. Planning for us includes both tactical (next release) and strategic (the releases beyond the one after next), but each type of planning looks very different. I’m going to call it “roadmapping” because planning means something specific and tactical in Agile.

I love roadmapping but I’m a pain to roadmap with because I’m a ruthless prioritizer.

When I sit down for roadmapping, I always do it from a 1 to N list without ties. That means that when marketing asks for a new feature (double the foo on the bar!) we put it on the list relative to other work that needs to get done. If you add something at the top then something else will fall off the bottom. Effectively, we’re using the list to say no to a lot of great ideas. This is essential because “the great is the enemy of the good (Voltaire).” It’s hard, but that’s the cold reality of delivering product.

The most important part of strategy is figuring out what to push down to make room for the precious few yes items.

Successful roadmapping is negotiating the splitting of big ideas into smaller ones. Decomposition is a circular process because one compromise may require another, but one change may force a cascading assumption fault. If you get too emotionally committed to one feature or subset then you’re going to slow down the process. It’s vital to approach roadmapping in free fall.

As always, my advice is to not mix meeting objectives. If you need more strategy then you’ve got to make time for it.

Interested in more…stay tuned for Agile Tao: balancing tactics & strategy

Avoid false agreements and saying no with a yes. #TeamDeath

caution

One of my favorite things about Agile is how it helps teams get committed toward a shared goal.  There are so many distractions and confusions, that we need to double down ways to help people get and then stay on the same page.  In some cases, it comes down to something as simple as word choice!

First, I feel like I need some explanation…

There comes a time in any disagreement when the team needs everyone to get on the same page even if they don’t agree.  As a rule, this should be a relatively small window (maybe 20 minutes max) because the team can defer issues by having a sprint long spike* or exploration story that collects more information to settle arguments down the road. 

Personal Experience Note: A team should NEVER spend much time arguing about the mid or long-term future!  It’s just not worth the time to convince someone that your vision is more compelling.  It’s more efficient to accept that there are MULTIPLE VALID FUTURES and that the team needs to watch to see which one(s) is  taking shape.  There is no need to be “right” about the future.

So, back to the fake agreement phrases that effective teams avoid.

#1 “Yes, but…”

This statement really means “Will you shut up already?  I don’t agree.”  The speaker says “yes” to acknowledge the first person has finished; however, it does not mean that they agree.  The confusing thing is the speaker typically does not even realize that they are sending you into a discussion death spiral. 

Anytime someone says “but” then they are disagreeing.   Just for fun, trying have discussions where people are not allowed to say but – it creates a whole new positive dynamic.

#2 “I don’t disagree”

This statement really means “You are full of shit and my opinion is more right.”  The speaker is trying to avoid addressing your points directly and refocus discussion on their opinion.  Agreement means that everyone believes the same thing.  There are many ways to not agree and only one way to agree.

This is one of my pet peeves because the speaker thinks they are rewarding you with some back-handed pat on the head.  In reality, they shutting your ideas down without validation or acknowledgement.

There are many such statements that waste team time and mask disagreement.  If you have some that bug you, please comment on this post and add to the dialog.  I’m sure that I won’t disagree with any of them!

* Spike stories are time bounded stories that have specific research or opinion deliverables.  They are intended to collect enough information that the team can take action and move forward.   Sometimes these are also called “time box” stories.

Substituting Action for Knowledge – adopting “ready, fire, aim” as a strategy (and when to run like hell)

Today my mother-in-law (a practicing psychiatrist) was bemoaning the current medical practice of substituting action for knowledge. In her world, many doctors will make rapid changes to their patients’ therapy. Their goal is to address the issues immediately presented (patient feels sad so Dr prescribes antidepressants) rather than taking time to understand the patients’ history or make changes incrementally and measure impacts. It feels like another example of our cultural compulsion to fix problems as quickly as possible.

Her comments made me question the core way that I evangelize!

Do Lean and Agile substitute action for knowledge? No. We use action to acquire knowledge.

The fundamental assumption that drives poor decision-making is that we have enough information to make a design, solve a problem or define a market. Lean and Agile’s more core tenet is that we must attack this assumption. We must assume that we can’t gather enough information to fully define our objective. The good news, is that even without much analysis we know a lot! We know:

  • roughly what we want to do (road map)
  • the first steps we should take (tactics)
  • who will be working on the problem (team members)
  • generally how much effort it will take (time & team size)
  • who has the problem that we are trying to solve (market)

We also know that we’ll learn a lot more as we get closer to our target. Every delay in starting effectively pushed our “day of clarity” further into the future. For that reason, it is essential that we build a process that constantly reviews and adjusts its targets.

We need to build a process that acquires knowledge as progress is made and makes rapid progress.

In Agile, we translate this need into the decorations of our process: reviews for learning, retrospectives for adjustments, planning for taking action and short iterations to drive the feedback loop.  Agile’s mantra is “ready, fire, aim, fire, aim, fire, aim, …” which is very different from simply jumping out of a plane without a parachute and hoping you’ll find a haystack to land in.

For cloud deployments, this means building operational knowledge in stages.  Technology is simply evolving too quickly and best practices too slowly for anyone to wait for a packaged solution to solve all their cloud infrastructure problems.  We tried this and it does not work: clouds are a mixture hardware, software and operations.  More accurately, clouds are an operational model supported by hardware and software.

Currently, 80% of cloud deployment effort is operations (or “DevOps“).

When I listen to people’s plans about building product or deploying cloud, I get very skeptical when they take a lot of time to aim at objects far off on the horizon.  Perhaps they are worried that they will substitute action for knowledge; however, I think they would be better served to test their knowledge with a little action.

My MIL agrees – she sees her patients frequently and makes small adjustments to their treatment as needed.  Wow, that’s an Rx for Agile!

Dell to spin bare iron into OpenStack gold

I’m at the CloudConnect conference today supporting my team’s initial OpenStack foray.   Our announcement part of the Rackspace Cloud Builders announcement.

Tonight (3/8), we’re at the Rackspace Launch with a pony rack of servers (6 nodes) where we will run a LIVE DEMO of our cloud installer (codename “Crowbar”).  The initial offer includes my hyperscale white paper and our cloud foundation kit.

Interested in the details?  Here are background posts that talk about the Lean/Agile process we use, what is Crowbar, and my write up about hyperscale (“flat edge”) data centers.

Added 3/9: Links to articles about the release:

Here’s what Dell is saying about OpenStack on Dell.com/openstack:

Dell is one of the original partners in the OpenStack community, which has now grown to more than 50 companies and participants. To accelerate adoption of this powerful platform, Dell has worked to develop an effortless out-of-box OpenStack experience with:
  • Optimized PowerEdge™ C-based hardware configurations
  • A technical whitepaper that details the design of an OpenStack hyperscale cloud on PowerEdge C server technology
  • An OpenStack installer that allows bare metal deployment of OpenStack clouds in a few hours (vs. a manual installation period of several days)

Read more about the steps to design an OpenStack hyperscale cloud in a Dell technical whitepaper entitled “Bootstrapping OpenStack Clouds.”

Interested?  Contact OpenStack@Dell.com.

The Go-Fasterer OpenStack Cloud Strategy

Dell’s OpenStack strategy (besides being interesting by itself) brings together Agile and Lean approaches and serves as a good illustration of the difference between the two approaches.

Before I can start the illustration, I need to explain the strategy clearly enough that the discussion makes sense.   Of course, my group is selling these systems so the strategy starts a sales pitch.  Bear with me, this is a long post and I promise we’ll get to the process parts as fast as possible.

Dell’s OpenStack strategy is to enter the market with the smallest possible working cloud infrastructure practical.  We have focused maniacally on eliminating all barriers and delays for customers’ evaluation processes.  Our targets are early adopters who want to invest in a real, hands-on OpenStack evaluation and understand they will have to work to figure out OpenStack.   White gloves, silver spoons and expensive licensed applications are not included in this offering.

We are delivering a cloud foundation kit: 7u hardware setup (6 nodes+switch), white paper, installer, and a dollop of consulting services.  It is a very small foot print system with very little integration.  The most notable deliverable is our target of going from boxes to working cloud in less than 4 hours (I was calling this “nuts to soup before lunch” but marketing didn’t bite).

Enough background?  Let’s talk about business process!

From this point on, our product offering is just an example.   You should imagine your product or service in these descriptions.  You should think about the internal reconfiguration required needed to bring your product or service to market in the way I am describing.

There are two critical elements in the go-fasterer strategy:

  1. a very limited “lean” product and
  2. a very fast “agile” installation process.

The offering challenges the de facto definition of solutions as being complete packages bursting with features, prescriptive processes, licensed companion products and armies of consultants.  While Dell will eventually have a solution that meets (or exceeds) these criteria; our team did not think we should wait until we had all those components before we begin engaging customers.

Our first offering is not for everyone by design.  It is highly targeted to early adopters who have specific needs (desire to move quickly) that outweigh all other feature requirements.  They are willing to invest in a less complete product because to core alone solves an important problem.

The concept of stripping back your product to the very core is the essence of Lean process.  Along this line of thinking, maintaining ship readiness is the primary mantra – if you can’t sell your product then your entire company’s existence is at risk.  I like the way the Poppendieck ‘s describe it:  you should consider product features as perishable inventory.  If we were selling fruit salad and you had bananas and apples but no cherries then it makes sense to sell apple/banana medley while you work on the cherries.

Whittling back a product to the truly smallest possible feature set is very threatening and difficult.  It forces teams to take risks and guesses that leave you with a product that many customers will reject.  Let me repeat that: you’re objective is to create a product that many customers will reject.  You must do this because it:

  1. gets into the market much faster for some customers (earning $ is wonderfully clarifying)
  2. learn immediately what’s missing (fewer future guesses)
  3. learn immediately what’s important to customers (less risk)
  4. builds credibility that you are delivering something (you’re building relationships)

Ironically, while lean approaches exist to reduce risk and guesswork; they will feel very risky and like gambling to organizations used to traditional processes.   This is not surprising because our objective is to go faster so initially we will be uncomfortable that we have enough information to make decisions.

The best cure for lack of information is not more analysis!  The cure is interacting with customers.

Lean says that you need product if you want to interact meaningfully with customers.  This is because customers (even those who are not buying right away) will take you more seriously if you’ve got a product.  Talking about products that you are going to release is like talking about the person you wanted to take to prom but never asked.

To achieve product early, you need to find the true minimum product set.  This is not the smallest comfortable set.  It is the set that is so small, so uncomfortable, so stripped down that it seems to barely do anything at all.

In our case, we considered it sufficient if the current OpenStack release could be reliably and quickly installed on Dell hardware.  We believe there are early adopter customers who want to evaluate OpenStack right away and their primary concern starting their pilot and marketing towards eventually deployment.

Mixing Agile into Lean is needed to make the “skinny down” discipline practical and repeatable.

Agile brings in a few critical disciplines to enable Lean:

  1. Prioritized roadmaps help keep teams focused on what’s needed first but don’t lose sight of longer term plans.
  2. Predictable pace of delivery allows committed interactions with customers that give timelines for fixing issues or adding capabilities.
  3. Working out of order keeps the great from being the enemy of the good so that we delay field testing while we solve imagined problems.
  4. Focus on quality / automation / repeatability reduces paying for technical debt internally and time firefighting careless defects when a product is “in the wild” with customers.
  5. Insistence on installable “ship ready” product ensures that product gets into the field whenever the right customer is found.  Note: this does not mean any customer.  Selling to the wrong customer can be deadly too, but that’s a different topic.
  6. Feedback driven iterations ensures that Lean engagements with customers are interactive and inform development.

These disciplines are important for any organization but vital when you go Lean.  To take your product early and aggressively to market, you must have confidence that you can continue to deliver after your customers get a taste of the product.

You cannot succeed with Lean if you cannot quickly evolve your initial offering.

The enabling compromise with Lean is that you will keep the train running with incremental improvements:  Lean fails if you engage customers early then disappear back into a long delivery cycle.  That means committing to an Agile product delivery cycle if you want Lean (note: the reverse not true)

I think of Lean and Agile as two sides of the same results driven coin: Lean faces towards the customer and market while Agile faces internally to engineering.

Please let me know how your team is trying to accelerate product delivery.

Note: of course, you’re also welcome to contact me if you’re interested in being an early adopter for our OpenStack foundation kit.

Scrambled & Confused? Use Shorter Sprints!

As part of my Dell Agile coaching work, I comparing notes with another coach about a project was talking with collegue today about a team that was going into “scramble mode.”  In addition to being behind, they had a new manager without Agile experience.

My suggestion: Use Weekly Sprints!

You should consider short sprints in the following cases:

  1. New Team / Learning Agile (more time working together)
  2. Uncertain Requirements (more feedback from marketing)
  3. Behind Schedule (more delivery points and visibility)
  4. Prototypes / New Technology (more feedback from engineering)
  5. QA / Hardening Phase (more intergration points)

Shorter sprints (this team is on 3 weeks) have a proven record for boosting productivity, increasing teamwork and getting more accurate results.  As an additional benefit, the new manager gets to experience 3x more planning meetings and become more familar with how the process works.

The reason is simple: more planning means more feedback.

For many, shorter sprints seems contradictory to being more productive.  This aligns with my personal experience.  A team that plans in frequently generally plans inefficiently: long meetings, vauge committments, fuzzy tasks and poor estimates.  In many cases, the team simply does not remember what was planned by the last week!

Shorter sprints, while a lot of work to manage well, are generally much shorter.  Reviews cover less ground, retros are more concise, and planning has less ground to cover.  Weekly planning for a practiced team should be less than 4 hours.

Next time your team stumbles with Agile, consider shorter sprints as a way back to your normal pace.

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.

Agile Jumpstart – so you want to do agile?

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:

  1. Have the product owner create a 1 page advertisement for the product that you are working on.
  2. Create a prioritized feature list (1 to N, no ties) that covers immediate and longer term items.
  3. 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?

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.

Don’t confuse the decorations for the process!

Or “Icing is pretty, but you need a cake too!”

Good Agile Process books will explain in chapter 1 that the stand-ups, iterations, demos, retrospectives, long planning meetings, et cetera are all “decorations” for the process.  This is an important concept that gets completely lost when they spend the next 43 chapters talking about how the decorations are used to support the process.

The decorations are not the process!

Having stand-ups does not make you agile.  Doing work in sprints does not make you agile.  Using story- cards does not make you agile.  Doing retrospectives where people share honest feedback does not make you agile (but could help you become agile if you actually take the feedback).

Agile is a business discipline.

Agile teams have the discipline to focus on delivering a product that generates revenue.  Management supporting agile teams has the discipline to reward team work.  Product owners have the discipline to provide crisp actionable priorities.  Everyone has the discipline to be transparent and willing to adapt as the environment evolves. 

These disciplines are hard to build and maintain, but they are fundamentally valuable.  They are honest and practical.  They are revolutionary.

Now, if you embrace the agile disciplines then the decorations will reinforce your efforts like mocha fudge icing on a double-dutch chocolate groom’s cake.

Unfortunately, if you lack the discipline then the decorations become a whip used to micromanage teams into a long frustrating death march.  Sadly, I’m finding that this experience is the more common one in the industry. 

Bon appetite!