Jobs to be done

Clayton Christensen (of Innovator's Dilemma fame and one of my management heroes) writes in the September edition of Harvard Business Review about understanding customers intentions (see Know Your Customers’ "Jobs to Be Done" - free too!).

Two great paragraphs:

The fundamental problem is, most of the masses of customer data companies create is structured to show correlations: This customer looks like that one, or 68% of customers say they prefer version A to version B. While it’s exciting to find patterns in the numbers, they don’t mean that one thing actually caused another. And though it’s no surprise that correlation isn’t causality, we suspect that most managers have grown comfortable basing decisions on correlations.

After decades of watching great companies fail, we’ve come to the conclusion that the focus on correlation—and on knowing more and more about customers—is taking firms in the wrong direction. What they really need to home in on is the progress that the customer is trying to make in a given circumstance—what the customer hopes to accomplish. This is what we’ve come to call the job to be done.

In conclusion, here's his argument as to why big data only is the second tool to reach for. The first thing is to understand the desires and intentions of your customers.

Many organizations have unwittingly designed innovation processes that produce inconsistent and disappointing outcomes. They spend time and money compiling data-rich models that make them masters of description but failures at prediction. But firms don’t have to continue down that path. Innovation can be far more predictable—and far more profitable—if you start by identifying jobs that customers are struggling to get done. Without that lens, you’re doomed to hit-or-miss innovation. With it, you can leave relying on luck to your competitors.

Bravo - I'd rather rely on understanding and insight than data.

Which is faster: Waterfall or Agile?

To be clear, my personal position from the arrival of Agile a decade ago has been of scepticism rather than love-at-first sight. Agile's star couldn't be higher 5 years ago. If you weren't Agile then you were a dinosaur.

Fashion has quite clearly moved from Agile only to Water-Scrum-Fall. (Gone are the days (TG!) that starry-eyed developers would come back from Agile training courses wanting Marketing or Sales to go Agile too!)

Credit: iQuest Group 

Let's rewind at the outset: both Waterfall and Agile share exactly the same objectives: to deliver high quality products as quickly as possible to a willing market. Both have strengths and weaknesses, but the inappropriate application of the letter of the law in either case leads to its relative weakness.

On Agile

Agile does produce more recognizable product more quickly, but must be inefficient because:

• Making lots of software releases generates an overhead: for development, testing, deployment, customer communications, for customers themselves. 
• Gathering and analyzing customer feedback (which is so important to Agile) can be difficult and time consuming. (It is certainly expensive to set up and configure in order that this process isn't too arduous). Note that Engineering only does some of these tasks.

Agile's strength is that it doesn't do too much before all the parts in the workshop floor are re-assembled together and the product is shippable. (There is the theory that less development needs less testing, but in complex software, a small error can have massive consequences.)

Agile's weakness is that tends to encourage a horizon of a two or three sprints only. Estimating epics which span multiple sprints, can be even harder / more error prone than Waterfall.

Also there is fallacy at the bottom of Agile: that all resources are interchangeable. This is wrong: people develop specialisations or area of responsibility. This expertise can easily generate a bottleneck and tasks requiring a critical skill always end up on the critical path - not just for one project, but the problem appears to snowball, impacting multiple projects.

On Waterfall

Waterfall does mandate careful attention at the outset to scope of the product. This discipline (call it product planning or roadmapping) is considerably downgraded in Agile - which is a huge mistake. Many execs believe that once they have a product owner (who writes user stories and manage the sprint process), then they don't need product managers (who assess product concept, write epics & launch products).

Waterfall's strength (in terms of speed to delivery) is that it smashes the problem into little bits all over the workshop with the final deliverable in mind and only intends to reassemble all the bits at the end. Continual reassembly must be more time consuming to get to the same objective. Agilists will rightly point out that the objective invariably changes and that remembering how to reassemble all the
bits is error prone, requiring lots of testing.

Waterfall's inherent weakness is that because the endeavour is so carefully planned at the outset, then everyone follows the project plan, heads down in the sand. What a good product manager should be doing is constantly scanning for changes in the market place, in the requirements, in the deliverables. He or she should be constantly 'checking in' with all parties to ensure that any new information is gathered / digested / understood and its impact assessed.

Conclusion

As in life, it is a compromise. However, time spent in reconnaissance before a line of code is written is rarely wasted. And that's why I like Water-Scrum-Fall.

Some references

• Agile is for development only (previous blog post)
• Agile vs Waterfall (from Udemy)
• First mention of Water-Scrum-Fall in 2011: Water-Scrum-fall is the reality of agile