Tom Gilb and Kai Gilb's blog

Congratulations to you all!






The official list of Certificate holders.

Kai & Tom Gilb

Amazon Co UK Review 3 Dec: of Eric Ries, Lean Startup book

I loved this book! I am recommending it to all my adventurous and open minded professional friends. I enjoyed reading is as an ebook alternately on my iPad and iPhone. The length is nice and short. The practical examples still rich. The deep understanding of a high risk, high uncertainty learning process is impressive.

Eric believes in the same basic ideas of development that many of us have championed for years. Clear quantified ideas of real world progress, being tested rapidly and frequently in feedback cycles. The emphasis being 'learning what is real and true, asap'.

The difference is that Eric applies these ideas at an extreme that I personally have not dared to think or experience. He is operating at the 30 to 50 real changes a day being measured and learned from, from the real world. This is about gathering 'requirements' from the real world by continuously (every day) and frequently (dozens of measured hypothesis per day). This is about testing alternative designs just as early and continuously, and letting design and architecture emerge as whatever really works in satisfying the simultaneously emerging requirements.

This is revolutionary! But for the skeptic, Eric documents in detail how it works in real named busnesses. Eric is very clear about his sources of ideas, the classical gurus like Deming, Drucker, Toyota-Ohno, and many such more. He is equally clear that his method's role is primarily a framework to allow extremely rapid learning about what really works, and for whom it works.

He clearly positions 'Lean Startup' as a way of managing system-building processes such as agile methods like XP and Scrum. I and my professional friends, have long campaigned for much better multidimensional quantified quality requirements, for a rich variety of stakeholders (gilb.com).

But the majority of 'agile' developers don't want to know about such disciplined thinking. They would rather fail.

Eric speaks openly of his earlier failed projects (using conventioanl wisdom), and those of other businesses and clients. The conventional startup, and software development methods are inevitably highly failure-prone, and have been for decades.

That is because there is too little clarity of purpose (clear quantified quality requirements), and too little understanding of the variety of stakeholder values.

The Lean Startup ideas convincingly show how to avoid the embarassing pervasive development project waste. History shows that the developers themselves, while intelligent enough to use these disciplined Lean Startup methods, are not likely to jump in and adopt them on their own initiative. They (developers) clearly prefer to get well paid to code fast - using Agile methods alone, using relatively little engineering discipline (and Lean Startup is rigorous scientific method and engineering discipline). They seem to feel no real responsibility for successful outcomes. Failure still gets well paid, at their level.

So this brings up the question of who this book is for. And who will in fact make sure the ideas are implemented. This has to be the people laying the investment on the table, hoping to get a return for it. Directors, CEOs, CTOs, Angels (startup investors).

They need to demand, as a precondition for their investment, the kind of rapid learning, and rapid early 'pivoting' (major changes in architecture, stakeholders, markets, product design) that Lean Startup teaches. It is this level of power and responsibility that needs to understand the basics of Lean Startup, and to demand their use.

I think this executive level has to far too long, in the history of software development, totally abdicated their responsibility to ensure serious management of IT and software projects.

My extensive experience shows they rarely bother to even have clear quantified trackable requirements for massive (like $100 million) investments. Business schools have not been helpful in training managers to deal with multimensional critical project requirements. If history is any guide, we are not going to change our irresponsible software investment culture in the short term.

But Lean QA is a clear opportunity for the wiser top managers to make sure THEY will succeed, and hopefully in the longer term the amateur, non-scientific. non-engineering methods of the current software culture will die out.

Get the book, read it now, spread the word, and see Erics many good Googleable presentations and videos as a supplement.

Here are some links
www.theleanstartup.com/
The official website of all things Lean Startup presented by Eric Ries.

www.slideshare.net/venturehacks/the-lean-startup-2
Eric Ries' presentation on lean startups. From Steve Blank's Customer Development course at Berkeley. Learn more and hear the audio at http://bit.ly/ 3qsvJ.

www.startuplessonslearned.com/2008/09/lean-startup.html
8 Sep 2008 – (Update April, 2011: In September, 2008 I wrote the following post in which I (ER)published my thoughts on the term "lean startup" for the first time

http://eng.wealthfront.com/2011/03/lean-startup-stage-at-sxsw.html

http://www.slideshare.net/venturehacks/the-lean-startup-2
Slides bySteven Blank and Eric Ries. “The Lean Startup, Low Burn by Design , not Crisis”
http://www.slideshare.net/startuplessonslearned/2009-05-01-how-to-build-a-lean-startup-step-by-step/download

Congratulations to everyone with certification in Value Requirements.

Kai & Tom Gilb

If you or someone you know are interested in learning the Competitive Engineering / Evo / Value Management methods in a light fun way, there is now a new option available. Introducing KickAssProject.com an online video based training class.



The class is aimed at people running smaller projects than the projects we normally are involved in. It is a way to reach out to people who run projects that Tom & I normally don't reach. It is also a very cost and time effective way to learn. No travel and no expensive public workshops needed to learn.

There are lots of free preview videos there.
You can start watching right away.
Head over to www.KickAssProject.com

Kai Gilb

http://linkd.in/dI1PDq

Tom Gilb Says:
January 1st, 2011 at 1:38 pm
I notice that, as usual, there is no mention of consciously trying to deliver real value to stakeholders early and at every iteration. This is the fundamental sickness of Agile Today. Plenty mention of code, none of value to stakeholder. Plenty mention of learn only at the end, none of learning what´s real at each increment.

If you had focused on delivering measurable high value, prioritised early, then the whole discussion of 3 months or 18 months would be moot. You have a big bang mentality, not real Agile.

You need to continue iterative delivery until value for delivery cost is no longer positive. Who cares then about estimates.

You have either learned your agile from poor teachers or failed to implement the good stuff they taught. As I have long predicted we will continue to build a bad rep for agile until the Next Big Religion catches our fancy.

I am happy you all felt so nice about your teams, but how did the stakeholders feel? Not happy bunnies if I read between the lines.
Grow up and serve the people who pay you.
Stop blaming the stupid organisation, and start delighting them with results.

See Demming, “Radical Management” for a mature criticism of the Agile Manifesto (page 88), and some really mature advice (from great agile people massively!) on focusing on delighting the customer incrementally. That is what it was supposed to be all about, in principle.

What are the Dangers of Current Agile Practices

Values for Value

Value-Driven Development Principles and Values – Agility is the Tool, Not the Master
July 2010 Issue 3, Agile Record 2010 (www.AgileRecord.com)

See the presentation I (Kai) held at Agile 2010 in Norway on how you combine Value Management with Scrum to create great results, with case studies. Time 10 min.



Play

Part 0 of 7 Introduction
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity
Part 3 of 7 Stakeout Stakeholders

Part 3 of 7: Stakeout Stakeholders or Stakeholders will stake you out.

Agile theory, teachings and practices mainly* focus on the users and sometimes the customer. They preach use-cases, user stories and the customer-in-the-next-room type techniques.

• *I’m sure someone can and will point to projects that takes a wider approach to Stakeholders. I applaud and support that. Please link to sensible information about capturing complete set of Stakeholders, especially those that target Stakeholders that are not customer and users. I’m in support, not against great Agile implementations. Yet 95% of what I see practiced, written, thought, and preached takes the limited approach to Stakeholders.

Any system being developed has multiple Stakeholders. Stakeholders being the people, groups and things (laws, other systems etc.) that have requirements related to the system. Stakeholders have a ‘stake’ in the system. Critical Stakeholders can potentially determine success and failure of the system. Stakeholders require something from the system.

Illustration: Stakeholder Map by Suzanne Robertson & James Robertson

To have a fighting chance at understanding the requirements of a system, identify all critical Stakeholders. Then identify, capture, communicate, develop, deliver and tune their requirements.

Typically one or a few people initially represents a stakeholder group and their requirements. It is unlikely that the representatives can understand the diverse needs of their group, therefore I also recommend, where at all possible, to deliver value directly to the actual stakeholders, get their feedback, then learn and change based on the feedback. Don't stop at demonstrating working software, rather, early and frequently, deliver real value to real Stakeholders.

Yes, users and customers are critical Stakeholder groups. What I’m missing are the other 20 to 40 Stakeholder groups that all have requirements for our systems, Stakeholders and requirements that can and will determine the success or failure of the system being developed.


Illustration: Here is an example from multi discipline industrial designers and design managers of thinking about multiple Stakeholders and their needs. -Providing Design Strategy for Winning Products and Successful Enterprises
by Mordechai Rotenberg - http://m-rotenberg-design-management.com

Until the popular agile practices systematically incorporate the requirements from a complete set of Stakeholders, they will remain unfit for any but the simplest of projects. Scaling agile without capturing the larger Stakeholder set and their requirements might somewhat work when the scaling is in the direction of doing more volume of simple commodity work. Without capturing the larger Stakeholder set and their requirements, I doubt agile will find much success in trying to scale towards larger, complex, high quality or competitive products.
Stakeout the Stakeholders or the Stakeholders will stake you out.

To comment, you need to register (instant) and log in (top right).

Yours truly
Kai Gilb

Part 0 of 7 Introduction
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity
Part 3 of 7 Stakeout Stakeholders

---

In the last blog post, Part 2 of 7 Developer Creativity, I posted this challenge,

The challenge got one response from one brave person, thanks ☺


Well, what my customer (student), Jens Egil Evensen (jens.egil.evensen at logica dot com), actually did was.
1. Identify the critical Stakeholders.
- Number one was the CTO who was sold the system from Microsoft.

2. Talk to them, and find the value improvements they are hoping for.
- The CTO said (after no compromise questioning of, - why? - what do you want to archive?, where he initially was stuck on the idea of rolling out the CRM system) they where loosing €9.300.000.- per year in expiring contracts, and they did not know about them before after the contracts had expired and the customer was lost.

3. Identify solutions, 4. Divide them into value deliveries, 5. Develop (using Scrum) and

6. Deliver value early.
- After 14 days, he delivered a system (based on the MS CRM system) to the desk of the CTO, that hooked into the telephone operators customer contract system, flagged the outgoing contracts about 30 days before expiration, and sent a message to the appropriate people to take action.
From that day onwards, and to this date, the telephone operator was saving about €9.300.000.- every year.

The point being that if Jens had followed any kind of requirement method as taught and practiced by the Agile community, based on functions, features, user stories and the like. He would have utterly failed. Jens would not have identified the Stakeholders, he would not have talked to the CTO, he would not have asked the right questions. What he would have done is rolled out a CRM system bit by bit?

Jens went on to roll out the CRM system going through the cycle 1 to 8 (7=Measure, 8=Learn). He was given all resources (guess why!) and the CRM implementation has since won an award that MS is busy taking credit for ☺



Have fun communicating with your Stakeholders.

Kai Gilb