Mark Pearl

Agile is evolving… Today we are doing a pretty good job at tackling the jobs that Agile is here to solve.

“Our highest priorty it to satisfy the customer through early and continous delivery of valuable software”

Delivering more crap faster was never what it was about…

Every agile thing starts with an idea. It then goes into cycles when it grows and grows until it gets to a point where we can ship it.

Talking to the people that are downright unhappy with us led us to a lot of ideas…

Inspite of doing everyhting that people said, sometimes things were awesome, sometimes things were not awesome, and sometimes things totally sucked.

It was hard enough to be predictable, but it was even harder to know that they would be happy with what we built…

What matters is what happens when things come out -> we call this the outcome.

We measure outcome by peoples behavior and what they do differently…

Making people happy is important, but the model also comes out of the business. This means that stakeholders should be happy.

The longer term benefit we call impact (return of investment or brand awareness)

Impact happens as a consequence of people being happy.

We can measure in days if people are happy, we cannot measure impact in days.

Happiness is a leading indicator, Impact is a lagging indicator

It doesn’t matter how short your feedback loop is, somethings cannot be measured in weeks (they need longer to measure).

One of the most challenging things about the whole thing is this stupid idea thing… everybody has them…

If you build things faster, there are always more ideas - you double your delivery rate, the number of ideas quadruples

The nasty thing about ideas is we are usually wrong

The standish report where 60-70% of features are never used is from a small subset of sample data (4 of 5 companies)

Marty Caga - author of Inspired (worth reading)

Marty said if you are really good at product management, you will be right 1/3 of the time.

  • There are too many ideas
  • We are usually wrong
  • We don’t know it

In software development, just building a lot of bad ideas is not a good idea Our job should be to focus on building less

Awesome vs Aweful

Awesome <-> Thud Zone <-> Aweful

( Build -> Measure -> Learn ) Cycle from Lean Startup

2 anoying things - Minimum viable product

  1. (2001 MVP Hypothesis) The smallest product that could achieve it’s desired market outcome [viable = successful, product = something released]
  2. (2011 MVP Test) As the smallest thing we do or make to validate a product hypothesi [viable = we learn something, product = test]
  3. (2017 Anti Definition) It’s crap, but it works…

It’s easier to satisfy a smaller market than a larger market If you shipped your product and everyone is happy, you shipped it too late Building something that helps us learn on everything is not the smallest thing we can do

Just because they are pretty great, doesn’t mean they do everything that is great.

blog comments powered by Disqus

Want to get my personal insights on what I learn as I learn it? Subscribe now!