There are still companies arguing about the good things about waterfall… So I’ll take “being agile” from another angle and will try to prove being agile is just being smarter than using waterfall!

First: where is the problem on any project?

From , https://dannorth.net/2010/08/30/introducing-deliberate-discovery/

“Learning is the constraint”

Liz Keogh told me about a thought experiment she came across recently. Think of a recent significant project or piece of work your team completed (ideally over a period of months). How long did it take, end to end, inception to delivery? Now imagine you were to do the same project over again, with the same team, the same organisational constraints, the same everything, except your team would already know everything they learned during the project. How long would it take you the second time, all the way through? Stop now and try it.

It turned out answers in the order of 1/2 to 1/4 the time to repeat the project were not uncommon. This led to the conclusion that “Learning is the constraint”.

Edit: Liz tells Dan North the thought experiment and quote originated with Ashley Johnson of Gemba Systems, and she heard about it via César Idrovo.

If we assume the only difference is that the second time round you have learned about the problem, this would suggest that the biggest impediment to your throughput was what you didn’t know.

So the problem is: the main constraint on a project is lack of knowledge.

So what is the solution?

The solution is to make learning more effective. So how?

  1. Work on high value and high risk requirements first and don’t waste time yet on low value and high risk:
    • High risk means lack of knowledge is important (high risk = we don’t know how this is going to work out).
    • Then high value, low risk
    • Low value, low risk
    • Finally, if any money left, low value, high risk: why? Why would you spend time learning on something that has low value and may not be needed at the end?
  2. Request for feedback as quickly as possible: how do you know what you have learned is correct? How do you know you have understand your customers? Learning is effective  if first what you have learnt is correct: your customers will tell you. Ask for quick feedback. Don’t delay.
  3. Work as a team:
    • One does not know everything, communicate as often as possible with your team members and customers (or proxies). You’ll learn a lot from people, not necessarily because they know more but by discussing, they may ask you some very good questions!
    • Don’t split design, development and testing between different people: make sure same people work on all phases otherwise team members spend time transferring information; spend time sharing information.
  4. Fail fast, learn fast, improve fast: give the team an environment to try and experiment new things. But since we want quick feedback, if they fail, they will fail quickly, learn faster and improve faster!
  5. Be strong on Quality: whatever you deliver, accept it only if it meets your criteria in terms of quality. I am not saying “get it right first time”, quite the opposite. Go fast, get feedback, iteration until quality is right and product is right. Because you iterate quickly, they will get it right quickly and will know how to get right faster next time.
  6. Foster a “learning” culture: books are amazing; some people have a wealth of experience they have captured in books; learn from them so you can quicken learning (from years – for the authors – to weeks – for you!).
  7. And then, use BDD: BDD is asking concrete questions to get concrete examples from your customers. Conversations are the critical part. And the added benefits are: faster learning and understanding of what the right product to build is; set of acceptance scenarios (tests); drive development (and living documentation); and even executable spec (when you automate these examples); etc

If you agree, “lack of knowledge” is really the constraint, then if you focus on learning effectively, you will deliver faster than when using waterfall and also you will demotivate your teams (if you are already using Scrum or Kanban too)!

So, being agile is learning more effectively so hence reducing the main constraint on your project so reducing time-to-market for your product: this is being business friendly… Sooner (less costly), faster (shorter time-to-market) hence higher ROI!

Advertisements