Agile is verge of productive conflict: controlling gap between demand and offer

Before everything else, getting ready is the secret of success.
Henry Ford.

Many of us doing Agile do not understand that it is primarily business mindset, rather than just another methodology to deliver software. Balance and sustainability of constructive conflict (key driver of any prosperous business) is the secret sauce to implement Agile successfully.
Let me explain it from practical business perspective. I will drift away from IT and software now…

Imagine you’re running business delivering…. car repair services to your customers.

It is your interest to deliver services fast and having quality in, so that you retain your customers and attract more (as it’s known that satisfied customer may bring 1 or 2 others, while dissatisfied one may stop other 8 coming to you). On one hand the more services you deliver, the more money you get, so you will push for more. But if you start pushing harder than your team is capable of, your service quality will start to suffer and this will obviously cause problems with your customers.

So you will try to get as much as possible given your conditions, while keeping quality in.

Now let us look at it from your customers perspective…

They want to have their car repaired cheap, fast with quality in. When you say your’re busy this week and cannot take their car, they will consider someone else’s services, rather then agree waiting that log (reality of market competition);

So, there is conflict of interests and mismatch between demand and offer.

It drives 2 things:

• Your business development (we need to improve our service to deliver faster/more/cheaper);
• Your customer’s expectations (maybe these repairs are not doable that fast/that much/that cheap);

Two consequences out of that:

• When there is no demand, why should you care to do more/faster/cheaper?
• When there is no chance to change your customers expectations either you’re doing poor job or your customer won’t likely get any better services with reasonable price anywhere else (task for your client managers to drive customer’s expectations).

So mismatch of those two creates conflict of interests that drives change.

The art is to understand to what extent you’re capable to improve things at your business given your current circumstances, while managing your customers expectations in the way to have control over gap between your offer and your customer’s demand.

Controlling this implies another important thing: ability to recognize challenge that you will fail taking (you should constructively resist) and challenge you’re able to overcome (and should take) to improve and continue managing “the gap”.

If you do not understand this you will end up bad. Either you will not be able to deliver quality in to your customers or you will be “beaten” by your competitors. In both cases you will end up being out of business :(.

Now let’s come back from cars to software and Agile

Customer is Product Owner (PO), while your business is your development team. The more you think business-wise and consider your team a business the better your team will be satisfying your PO.

So it is as easy as managing just 2 things:

• Your PO’s expectations;
• You development (quality and predictability);

Agile is just business common-sense mindset, nothing else! So to implement it right start from considering that you run a business in a highly competitive market with goal to satisfy your customer.

And mind that there is difference between pleasing and satisfying your customer, so argue, stand for your point, do not let compromise quality, do never over-commit, protect your ability to deliver, manage expectations, and … satisfy. If you do not follow these simple business rules and will focus on just pleasing your customer (or PO) just as in business you will end up not being able to manage what you’re responsible for – QUALITY.

Good Luck 🙂

10 Tips to undermine Agile team ability to deliver

Many Agile coaches have their own list of top failure modes. My favorite one is Mike Cohn’s: “How To Fail With Agile: Twenty Tips to Help You Avoid Success“.

But I also want to publish my winning list of things that impact teams and undermine their trust in business and Agile  (combined from experience gained observing different teams at different times, so no particular team is meant here 🙂 ).

So tips are written from the Product Owner perspective:

1. Argue in front of team at Sprint Planning. Let them see you were not capable to decide what you want to build them. Moreover, involve them into arguing. This will demonstrate how your (PO) team misses integrity;

2. Demonstrate that being on time does not matter: interrupt meetings with calls, side talks and questions. Leave the room occasionally and be late regularly. Doing this will make it almost impossible to demand on-time delivery from the team;

3. Continuously fail to deliver INVEST stories and integrity in sprint goal/product backlog. Let stories w/o details thought through, so that team feels you had not invest enough time to prepare them. This will also make it easier for team to fail delivering outcome of that stories to you, will make things more ambiguous, so that no one will understand where is failure or what was wrong and will never learn from it, so that improvement will not be feasible;

4. Ignore team signals on complex stories (the ones that are above ~13 story-points, the ones that are risky, big, and usually need to be analyzed and split into smaller chunks in advance). Just let big stories that have big doubts, leading to easier underestimations, over-commitments, sprint failures, causing less team confidence, further under-commitments and wastes of all kinds;

5. Present deadlines ignoring reality “I do not care how you do it, it MUST be done”. With this “masculine” management style you can always push things forward as Agile teams just delivery chain, so they must obey and no matter what they think and capable of;

6. Never share the Product Vision and mid-long term roadmap with the team (just keep it secret);

7. Ignore technical debt (just concentrate on #5);

8. Bombard team with in-sprint questions and “Can you do it now please?” tasks. Explain them that SCRUM is good but now we need to be more “FLEXIBLE”. Moreover, assign tasks to team members without talking to entire team. Demonstrate that you were not been able to plan things for an iteration, this will ruin team trust that they are working on most valuable things and completely undermine their ability to deliver;

9. Never groom your backlog just leave it to the sprint planning meeting when it is already too late. This will lead to long and stressful discussions as you will have to do it mid-planning,will drain team energy, lead further to fatigue, wrong estimations, poor planning and sprint failure;

10. Always try to find something that team did wrong to pin point and focus on blaming. This is proper way to avoid Kaizen and let team protect themself by “storytelling”;