Loading...
 

Tom Gilb and Kai Gilb's blog

Leading ideas on Project Management. Stakeholder Values, Quantification, Agile, Quality, Requirements, Evo, Quality Control, Systems Engineering, Value Management.
RSS feed
Published by Kai Thomas Gilb323 points  on Tue 24 of Jan., 2012 KaiGilb

Project-Requirements.png (4.34 Kb)

Congratulations to you all!


The official list of Certificate holders.

Kai and Tom Gilb

Published by Tom Gilb13 points  on Sat 03 of Dec, 2011 TomGilb

Project-Requirements.png (4.34 Kb)

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/(external link)
The official website of all things Lean Startup presented by Eric Ries.

www.slideshare.net/venturehacks/the-lean-startup-2(external link)
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/(external link) 3qsvJ.

www.startuplessonslearned.com/2008/09/lean-startup.html(external link)
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(external link)

http://www.slideshare.net/venturehacks/the-lean-startup-2(external link)
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(external link)

Published by Kai Thomas Gilb323 points  on Wed 29 of June, 2011 KaiGilb
Project-Requirements.png (4.34 Kb) Image Congratulations to everyone with certification in Value Requirements. Kai & Tom Gilb
Published by Kai Thomas Gilb323 points  on Mon 23 of May, 2011 KaiGilb

Project-Requirements.png (4.34 Kb)
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.

Flash player not available.


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(external link)

Kai Gilb

Published by Tom Gilb13 points  on Sat 01 of Jan., 2011 tomgilb

Project-Requirements.png (4.34 Kb)

http://linkd.in/dI1PDq(external link)

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(external link)

Values for Value(external link)

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

Published by Kai Thomas Gilb323 points  on Wed 24 of Nov., 2010 kaiGilb

Project-Requirements.png (4.34 Kb)

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.

Value-Scrum-Kai_Gilb.png (214.16 Kb)

Play(external link)

Published by Kai Thomas Gilb323 points  on Tue 28 of Sep., 2010 kaiGilb
Project-Requirements.png (4.34 Kb)
Part 0 of 7 Introduction(external link)
Part 1 of 7 Wrong Focus(external link)
Part 2 of 7 Developer Creativity(external link)
Part 3 of 7 Stakeout Stakeholders(external link)

!!!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.
StakeholderMap.jpg (41.77 Kb)
Read more
Page: 2/11Last Page
123411