Forward-looking Reviews: Feedback loops essential for Agile success

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.

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.

Process (not a dirty word!) means knowing how you make decisions

“Process” is the least* understood business word.  I hear it talked about as something that must be added or introduced into various organizations so that they are more controlled.  Most typically, we tend to think of process as a synonym for “going to more meetings.”  So I want to set the record straight.

Process means knowing how your organization makes decisions.

There is nothing more to it than that.  If you know who will make a decision (the product manager), when they will make it (during the planning meeting), and what input they use to make the decision (a product roadmap) then you have a well defined process.  Ideally, you’d also know when you are able to influence the input (quarterly roadmap review or sprint retrospective).

Unfortunately, everyone wants to be able to make decisions all the time.  Making decisions all the time really means that you never make any decisions!  If there’s no agreed time, place, or person to make and communicate the decisions, it is impossible for anyone to know what’s the company is supposed to accomplish.

The default solution is to have meetings, meetings, and more meetings.  These meetings have lots of status updates, impassioned discussions, clever powerpoint slides and the appearance of consensus; however, they universally lack any commitment to execute work.  In the end, individuals doing work follow their own priorities or spin in the prevailing management wind.

So the next time someone suggests that your organization needs to work on a process, start by figuring out how you are going to make decisions.  After that, the rest of the process is just decoration.

* MRD ranks as a close second, but confusion is reduced since it’s as synonym and homophone for the French “merde.”

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.

Getting cozy with “Adjacent Services”

I’ve had a busy week with Azure Training and Cloud Camp Seattle.  It’s going to take a few days to unwind specific posts about both, but I wanted to hit some shiny new thoughts.

Services helping each other

  • Adjacent Services are dedicated and/or public services (XaaS) that are offered along side generic public cloud offerings.   For a company like Dell (my employer), this could be specific brands of storage or databases (e.g. Oracle).  I believe these are much higher margin XaaS than IaaS.
  • Layer 7 Load Balancers represent a more intelligent link between load direction and the applications. I heard people using this term in multiple contexts.   For example,  In Azure, the apps can set themselves as “offline” and they will stop getting traffic then they can turn themselves online when they are ready for more.
  • Cloud Rollout/Migration is a rolling upgrade scheme where you can send traffic to 2 versions of your application at the same time!  You upgrade by zones and if you have >2 zones then you’ll have two active versions at the same time.  Your data models need to accommodate this.
  • We don’t have enough Agile Cloud programming books (like Dave Thomas’ RoR Intro).  We need a cloud programming book that STARTS WITH INTEGRATION TESTS and shows how to use all the adjacent services.  I may just have to write one (or three).

Thanks to many many at Microsoft for the great Azure training sessions.  I’ll add more names, but for now I have links to Steve Marx (Smarx.com) & Srirm Krishnan (Sriram Krishnan.com) .

Cloud Culture Clash Creates Opportunities

In my opinion, one of the biggest challenges facing companies like Dell, my employer, is how to help package and deliver this thing called cloud into the market.  I recently had the opportunity to watch and listen to customers try to digest the concept of PaaS.

While not surprising, the technology professionals in the room split into across four major cultural camps: enterprise vs. start-up and dev vs. ops.  Because I have a passing infatuation with pastel cloud shaped quadrant graphs, I was able to analyze the camps for some interesting insights.

The camps are:

  1. Imperialists:  These enterprise type developers are responsible for adapting their existing business to meet the market.  They prefer process oriented tools like Microsoft .Net and Java that have proven scale and supportability.
  2. MacGyvers: These startup type developers are under the gun to create marketable solutions before their cash runs out.  They prefer tools that adapt quick, minimize development time and community extensions.
  3. Crown Jewels: These enterprise type IT workers have to keep the email and critical systems humming.  When they screw up everyone notices.  They prefer systems where they can maintain control, visibility, or (better) both.
  4. Legos: These start-up type operations jugglers are required to be nimble and responsive with shoestring budgets.   They prefer systems that they can change and adapt quickly.  They welcome automation as long as they can maintain control, visibility, or (better) both.

This graph is deceiving because it underplays the psychological break caused by willingness to take risks.  This break creates a cloud culture chasm. 

On one side, the reliable Imperialists want will mount a Royal Navy flotilla to protect the Crown Jewels in a massive show of strength.  They are concerned about the security and reliability of cloud technologies.

On the other side, the MacGyvers are working against a ticking time bomb to build a stealth helicopter from Legos they recovered from Happy Meals™.  They are concerned about getting out of their current jam to compile another day.

Normally Imperialists simply ignore the MacGyvers or run down the slow ones like yesterday’s flotsam.  The cloud is changing that dynamic because it’s proving to be a dramatic force multiplier in several ways:

  1. Lower cost of entry – the latest cloud options (e.g. GAE) do not charge anything unless you generate traffic.  The only barrier to entry is an idea and time.
  2. Rapid scale – companies can fund growth incrementally based on success while also being able to grow dramatically with minimal advanced planning.
  3. Faster pace of innovation – new platforms, architectures and community development has accelerated development.  Shared infrastructure means less work on back office and more time on revenue focused innovation.
  4. Easier access to customers – social media and piggy backing on huge SaaS companies like Facebook, Google or SalesForce bring customers to new companies’ front doors.  This means less work on marketing and sales and more time on revenue focused innovation.

The bottom line is that the cloud is allowing the MacGyvers to be faster, stronger, and more innovative than ever before.  And we can expect them to be spending even less time polishing the brass in the back office because current SaaS companies are working hard to help make them faster and more innovative.

For example, Facebook is highly incented for 3rd party applications to be innovative and popular not only because they get a part of the take, but because it increases the market strength of their own SaaS application.

So the opportunity for Imperialists is to find a way for employee and empower the MacGyvers.  This is not just a matter of buying a box of Legos: the strategy requires tolerating enabling embracing a culture of revenue focused innovation that eliminates process drag.  My vision does not suggest a full replacement because the Imperialists are process specialists.  The goal is to incubate and encapsulate cloud technologies and cultures.

So our challenge is more than picking up cloud technologies, it’s understanding the cloud communities and cultures that we are enabling.

DevOps: There’s a new sheriff in Cloudville

DevOps SherrifLately there’s a flurry of interest (and hiring demand) for DevOps gurus.  It’s obvious to me that there’s as much agreement between the ethical use of ground unicorn horn as there is about the job description of a DevOps tech.

I look at the world very simply:

  • Developers = generate revenue
  • Ops = control expenses
  • DevOps = write code, setup infrastructure, ??? IDK!

Before I risk my supply of ethically obtained unicorn powder by defining DevOps, I want to explore why DevOps is suddenly hot.  With cloud driving horizontal scale applications (see RAIN posts), there’s been a sea change in the type of expertise needed to manage an application.

Stereotypically, Ops teams get code over the transom from Dev teams.  They have the job of turning the code into a smoothly running application.  That requires rigid controls and safe guards.  Traditionally, Ops could manage most of the scale and security aspects of an application with traditional scale-up, reliability, and network security practices.  These practices naturally created some IT expense and policy rigidity; however, that’s what it takes to keep the lights on with 5 nines (or 5 nyets if you’re an IT customer).

Stereotypically, Dev teams live a carpe diem struggle to turn their latest code into deployed product with the least delay.  They have the job of capturing mercurial customer value by changing applications rapidly.  Traditionally, they have assumed that problems like scale, reliability, and security could be added after the fact or fixed as they are discovered.  These practices naturally created a need to constantly evolve.

In the go-go cloud world, Dev teams are by-passing Ops by getting infrastructure directly from an IaaS provider.  Meanwhile, IaaS does not provide Ops the tools, access, and controls that they have traditionally relied on for control and management.  Consequently, Dev teams have found themselves having to stage, manage and deploy applications with little expertise in operations.  Further, Ops teams have found themselves handed running cloud applications that they have to secure, scale and maintain applications without the tools they have historically relied on.

DevOps has emerged as the way to fill that gap.  The DevOps hero is comfortable flying blind on an outsourced virtualized cloud, dealing with Ops issues to tighten controls and talking shop with Dev to make needed changes to architecture.  It’s a very difficult job because of the scope of skills and the utter lack of proven best practices.

So what is a day in the life of a DevOp?   Here’s my list:

  • Design and deploy scale out architecture
  • Identify and solve performance bottlenecks
  • Interact with developers to leverage cloud services
  • Interact with operations to integrate with enterprise services
  • Audit and secure applications
  • Manage application footprint based on scale
  • Automate actions on managed infrastructure

This job is so difficult that I think the market cannot supply the needed experts.  That deficit is becoming a forcing function where the cloud industry is being driven to adopt technologies and architectures that reduce the dependence for DevOps skills.  Now, that’s the topic for a future post!

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?

Juxtaposition: Dave McCrory joins Dell Cloud Team & Quest acquires Surgient

Rarely in my life have I seen true juxtaposition as in the last few weeks.  Mearly hours after my long time friend and cloud conspirator, Dave McCrory, joined our team at Dell; the company that we founded, Surgient, was aquired by Quest software.  Neither of us had been there for years and had been looking for ways to work together again.  Apparently the cosmos required that we could not join forces while our first effort together was still standing.

Cloud Walker

Our cloud team at Dell is full of people who like to both dream and do.  Now that we added Dave, I am expecting BIGGER things.  We’re actively planning coordinated blogging about some of the issues and inspirations that are driving our plans.   Those topics include Dev-Ops, PaaSvsIaaS, and the real “private” cloud.

Dave, welcome back to the party!

Here’s what Dave posted:

A lot has occurred since my last blog post. I am continuing the development of my technology and working in the Cloud, however I have chosen to do this with a great team at Dell. I was approached a while back about this opportunity and as I dug deeper and saw the potential I began to buy in. Finally after meeting the great team of experts involved behind the scenes I decided to join them.
I have worked with some of the team members before including Rob Hirschfeld. Rob and I founded both ProTier (note that PODS ran on VMware’s ESX) and co-founded Surgient together (interestingly Surgient announced its acquisition by Quest Software last week). Rob and I have created a great deal of IP (Intellectual Property) in the past together, including the First Patent around Cloud Computing (This was filed as a Provisional Patent in 2001 and a Full Patent in 2002). Our time at Dell should produce some new and great work in the Applied Architectures and Intellectual Property sides.

Annual Performance reviews hazardous for team performance

Performance Review Game

You don’t have to go farther than your own personal experience to know that annual reviews completely fail to motivate, inform, or protect people.  If you’re own experience is not enough try comparing notes with peers, reading JoelOnSoftware, and PeopleWare by DeMarco.

If you’ve got a great performance from an individual, a review is likely to hamper it.  If you’ve got a great team then individual reviews are likely to sabotage it.  Really.  This is 100% true and there’s plenty of research to back it up.

Managers – if you are relying on performance reviews to create great employees and teams then you’re feedback is way way way (way) too late.  If you are relying on inventive pay to build your feedback is not only too slow but likely to cause more problems then you imagine.  Most of these systems only show employees that they are not valuable and build up your (the manager’s) ego.  If that’s not intuitive to you then you need to educate yourself.  Read and learn.  It’s not too late!

Here’s an NPR article supporting the evidence:  Annual Job Review Is ‘Total Baloney,’ Expert Says.  Employee performance reviews should be eliminated, according to Samuel Culbert: “First, they’re dishonest and fraudulent. And second, they’re just plain bad management.” The UCLA business professor has written a new book expanding on that view.