Category Archives: Planning & Estimation

Dietary Manipulation (Part 1) – Pizza

Posted on by
Reply
Reading time ~ 2 minutes

**Note, I’m not responsible for any health issues related to over-eating, poor diet, allergies, existing or hidden conditions or the quality of the pizzas ordered in. Eating pizza during training is a personal choice.

Covering story sizing in ~30 minutes needs creative ways to get through people’s mental road-blocks.

On a pure estimation course attendees are prepared to expand their estimation skills with no “selling” needed however if it’s a small component of a multi-day “agile” course people find it hard to fit in their heads. They need to mentally accept the basic concepts and then learn by doing.

I’ve developed a novel (and not very healthy) technique for getting through the “I can’t fit it in my head” barrier.

At the start of a course; during discussions on logistics, lunch, dietary needs etc. I say to the group:

“OK, this afternoon we’ll be covering story point estimation. This can get a bit contentious for those of you that are mathematically minded…”

“…For lunch today, if you are willing, I suggest you have a large helping of pizza. Once you’re fully loaded with carbs, we’ll start the afternoon session. The estimation stuff is about an hour in – where you’ll be close to your carb peak and won’t feel like fighting any more :)”

Then I make sure there’s just over half a large pizza per person available for lunch.

This sounds bad, but it’s not mandatory and I’ve been completely honest with attendees – I’ve not yet had anyone not comfortable to eat pizza.  **(see opening disclaimer)

I’ve also quietly planted the seed that although it’s tricky and abstract, I don’t want any trouble during that part of the session.

What we’ve done is collaboratively neutralize the barriers that prevent the theory going in so that the teaching is more like osmosis. Once the basics are gently brought in with some slides, chat and rather lethargic Q&A , the teams put the theory immediately into practice on their workshop exercises.

Now they get it – but without the mental trauma!

After another day’s immersion with the points they defined during the workshop exercises marked in the corner of each of their story cards, the seeds have taken hold sufficiently for teams to accept what they’re doing and use again outside the classroom.

Never underestimate the power of food & drink when teaching and/or learning.

Readiness to Serve

Posted on by
Reply
Reading time ~ < 1 minutes

A couple of years ago a friend said: (I’m paraphrasing here)

My team are paid a huge pile of money to do nothing most of the time.

As an analysis team for a financial institution their goal was to be immediately available at the first sign of an anomaly in the system. Like every other good analysis team in the city, their goal was to identify and find a means of exploiting the next new anomaly before anyone else in the world did. When the rest of the world catches up, their edge is lost – until the next time.

Many times I see organizations saving pennies on billions of dollars of revenue to ensure they keep their teams “busy” or “fully utilized”.

  • If your teams are always busy, how will they be able to cope with the next bump in the road?
  • If your teams are always busy, how will they be able to stop and see the big picture?
  • If your teams are always busy, when will they have enough time to stop and sharpen their tools?
  • If your teams are always busy, who is looking around to see what the rest of the world is doing?
  • If your teams are always busy, who will you have available to exploit the next change in the market before your competition?

Unless money really is that tight, staff up your teams or balance your investment portfolio not just to deliver your current needs but also provide sufficient capacity to be “ready to serve” when the next anomaly hits your market.

Blame

Posted on by
Reply
Reading time ~ < 1 minutes

When your project goes wrong because you’re dependent on another team, whose “fault” is it really?

  • When did you identify the risk?
  • What did you do to mitigate it?
  • What relationship did you build with the team you’re dependent on?

When did you start really collaborating to resolve the dependency?

Too often we throw our problems over the wall and blame the people that aren’t there to catch it for our own laziness.

  • Are we too lazy?
  • Are we too busy? (what else is more important?)
  • Are we secretly looking for someone to take ownership of our problem?
  • Are we cynically looking for a scapegoat?
  • Are we just incompetent?

Think about government lobbyists – they spend their entire time fighting for what they need to achieve…

If something is that important to the success of your goals, why aren’t you sat next to the people you need it from making sure it’s on the top of their priority list too?

YOU ARE RESPONSIBLE FOR YOUR OWN COLLABORATION FAILURES

Learning to Say “No”

Posted on by
Reply
Reading time ~ 2 minutes

The great thing about working with software development teams is that on the whole they’re a nice bunch of people who just want to get on and do the right thing.

The tricky thing in large-scale enterprise product development is that there’s often aggressive targets pushed through sales & marketing onto product managers.

A common response is to take a shotgun to the enhancement request backlog and ask for everything from the development teams and negotiate down from that point.

Craig Larman & Bas Vodde summarized this brilliantly using game theory in the second of their scaling agility books as the “your fault” game.

Assuming like many large companies you’re faced with the challenge of an annual commitment-based project/backlog and you’ve whittled that down to the best you can do; chances are your product manager will come back at some point through the year having visited a customer or partner and, like Columbo, ask for “just one more thing”.

Agile development is meant to give us the flexibility to do this right?

The typical nice guy response is “well… it’s going to hurt … but we’ll try”…

Great! When your team gets kicked around the room at the end of the year for failing to meet their release commitments, I’m pretty sure I know whose “fault” it’ll be.

FrAgile

So… Time to dig yourselves out of that abusive relationship, get a backbone and learn to say “No”.

OK. Maybe that’s a bit harsh. How about…

“Sure we’d absolutely love to do that but here’s everything we’ve already committed to for you. What would you like us to drop first?”

That still sounds pretty collaborative – but now it’s on your terms.

You’ve also just highlighted that being Agile doesn’t mean not making commitments if that’s what your business needs, it means managing your customers better.

If the previous “we’ll try” conversation is the norm for your teams, chances are this is the first time your product manager has ever been put in this situation. Don’t expect it to be pretty or easy. You’ll need to stand your ground and limit the options available.

I’m a fan of visual management so here’s my take.

  1. Take all the features you’ve committed to already and put them on cards or stickies.
  2. Draw a box around them so that there’s no room for anything else.
  3. Bring your product manager to the table, hand them the new feature or item they want on a card of similar size to an equivalent feature.
  4. Ask them to trade out something so that the card fits.
  5. Once the trade-out decision is made. Confirm any timing impact on the other features.
  6. Optional… (but recommended If you’re in a low-trust environment) Get the decision in writing recorded in whatever your system of record is.

If you can’t get your product manager in the room, do the same thing with excel and coloured blocks representing each feature in a pipeline. Adding a new feature in anywhere in that pipeline extends the end date. If you’re on a fixed-date commitment that means something falls off the end.

Simple?

Give this a try or adapt something similar for your own needs.