Archive for October, 2011

So willing to SUCCEED that not seeing FAILURE coming: the difference between urgency and panic

Defer Commitment + Deliver Fast!

Recently I observed an interesting trap one team fall into. When asked how confident guys feel about hitting the target, they was almost jointly saying they’re absolutely confident, however burndown chart  trend told me they won’t make it.

Well, I am absolutely sure that this is what we all want to have – 100% confidence, however here’s the dangerous trap.

We may stay satisfied and oversee problems (or pretend that tomorow the problems will be gone). Or try not to rise them. Or feel uncomfortable rising them. Or think that others will feel uncomfortable if we raise them, etc…

But, they will NOT disappear. Problems usually have tendency to pile up… And when such a team recognizes that, it’s already too late…. and painful.

Kaizen mindset and “Toyota way of Lean Leadership” cultivate culture of  “continuous crisis” that requires continuous improvement . Only having daily cultivated feeling of urgency and need, maintains the rhythm of tense and productive environment that reduces risk of facing a FAILURE.

As Toyota management team stated in 2010:

“We realized we need to develop a grater sense of urgency, in our business. Success is good, but without urgency serious weakness sets in, customer focus declines, creative ideas dry up and before you know it, you’re in trouble”.

So here is the trick to recognize: before you know it, you’re in trouble.

But the word and concept has negative tone and may have de-motivating impact on a team. How to make it distinct and positive?

Here is an advice…

Unlike panic or hysteria, urgency is a constructive, ordered and focused sense, therefore it should not de-motivate. Simply because it results in targeted and the only correct decision and action. Deffer commitment + deliver fast, guys!

To illustrate this imagine fighter aircraft pilot that needs to make the only correct decision and act accordingly within 10 seconds left before he may crash. And here is the difference that also proven by multiple real-life cases:

  • Panic: an ordinary pilot most likely starts to hit all buttons around (maximizes focus and work-in-progress) or worse, thinks about death (we will fail…), not believing that this happens to him (we will not fail, I do not see problem, it’s not about us/me…);
  • Urgency: trained pilot usually freezes for 7 seconds (analysis, defer commitment), makes decision, then within 3 remaining seconds quickly does (focused, fast) the only correct action to stabilize aircraft;

Feel the difference?

A takeaway is simple: stay open-eyed with reality, constantly challenge your confidence, do not fall into trap of satisfied optimism, distinguish among your will and reality, spread urgency around and stay hungry © for constant improvement.

, , ,


How long does it take us to context switch?

Came across an interesting study (Quality Software Management: Systems Thinking by Gerald M. Weinberg) that draws relation between number of tasks in progress and time wasted for context switch.


So if you are running two projects (do two tasks) paralleled, waste caused by brain context-switch is 20% (and you’re able to use effectively only 80% of your time), for three it’s getting worse – 40% wasted (only 60% used), etc…

The mechanics behind are simple: according to psychiatric studies when our brain is juggling different tasks, it is also trying to arrange focus and attention to those tasks. Therefore when we attempt to perform two complex cognitive tasks, the brain must shift its focus to manage one task at a time. This process is identified as “reaction-time switching costs” and represents a measurable period of time in which the brain is moving its focus from one task to another pretty much as computer’s CPU does.

The other consequence is that we get tired earlier, since switch itself eats-up brain energy and we are not able to do 100% switch (we’re not CPU, we’re humans!), so it is more like having main part of brain focused on one task, while some small part of it still stays with next (past) one.

All this makes limiting WIP (work-in-progress) vitally important to both productiveness and human health.

, , ,


Thank you Jeff!

I had my CSM training in Stuttgart, Germany this spring where I first met Jeff Sutherland.

Well it wasn’t just that… training. Listening how he describes Scrum creation and rationales behind each artifact/ceremony/role was an experience! Having him answering simple and tough questions (and not only about Scrum) had helped a lot!

I felt as I occasionally discovered new dimension of Agile where everything I knew until then immediately got the depth, with lots of insights to generate own ideas.

It was two remarkable days with Agile evangelist, Scrum co-inventor,  and great Scrum practitioner.

Thank you, Jeff!

, ,

Leave a comment

Selling Agile to a customer in 10 steps

It happens often that Agile teams have to deal with fixed price contracts and have to “sell” benefits and idea of Agile project management to the customer.

From the fist look Agile may be obviously beneficial, however getting customer there is not that trivial as it may seem to.

Let’s take an example I’ve came across recent times.

An online service wanted to have new web application developed (for certain reasons I cannot specify it’s name). It turned to a team, giving high level detailed specifications and asked for estimates (both budget and time-wise).

Or another one: “… we’ve got budget fixed and cannot afford us more. Can we get our application for it then? How we can have guarantee that we’ll cover key functionality we need, ha?”

Or… “Just tell me when it’ll be ready and how much it’ll cost”.

Well, the scope is usual trap here. Customers may have a rough idea about scope (in some cases they could have even detailed specs defined). In both cases it ends up  having either nothing specified or too much specified making them hardly answering realistic scope question and leaving team being not able to forecast or making dangerous guesses.

Familiar cases, aren’t they?

To address situations like these I combined my sales experience with known Agile benefits and came up with simple 10 step practice.

Here I go…

To get the point how to sell best it’s needed to get closer to the reasons why your customer demanding to have fixed contract: most likely he may want to be sure he will NOT spent more budget or time then he has in mind to to get the imaginary scope.  There may be plenty of other reasons as well…

Only getting answers will help you to prepare your deal properly.

Here are simple steps I found working dealing with fixed contracts:

1. Prepare (before you start): think of the reasons and ways to make sure you understand limitations and rationales for fixed contract for your particular customer. Stop here and think!

If you’re not sure you understand those, do not sell as you’re not prepared yet and you may offer wrong benefits, operate using wrong terminology, stress not important aspects, etc… This is key point. Prepare your deal before moving forward (I promise another post to explain how to get clear and move forward).

2. Set the stage: explain Agile (SCRUM) rules without selling them at this point (just simply telling how it works and what it looks like  process-wise from customer perspective). It is important that at this point you still do not “sell”, just take time to explain Agile. Get feedback cautiously and to see if  customer gets it. Continue explanation until he gets a full picture and feels confident with “mechanics” described. It is also important not to overdo it: it should be easily understood, sound light-weight and non-technical at all;

3. Step forward: offer first planning session for free (this works). This will help customer to both get more involved and feel more secure moving forward. Explain that by this you’ll mutually try collaboration with each other “softly”.

4. Involve (offer help): some clients want to (or like to) develop specifications on their own, some want to have contractor or 3rd party side PO doing this. In both cases customer needs some help getting started with story writing as it requires knowledge and practice.

5. Agree on conditions of satisfaction of each feature (aka Definition of DONE), since it will have an impact on estimations. Do not be technical here if you deal with business people (or be if you asked to explain it to CTO or a tech guy). Again be cautious here: some tech guys have their own opinion on what is important (is not) that is hard to change (and also wrong). It may be that you end-up knocking into the closed door if you start offering without asking what is considered as important first place.

6. Follow up after first planning session by helping to re-calculate to contract details:

  • story points to time, knowing team baseline (assuming established team with agreed baseline of estimation);
  • sprints required (knowing team average velocity) to the budget required;

It may be required  to estimate entire scope. There are known techniques to do so. Goal here not to be exact (since you’ll never be) but to create feeling how much features customer gets approximately for a single sprint budget and/or how many sprints it will take to cover entire project. Usually this impresses (because Agile teams are way more faster than others). Then move forward and SELL!

7. Sell: stress that with Agile business is riskfree, since your customer will:

  • avoid big-bang integration and “surprise parties” (by releasing as early as possible);
  • observe potentially shippable software every sprint, having all required qualities-in (DoD);
  • be able to adjust what features are most beneficial per sprint and ensure that team working on top important ones;
  • be able to get end-user experience early to steer the product in the optimal way further;

If you’ve done everything correctly already here you should have READY customer. But he’s not fully there yet (or still has some doubts). Stop. Ask for doubts directly. Take your time to explain. Continue until all doubts are addressed. But you need a final “stroke” make customer feel more confident.

8. Pause (optional): there are two options how to continue at this point.

  • Let customer “sleep over” with everything above (I usually do that), but it depends on what extent is your customer “boiled” here. Short waiting is good, because it lets sale process within customer’s organization to take place (aka “inside sale” stage). Involved managers discuss here and come to the point to sign/not to sign contract with you.
    But here’s the trick I apply: you should try to know by when decision shall be  made and act a bit up-front in time (#9). Because if decision is made it may be too late (in many organizations it usually is).
  • Continue if you sure customer is ready for another “strike”;
9. Propose flexibility: at this point you need to make customer feel that you do not want to get money for nothing and care about most targeted and optimal way to spend his budget. To do this you may offer:
  • option to terminate contract at any time after sprint review session (with some benefits for you, of course).
  • option to swap features and do changes in scope at any planning session.
Use another strong argument:  ~65% of features are non or rarely-used and ask why customer wants to pay for non-profitable features? Pause. Ask again.
Usually these arguments have dramatic effect on people in charge of budgets, since  they are very natural and convincing.

10. Close your deal.

That is it. Let’s call it : Prepare->Set the Stage->Step Forward->Involve->Agree->Follow up->Sell->Propose flexibility->Close
Good luck in sales 🙂
Further reading:
Money for nothing, Change for free approach:


Leave a comment

Roadmap Planning: “steering” with product map

Roadmap planning is indispensable part of Agile project management that represents second level of 5 levels of agile planning that any team should somehow cover. As a best practice suggests it needs to be done by product owner every ~2-6 months, depending on the intensity of development.

  This exercise makes sure that entire team understands direction, goals and vision of the product team, brings many benefits and speeds things up by creating shared clarity about future and maintains high focus on the “vector” PO gives.

Recently I’ve facilitated Roadmap planning session applying  two techniques: planning poker and story map. For those who want to get details of both techniques I would recommend  nice extract from Mike Cohn’s “Agile Estimating and Planning”: and this nice article at Jeff Pathon’s blog:

It was both interesting and challenging, especially since we’ve never try this before. It was great success since resulted in having clear, estimated and planed Roadmap for product fist steps.


  • To share product roadmap and vision;
  • To make challenges and risks visible and clear and address them early;
  • To make approximate measurement the minimum required scope of the release of the product;
  • To predict possible release date range / manage product scope in the way to hit deadline;


  • PO prepared items (user stories and/or themes) written on index cards (one per card);
  • Items were grouped according to the story map (by corresponding key product functional areas);
  • Key area titles were stick to the glass wall at our big conference room;
  • Horizontal line was drawn to separate the first release content over the wall;
  • Scrum team in one room for 2 days;


  • PO presented key functional areas of the product being built, briefly describing what each area covers;
  • PO started presenting item after item, sticking on the corresponding map column of the wall, given priority he had in mind.
  • Team estimated item presented with planning poker.
  • When estimations were too different we’ve allowed 1 or 2 rounds of re-evaluations. Well, we did not played exact poker, since we were interested in the approximate estimations, so we took averaged estimations  (i.e. majority raised 5USP, some guys 8USP, 6 or 7 is taken as an average, more feeling-based);
  • As soon as a column was complete discussion on required minimum scope of the release content started and PO moves some items below/above “scope line” (also considering estimations and best guessing for ROI).
  • Moving on and on to the next product column and item after item of a story map;


As result of 2 days workshop we’ve manage to:

  • Gain shared clarity about what needs to be done to get product LIVE;
  • Identify biggest project risks and “hairy topics” with poker estimations (those had usually high estimates, more than 20 USP, clearly);
  • Agree on next steps (to start with risky but must-to-have items first);
  • Noticed dependencies among items and moved them up/down in the way to decrease them;
  • Estimate roadmap and predict delivery dates range (we’ve ended up having kind of 500 USP);


  • On the level of details where items represent Themes rather than a requirements or stories according to the cone of uncertainty estimations vary from 0.8 to 1.25x factor. On the requirement/story level they also vary from 0.85 to 1.15x. Considering this I took an average  ratio, given the fact that some items were story sized, others were bigger (nice article that illustrates correlation between estimation accuracy and uncertainty from Agile101:
  • This number together with average team/historical velocity gave an idea of the range required to get product out within agreed scope;


  • Roadmap planning is a valuable and must to have regularly exercise;
  • It is both interesting and motivating for team members;
  • PO gains a lot of important insides about product that allows to manage release scope and prioritization to minimize risks and get to live ASAP;
  • Teams are enabled to plan more than  just in time architecture since bigger picture of the product becomes visible;
  • It shall be done outside of a sprint to guarantee 100% clear mind and focus;

P.S.: * many thanks to my CPO, would be impossible without his preparation and buy-in.

, , ,

Leave a comment