{squeaky lean}

Beat the competition. Be a slave to your development team.

In a company that has managers responsible for the success of a product, and developers who produce that product, the company's hierarchy normally places the managers 'above' the developers.

'Above' implies that it is the managers who request things of the development team, and the development team who respond on demand. Not the other way around.

And that, in the main, is how things are.

Thing is, it is this situation that damages the quality of a product and reduces the speed at which it gets to market. 

To fix this, once a manager has handed a project over to the development team, he or she should be answerable to that team, on demand, until the completion of the project. They should expect to be interrogated as and when the team require answers, and should be quick with decisions as and when the team need direction.

Why? Well, a few reasons, but the one I want to talk about here is context switching.

What is Context Switching?
Imagine your mother has asked you to bake a chocolate cake for a party this evening. You've not baked a cake before, but you're pretty excited about it.

  1. You get started, and soon realise you don't know which type of flour to use. You call your mother. She's playing poker and says she'll call back in an hour.
  2. You mow the lawn in the meantime. CONTEXT SWITCH No 1
  3. An hour later, your mother calls and tells you about the flour. Great, back to the cake. CONTEXT SWITCH No 2
  4. You spend 15 minutes going back over what you'd done so far to get yourself back up to speed. Baking and gardening require different mindsets after all.
  5. 15 minutes later you're wondering if it's ok just to use the chocolate egg you got for Easter.
  6. You call your mother again.
  7. She's spending her poker winnings on a spa treatment and can't be disturbed for the afternoon.
  8. You sigh, and decide to go and varnish the garden fence. Not as pressing a task as the cake, but it needs doing, so why not. CONTEXT SWITCH No 3
  9. At about 5pm your mother calls back.
  10. She says you need to get special cooking chocolate.
  11. You violently smash up the Easter chocolate with a rolling-pin. CONTEXT SWITCH No 4
  12. You trudge to the shop and come back with the chocolate. CONTEXT SWITCH No 5
  13. You read the recipe and retrace your steps for a third time. CONTEXT SWITCH No 6
  14. Your excitement about the whole cake thing has diminished substantially and suddenly you're not interested in how it will taste anymore, just about getting it done.
  15. Later that evening as people eat dry chocolate cake, your mother tells you you shouldn't have cooked it so long.
  16. You love your mother, but you spike her coffee with laxatives all the same. CONTEXT SWITCH No 7

What went wrong?

The cake went off track because when you needed more information, your mother wasn't available to provide it, so you had to stop working on it.

Your only choice was to switch to a different task and a different context.

Different contexts require different mindsets, knowledge and skill sets. Putting one set away, taking out another and getting the hang of it again can be exhausting and confusing if you have to keep doing it.

Context switching like this also makes it very difficult to keep tuned-in enough to spot mistakes, or to find those extra improvements that make a product great.

Is overall productivity effected?

Yes, because the context switching itself takes time. People don't move seamlessly from one to the other without losing momentum. Losing momentum by switching often can slow down projects drastically.

So what would have made the cake better?

Your mother answering your questions the moment you needed them answering. That way you could have just got on with it, keeping your momentum along with your excitement and pride in the quality of the cake.

Stop beating yourself up. The bad cake was her fault.

Anyway… back to business now please?

Yeah, sorry. Enough about cake.

As I've said, when 'management' hand the development team a project, they should then be answerable to the development team until the project is finished.

They need to be available to answer questions and to make decisions. Not at the next meeting, but as and when questions need answering and decisions need making.

But 'management' have things to do as well. Aren't you just passing the context switching problem to them?

Yep. And that's how it should be.

What?! Why?!

Because protecting those who produce your product from context switching, by swallowing it yourself, is what good managers do. It's what good management IS.

Good managers tell their team that they can call them or go see them when they need to. If you don't have time for these calls or visits then either:

  • Delegate this authority to someone who will, and forego the right to complain about the end product
  • Acknowledge that if the project isn't important enough for you to make the time, then the team shouldn't be working on it in the first place
  • Make time

Like this?


By Kevin Heery.

Google

Hit objectives quicker through Validated Learning. Here's how.

Validated Learning is another key concept in Eric Reis' Lean Startup book. He talks about how startups can learn from what they've launched already, to influence what they build next.

For bigger companies, installing a validated learning approach is more complicated.

The problem is that a lot of them see Agile like this:

"Yeah, Agile! We do that. We hand the dev team a prioritised list of things to build, and they tell us how much they can get done in 4 weeks.

We draw straws. Whoever picks the short one, goes to see the developers once a day to discuss progress. They do this at a white board with cards and coloured pens. And no-one's allowed to sit down in case they can't get up again.

At the end of the 4 weeks the developers will have built and launched all our stuff. We hand them a new list and they start again. I think we pay them in cake."

Sounds good right?

Actually, there are two things wrong with it:

  1. It assumes that whoever hands the dev team the prioritised list is the rare kind of genius that knows exactly what should be done and in what order. That they need no feedback at all to help them grow your company faster than mere mortals could possibly achieve; and
  2. It assumes that the products are always perfect first time, every time. That you can just launch them and forget them, confident that the world will be enthralled by their sheer magnificence. And without a single tweak required.

Thing is:

  1. They're not that rare kind of genius; and
  2. Products are never right first time

Assuming we're agreed on those two points, we should try to change the way we do things to accommodate them.

So along with our developers, editorial team, sales people and anyone else with a say in what the dev team do, we need to always:

  1. Improve our knowledge of which products and features will delight our audience; and
  2. Check that the products and features we launch are having the desired effect on our audience

The good news is that just by doing number 2, we get number 1 for free!

Validating launched products and features

I'm assuming that your dev team is using an Agile approach to development. If not, at least go and sort that bit out first. I don't care which flavour of Agile they use, just that the basic concepts are being followed.

Done? Good. Your dev team should be proudly standing by a whiteboard that looks like this:

Good for your dev team. Now get everyone else to join in.

Everyone needs to feel responsible for whether or not the products and features being delivered are the right products and features to deliver. And everyone needs to feel responsible for wether or not they are performing as well as they could be.

To achieve this, all you need to do is:

  1. Make sure, as a team, you've agreed your objective along with an immediate KPI to improve. Read objective setting for dummies for more on this
  2. Write the KPI, the current score and a target score on the top of the whiteboard
  3. Add a column to the end of the workflow board entitled 'Validating'

User stories (Agile speak for a feature that needs building) normally finish their journey across an Agile workflow board once they're released to the live environment and no bugs show up. They are considered DONE.

But not when you add a Validating column.

The story would instead move from DONE to VALIDATING, meaning that the team are in the process of measuring and monitoring the story to decide wether it's working in business terms. I.e. If it is positively effecting the chosen KPI.

I recently launched a pilot programme to try this approach at the company I work.

How WE do it

Every two weeks, about 10 people who work on a brand website: publishing, editorial, development, and in some cases even the Managing Director, will stand at the board and discuss the stories in the validated column.

By this time, the product manager will have ensured there is results data against the chosen KPI, and they will have written the relevant numbers under the story card.

As a story's merits are debated, there are three possible outcomes for it, each of which normally trigger an action:

    1. It is proven to be a success and gets to live out its days proudly in the 'Good Idea' envelope at the bottom of the board
      Actions:

      • New similar stories might be generated because of its success.
      • Some further A/B testing might be agreed, to see if its results can be improved even further
      • Related stories in the backlog might be prioritised higher because there is more confidence that they will improve the KPI
    2. It is deemed a failure and is vanquished to the 'Bad Idea' envelope at the bottom of the board
      Actions:

      • The product or feature might rolled back so it can't do any more damage
      • Related cards in the backlog might be removed, ripped up and binned
      • We may learn that it was our approach that was flawed, rather than the idea, and a new story is generated to do it the way it should have been done first time round
    3. It's deemed too early to tell if it is a good or a bad idea
      Actions:

      • We might agree to wait another two weeks to debate again
      • We decide wether or not related stories should be put on hold until this one is validated
As you can see from the pic below, we weren't as harsh as to actually call the envelopes "Good idea" / "Bad Idea", but you get the idea:validated learning envelopes

Once this debate is finished, we go into a meeting room and build a backlog for the next two weeks with all of this data and debate fresh in our minds.

This is Validated Learning.

We've been doing it this way for 3 months and the sense of pace towards a focused goal has increased significantly.

Also, because everyone is motivated by the KPI, there is a natural collective push for Minimum Viable Product. The team now crave fast feedback through metrics. They know they can get it quicker by first validating a less sophisticated version of the planned end product, so they do.

Overall, they are more engaged because they always have a common goal and are regularly measuring themselves against it. As a team.

And suddenly, the trusty workflow board has developed from:

  • a tool used to help a product manager and a dev team work through their backlog of work,
  • to a tool used by the wider business to pinpoint the tactics required to hit the business' objectives.

And its the same £100 white board it was before. Pretty good value if you ask me.

So, in summary:

  1. Pick a KPI
  2. Add a VALIDATING column
  3. Debate the value of things in the Validating column regularly
  4. Take action based on the outcome of these debates

And that's Validated Learning.

Like this?

OR

By Kevin Heery.

Google