Tom and Kai Gilb blog

Tom Gilb awarded Honorary Fellow at the British Computer Society

Mon, 16 Apr 2012 15:28:00 +0000

Tom Gilb FBCS
Bob Harvey, current President of BCS, congratulates Tom on the Hon. FBCS award, while past President Jim Norton looks on.

Tom feels honored to join the exclusive list of Honorary Fellows.

Value Project Management - Lean QA Classes and awards.

Thu, 12 Apr 2012 11:50:00 +0000

Another great week of workshops at the British Computer Society (BCS).

London Easter Eggs

We started with a Project Management Class

Project Management Group Picture

Soheir Ghallab organizing and making it all a pleasant workshop. Thanks from all of us!

Then we did a Lean QA class.

The Lean QA class group picture. Welcome as new Agile Inspection certificate holders. May you use it wisely
The official list of Certificate holders.

Mr. Dick Holland sharing experiences of how he turned a financial services company around using Value Management and Inspections. Read about how he did it: Paper and Slides

Mr. Dick Holland awarded Value Management - Master and Agile Inspection - Master. With many years of experience implementing and practicing the disciplines, and getting outstanding results. Many congratulations from Tom & Kai and I'm sure the project management community. Official Registration

New Value Management and Lean Inspection Certificate Holders

Tue, 24 Jan 2012 13:10:00 +0000

Congratulations to you all!

The official list of Certificate holders.

Kai & Tom Gilb

Review of Lean Startup book by Eric Ries

Sat, 03 Dec 2011 04:03:00 +0000

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

Nice Value Requirements Workshop

Tue, 28 Jun 2011 22:16:42 +0000

Congratulations to everyone with certification in Value Requirements.

Kai & Tom Gilb

Kick-Ass Project - a new online video based training class.

Mon, 23 May 2011 20:32:56 +0000

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

Kai Gilb

Why did BBC Agile Project Fail? Tom´s Opinion; deliver value to stakeholders !

Sat, 01 Jan 2011 13:45:44 +0000

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)

How you combine Value Management with Scrum to create great results

Wed, 24 Nov 2010 00:52:41 +0000

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

7 truths about Agile and Scrum that people don't want to hear. Part 3 of 7: Stakeout Stakeholders or Stakeholders will stake you out.

Tue, 28 Sep 2010 13:19:09 +0000

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,

^A challenge to you!
I like to pass on a challenge one of my customers had. He was given a project from Microsoft, to implement a Microsoft built Customer Relationship Management (CRM) system at a telephone operator company. He was the Product Owner. He had about 6 months to roll out the system to all the employees there using CRM systems.
Your challenge: By using Scrum, XP or any other Agile framework or method, how would you write the product backlog items or the requirements? I understand if you think I have given you too little information, but give it a go anyway. Just give me some examples of how you would specify the Product Backlog Items in our Blog comment section, or at least think about it for yourself, later I will tell you what he actually did, and then you can compare.

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

4) As for your challenge, that's simple. Deploy the CRM tool out of the box. Tell the user community that you're going to make it live on Monday. Ask them why they couldn't do their jobs if you did that. The resulting reasons they come up with becomes the backlog. Seriously. That way you aren't getting stupid wish list Requirements, but rather ones that are much more focused on getting their job done.^

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

7 truths about Agile and Scrum that people don't want to hear. Part 2 of 7: Developer Creativity

Mon, 22 Feb 2010 09:59:48 +0000

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

Part 2 of 7: Agile “Baby Talk” Kills Developer Creativity

Conclusions up front
Scrum is practiced as a huge cooperative todo list. By not focusing on the critical "how well" attributes of the system, Scrum is reducing sw development to tasks, not needing skillful creative knowledgeable Developers. Developers are told what to code, not asked how to best satisfy a product quality need. When developers are given the challenge to improve a system (Product-Quality) they not only rise to the challenge, but excel at it. This is also observed in Scrum teams where they are given the challenge.
There is little or no understanding for how to create a competitive product. Rather, the opposite is happening, by requiring 'solutions' (made by amateurs (users), not architects), more-competitive options are systematically censored.
The Agilists sell Agile as an answer to increasing market pressure, as a way to be more competitive. But Agile falls short of giving its applicants a competitive advantage, because it doesn't say anything about requirements.
The popular Agile practices, teach and practice Use Cases or User Stories and other function and feature centric ways to describe the most critical input and outcome of development. There is little or no specification to help us differentiate between a function “the what”, a value “how well”, and a Solution “how”. Most Agilists teach and practice 'mixing the required function with the optional solutions'. They don’t seem to teach anything useful when it comes to the most critical type of requirements, the “how well”. In practice, by teaching User Stories, they teach not to use the critical “how well” types of requirements, at least not in a way that can be used to guide decisions in the solutions.
The real value and cost of a system comes from creating the "how well" attributes.
This “baby talk” requirements practice makes the popular Agile methods useless to anyone creating competitive systems, to anyone creating systems requiring high value, and to business.

that is it, the rest of this blog is fill to better explain the conclusions above.

Claims:
1. 90%-99% of all Agile, XP & Scrum practitioners and teachers are describing product requirements using the incomplete and uncompetitive aspects of what describes products, the functions, features, user stories and the like. They are failing to incorporate the requirement parts that make a product competitive, that make it valuable, and that is costly to develop.

2. 90%-99% of all Agile, XP & Scrum practitioners and teachers have not learned the fundamental skill which is critical for the success of a product: separating functions, from solutions, and also from the “how well” attributes (aka qualities). This is not unique to Agile, but without this, Agile is not healthy.

3. 90%-99% of all Agile, XP & Scrum practitioners and teachers teach 'Solutions' as if they were the Requirements, thereby killing opportunity for creativity among the Developers to come up with better solutions. This also tends to kill the fun of being a Developer.

I don't know the actual %, but from my broad international exposure, it is closer to 99% than 90%.

Introduction
At its purest description, Scrum is an empirical process control method. That means that Scrum is specifically designed to NOT tell you how to do any particular sw engineering discipline, like testing or requirements.
It is an “open development framework”. 'Open' meaning that you can use any requirement method, testing method, prioritization method etc. that the Scrum team sees fit for purpose.
Using Scrum, through early continuous feedback, your organizational disfunction, like lack of understanding of the real requirements, should be revealed.

Agilists also like to emphasize that Agile is a good answer to increasing market pressure; that it is a method that gives an advantage over other methodologies in terms of competitiveness.
Also central to Scrum is the idea of cross-functional teams. I might comment about that in a later post, or not.
Credits: thanks to Craig Larman and Jeff Sutherland for teaching me about Scrum's origin, and what it should be.
What a great starting point! There is much to like about the above description.

In this blog post, I will use the word Developer to include; engineers, architects, usability experts, coders, softcrafters etc. and in most cases product owner)

Reality?
You cannot just do Scrum. To put the framework to practice you need to plug in methods for the various sw engineering domains, like testing and requirements, and practices from XP.

In the field, what requirement practices are taught and used? Simplified Answer: User Stories! (Functions and Features based, also TDD and BDD are of this nature).
And you might think that is ok, what is wrong with User Stories? Everything is wrong with that focus, it is not ok. It means you make your favorite Agile practice as weak as most of the past fads ;-) Read on...

By talking to Scrum and XP gurus and teachers, I have found that they teach user stories and the like. They say this is for two reasons.
1. That is all the Agile market is ready to digest. (If this is true, my efforts are of no use ;-)
2. Most (but not all) of them don’t know how to do it much better.
Some references that point to examples for User Stories. But you can look at your own practice and thinking.
http://www.scrumalliance.org/pages/what_is_scrum
http://en.wikipedia.org/wiki/Scrum_(development)
http://scrumtraininginstitute.com/home/stream_download/scrumpapers
I don't find interesting practical alternative methods of requirements, as described below, from within the Agile community, let's say 'in use' to drive the Product Backlog. I have searched the web and asked the experts. But I’m sure these interesting alternatives are there, especially when Agile is used to create systems that have a heavy engineering background. Please point them out to me, as I'd love to learn about them and how their users do it.

User stories have the same philosophy and faults as valuing “working software”. User stories are not values to most real stakeholders. Functions are fundamental, but they are not the increased value people want. User stories or derived function requirements describe what the user does, or wants to do. They will guide the Developers to create the functions needed for the sw to be able to “do” that.

The Real Point is - Value Increases
The point is not sw functions, the point is to enable some stakeholders to improve something, to do things better than before. The main focus has to be on the “better” part. If you are in the business of creating working sw, user stores might do the trick for you, but if you have any kind of competition, even from your own old system, user stories don't cut it. If your stakeholders are at all demanding, you need to focus on how well the system you are developing does a function for the Stakeholders.

Example
Let me give you an example from a authoritative text on Scrum. http://scrumtraininginstitute.com/home/stream_download/scrumprimer page 8 figure 2 The Product Backlog.
Item 1. As a buyer, I want to place a book in the shopping cart (see UI sketches on wiki page).

What is wrong? Everything is wrong! Let me give a quick breakdown.

First, the function it describes, “to place a book in the shopping cart“ is already a solution. The pure function is “to order a book”. Any specific way to make the order happen, like “shopping cart” will restrict the options/creativity space available for the Developer to find a solution, that will make the function “order book” have better quality, as in perform better.

Second, the central part of competitiveness, the idea about “better”, is missing completely.
The “how well” attribute of the function (aka 'quality') is the critical aspect that allows the Developers to know, find, and prioritize the solutions that are;
1. better than the competitors (also information that’s missing, how good will competitors be?),
2. better than the sw product it is replacing (missing),
3. better than the solutions specified in the “UI sketches” (aka solutions),
4. helping you know when you are over or under-designing, compared to the values needed and their worth.

Developers are essentially reduced to “bricklayers”. They are told what to do. The mighty Scrum framework is reduced to a big cooperative To-Do list that tells the Developers what to do, and you the Developer should just do it.

Summary of what is wrong with this User Story.
The Product Backlog Item is mixing up 'required function' and (optional) 'solutions', without feeling any guilt. The critical “how well” attributes are totally absent.

Here is a hint to an alternative way of expressing it (simplified requirements, I would normally define some of the words etc., but found not needed for the points expressed):

Book-Order.Through
Scale: average % of books, that a user intends to buy, that they actually end up buying.
Past [System being replaced, last month] 75%
Past [Competitor x, last month] 85%
Status [new system, last delivery cycle] 80%
Tolerable [new system, May.] 85%
Goal [new system, May.] 95%

Book-Order.Speed
Scale: Average time, to complete a book order, of three books, that are known to the buyer,  from: she has the intention of buying the first book, she is on a page where the book is displayed, until: she has completed the order of the three books, and gotten her confirmation of order and of payment.
Past [System being replaced, last month] 10 min.
Past [Competitor x, last month] 7 min.
Status [new system, last delivery cycle] 6 min.
Tolerable [new system, next May.] 6 min.
Goal [new system, next May.] 1 min.

In plain english, and shortened, Book-Order.Speed reads:
It is required that a buyer, by next Feb, can complete a book order of three books, in 1 min.
If by next Feb. it takes more than 6 min., this project is a complete disaster.
On the website it is replacing, it takes 10 min.
Our main competitor has a system where it takes 7 min.
And after last sprint (if Scrum) we measured our latest version to 6 min.

State the challenge without the Solution
In the Book-Order.Thrugh & Book-Order.Speed examples, the solution is not given, just the challenge. The challenge is to find the best solutions to reach the Goal levels. A challenge put forward in such a way focuses on delivering the desired value improvement to the Stakeholders. It leaves the creative and engineering aspect of how to best solve the challenge to the people best suited for that, the Developers.

From Customer to Developers
Needs as uttered from the customer and users are uttered from their perspective, from their background, with their engineering knowledge. They speak “baby talk” when it comes to development and engineering. They will say they need ‘password’, when they need ‘security’, they will come up with solutions that they think will solve their needs, but will not have the insight of all the Stakeholders needs required to make the best solution required for all Stakeholders.
Developers do have the potential to have the overview over all the Stakeholders needs and an overview of the technical possibilities.

Don't state the "how", Don't worry about the "what", Focus on the "How well"
Every bookseller has to have a system for ordering books. The Product Backlog item: “As a buyer, I want to place a book in the shopping cart (see UI sketches on wiki page)“ pins down the solution, states the obvious that is common among all competitors (the function, the what) and omits the real requirements which is essential for creating a competitive product (doing the function better).

Documentation Reduction
If you are not accustomed to the power of focusing on the "How well", you might think I am introducing more paperwork. The opposite is true. By learning the art of specifying the critical ends, as "what it will do" and "how well it will do it", one can eliminate the solutions (from the requirements specs).

Requirement documentation can be reduced drastically, like down to one page for huge projects. I just got a status report from a client of mine. He was a little shy when he told me that the requirement documentation for his project consisted of only one requirement. His requirement looks something like this:

DB-Clean.Time
Scale: the average time, from a customer delivers a contact db to them, until it is given back to the customer, cleaned to the same quality as it is with the current system.
   Past 5 hours
   Status 1 hours
   Goal 30 min.

That's it! He told me he did not have any other documented plan. He trusted they would find ways to reduce the time as they went along. And he (his development team that was free to find the most suitable solutions) had now brought the time down from 5 hours to 1 hour. He is as Agile as can be, AND he is creating a very competitive system. Note that the competitiveness didn't result from 'Agile' alone, but mainly from the requirements practice used.

No creativity needed?
There is not much happening with the “function”, all book sellers have to have the same function, it is either present or absent. If absent, you are not in that business.
What needs to be created is the “better attributes” of the functions. Better than the competitor/old system.
How do you create “better”? By coming up with solutions that together carry/create those “better attributes”. That means, if Solutions are called Requirements, as in 'required', as they are in User Stories, those 'required solutions' will directly deny the Developers the possibility to create better solutions, that could have resulted in a competitive product.

Skilled Developers need not apply!
When the requirements of a project are focused on the functions and solutions, as is normally the case with User Stories, good craftsmanship, doing coding well, will not be appreciated. If your job is to code "put the book in the shopping cart", well that is what you will produce. This is likely to lead to yet another terrible system, do it and update your burn down chart. But if your real requirement is something like Book-Order.Through & Book-Order.Speed (see above) thinking and knowledge is required. Then add your simultaneous requirements for Maintainability, Security, Usability, and Upgradability to the challenge, and we need skillful people to specify requirements and to suggest suitable architectures.

Where the Value and Cost is
Creating functions, of no particular quality, is just about free to do, but without the "how well" attributes, they are useless and value-less. What drives development cost is "how well" the function does what it does. What is valuable to stakeholders is also "how well" the function does what it does.
To better understand this, lets first look at extremes. Lets use Book-Order.Speed as an example. If it took about 7 weeks to complete the order of books, it would not matter if it could be done, no matter how good other aspects of the system are. People would not order books. At the other extreme, pushing the time down to 1 sec. to complete the order, would be technically very challenging, and probably expensive, but it could do wonders for sales.
Now, what is happening if you (I'm potentially talking about you are using User Stories or the like, without a main focus on the "how well" attributes.
   What is happening is that you are developing "good enough" functions. Obviously 7 weeks for Book-Order.Speed would not be accepted, so you develop it until it is ok; you find some solution that you like, and go with it. But is the system created better than the competitors? Who knows! Is the system better than the old system it is replacing? Sometimes yes, sometimes no. If they have a serious competitor, one who is targeting "ease of completing the sales" with vigor (think iTunes store's one-click sales machine!), 'good luck' competing with your User Stories.

A challenge to you!
I like to pass on a challenge one of my customers had. He was given a project from Microsoft, to implement a Microsoft built Customer Relationship Management (CRM) system at a telephone operator company. He was the Product Owner. He had about 6 months to roll out the system to all the employees there using CRM systems.
Your challenge: By using Scrum, XP or any other Agile framework or method, how would you write the product backlog items or the requirements? I understand if you think I have given you too little information, but give it a go anyway. Just give me some examples of how you would specify the Product Backlog Items in our Blog comment section, or at least think about it for yourself, later I will tell you what he actually did, and then you can compare.

Hope!
There is hope. Being an empirical process control method, Scrum is not the direct cause of this illness, neither is Agile. With Scrum you are free to dump User Stories, and iteratively start using meaningful ways to describe the requirements! Where we have given Scrum Developers back the responsibility to use their skills and to be creative in the solution space, we see the Developers shine.

Your 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

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

Tom's position on real software engineering: It is Not about programming!

Sun, 31 Jan 2010 04:29:01 +0000

http://bit.ly/axtT9A www.semat.org My Position Paper for March Zurich Conference. Too many 'coders' involved!

A select group of 'wise old men' (at least 'old') including me, is going to meet 17-19 March at ETH Zurich, to tackle the problem of making real software engineering happen. I am also going to hold some courses public in town that week too.

We have failed miserably, and we have been the methods leaders, book writers, conference speakers for decades.

Reading some other's position papers, I am already worried, as I initially was, that some of these people still do not see a distinction between programming, and software engineering - between a craft of building, and an intellectual/practical discipline of designing and architecture.

They consistently fail to mention anything about quality and cost, or design or architecture to meet performance requirements within constraints.! They consistently refer to code and coding processes. I know these guys, they are actually intelligent people - but it amazes me they have no sense at all of what engineering is. Lack of the culture.

Failure to engineer, while "improving Scrum Burn Rates" is arguably one major reason for large software system failure. I find that most large projects do not quantify their top few critical (quality, improvement objectives. I have seen at least 3 $100 million software projects totally fail for this reason alone. Lots of smart programmers there though!

My personal prediction is that real major change in teaching, and doing, real software engineering, will only come about as a result of very major catastrophes, caused by bad software. In my imagination 300 aircraft will kill all their passengers, on a single day, due to an air traffic control 'glitch'. Caused by poor engineering practices. Will that wake people up?

Until then we can try to prepare the ground by working out ideas of what we should be doing - but nothing will happen until we are massively motivated - and we are really not motivated yet.

Even events like Nine Eleven (11 Sept, attacks), and Credit Crunch Financial Collapse are not big enough for us to change anything effectively. So something much more painful is required. I hope our ideas survive, the '2012' catastrophe (see this film - it makes you think).

Or wait a minute, our ideas on doing software are so bad now, that maybe if they all got wiped out, we might get a fresh start based on common sense? Yeah, wipe out all those dumb software ideas, including agile, then use our heads:

One simple survivor: deliver real measurable value for money to stakeholders.

Is that so difficult to understand?

Report with pictures from our Value Management experience workshop - building robots

Fri, 11 Dec 2009 00:38:12 +0000

Sorry about all these pictures, but I am very excited about this workshop ;-)

This is the setup for each team.
Prioritizing from Finance to Stakeholder Values
to Product with Product Values
to Sub-Products with Sub-Product Values
to Solutions.
to Evo Cycles.
Then build the Solutions with sw and Lego.
test with measurements
missions.
repeat.

Here you see glimpses of the Value Decision Tables, and Solution description.

Intense testing. Reality hits.

Getting better and better for every cycle (with a few occasional setbacks:-).

Every critical Product Value is quantified with Status and Goal levels.

Measure and improve.

As the teams made the Robots faster, reliability and precision challenges came.
Intensity followed by laughter. One Robot took of and hid behind the speaker.

at the toy store getting parts and discussing options.

Fantastic to see how the Value Management methods drive competition, the name Competitive Engineering really finds its place in this workshop. I have never held a 3 day workshop where the participants learned so much about Value Management (Evo/Competitive Engineering). Kudos to all the participants that stayed with it through the early frustration caused by being asked to do what they had not yet learned to do. I hope there will be many such courses to come. Congratulations with your certifications, they are well earned.

Part of a Set of slides on Project Predictability, for a Top Manager Presentation

Mon, 07 Dec 2009 16:53:54 +0000

Principles of Professional Change

You have to define your critical organizational improvements quantitatively
You have to judge all organizational strategies in relation to these critical objectives
You have to roll out change early and often, and measure the effect immediately
You have to prioritize change strategies that really work, and kill off those that don’t, before scaling up
Focus on Meta-Strategies: those that allow decentralized feedback and change during projects (like Evo and Spec QC)
Project Architecture must explicitly address quantified project objectives
All cost-driving specification must be quality controlled and have high quality (1 Major defect/page) exit levels
Projects must deliver stakeholder value incrementally and measurably
Thorough stakeholder value analysis must be used to prevent cost surprises later
Always prioritize the most efficient strategies next: high value/cost wrt risk
Sub-contract for no cure no pay, not for fixed cost or time and materials

http://www.gilb.com/tiki-download_file.php?fileId=364

Business Values are always subjective, and almost always quantifiable: an angry answer to immature ideas

Sat, 05 Dec 2009 22:48:48 +0000

A BLOGGER, FOLLOWED BY A TWITTER AND RETWEET SAID TODAY ......

"Ppl talk a lot about business value, but they forget that for most people business value is totally subjective! (i.e. unquantifiable)"

FROM TOM
To the blogger/twitterer (who could be many of you out there, not least - your manager!)

I think you need straightening out, regarding your terms
and concepts.

Of course, you don't have to get straightened out! :)

'Subjective' means, based on personal opinion, as opposed to more-objective observation
"I think he is heavy". (subjective)
"The scale shows he is 100 kilos" (objective)

Personal opinion can be quantified "I think he is about 100 kilos"

There is nothing wrong with value being subjective - in fact that is a normal, inevitable thing.
People and organizations have their own values, and that determines what they value.

Most of these values can be expressed quantitatively, if we want to, and know how.

But most often we do not quantify our value statements, because we do not feel the need, we do not need to, we don't know how.

In my opinion, your view is dangerous, and your commonly held view that is one root cause of widespread project failure.

I suggest you study (if you care to rise above your misconceptions)
top level objectives

and

vision engineering
Quantifying Stakeholder Values
Value delivery paper

and finally study the process for quantification in
ch 5 Competitive Engineering

When you have concluded, correctly, that you were wrong, misleading, and a danger to the IT community for spreading such incorrect views, you should consider blogging to illuminate your readers about your new insights.

Then consider what this might mean to the better control of agile processes (quantified values as requirements and testable outputs, and increments).

Like this
Confirmit Case

Value Driven Project Management

Your observation might be more accurate and useful if you had said.... (you can quote me):

"People are good at articulating their business values with nice sounding words ('greater efficiency') but universally terrible at clarifying exactly what they mean numerically and testably. This is one root cause of project failure. The problem with articulating business values is not that people are intellectually incapable of quantifying and defining them. The problem is that they were never trained to quantify them, nor were that asked by their organization and management to quantify them" (© Tom Gilb 5 Dec 2009)

I think I will put the above in my blog, but I won't identify you. You are after all the victim of poor education regarding quantification of critical values, like most people. The good news is you can rise above the level of your teachers, if you choose to.

Don't take this personally. It is not your fault.
But it will be your fault if you do not improve your understanding of these things.

If I seem angry - I am! These attitudes and misconceptions are directly at the heart of our horrendous IT project failure rate, and consequent lack of trust in IT. We need to learn to succeed more often than we fail. We need to deliver real expected value to society. The programmers of the world are not exactly famous for doing so. I am ashamed to be somehow related to the community. But I am fighting for change. How about you?

You might like to know there are some people who feel as strongly as I do that this immature profession needs to grow up.

http://www.semat.org/bin/view
Welcome if you want to join us.

Tom
.

SOME DICTIONARY DEFINITIONS

subjective |səbˈjektiv|
adjective
1 based on or influenced by personal feelings, tastes, or opinions : his views are highly subjective |there is always the danger of making a subjective judgment. Contrasted with objective

value |ˈvalyoō|
noun
1 the regard that something is held to deserve; the importance or preciousness of something :your support is of great value.
• the material or monetary worth of something : prints seldom rise in value | equipment is included up to a total value of $500.
• the worth of something compared to the price paid or asked for it : at $12.50 the book is agood value.
• the usefulness of something considered in respect of a particular purpose : some new drugs are of great value in treating cancer.
• the relative rank, importance, or power of a playing card, chess piece, etc., according to the rules of the game.
2 ( values) a person's principles or standards of behavior; one's judgment of what is important in life : they internalize their parents' rules and values.
3 the numerical amount denoted by an algebraic term; a magnitude, quantity, or number : the mean value of x | an accurate value for the mass of Venus.

quantify |ˈkwäntəˌfī|
verb ( -fies, -fied) trans.
1 express or measure the quantity of : it's very hard to quantify the cost.

Agile is NOT a major solution to Bad Government or Private IT Projects!

Fri, 04 Dec 2009 22:00:43 +0000

From: Tom Gilb tom@gilb.com
Sent: 2009-12-03 10:14:10 CET
To: Frederik Hermann Siegumfeldt frhs@itst.dk

Subject: here is a summary of my 5 oral remarks after your talk at Agile 09 Copenhagen 2 Dec09

1. Agile is not any kind of main solution to the problem of failed or bad government projects.
It has no track record of doing so
Iteration (aka Evolutionary, US DoD Std 494, 1994, an Evolutionary standard, distancing itself from Waterfall) is a very useful principle, long before the 'Agile' era.
But you must not confuse Rapid delivery cycle feedback, with Agile. Agile (like Scrum, actually does the feedback process very badly! The requirements are screwed up, so feedback works badly, see 2 below)

2. The primary problem with large projects today, in my extensive international experience, is "THE LACK OF CLARITY AND FOCUS ON THE TOP FEW CRITICAL OBJECTIVES OF THE PROJECT."
http://www.gilb.com/tiki-download_file.php?fileId=180
Eight CASE STUDIES
and also

http://www.gilb.com/tiki-download_file.php?fileId=237
Vision Engineering: how to convert management phrases into measurable targets and measurable strategies.

The problem is that projects, agile or not, fail to set really clear objectives (quantified improvements in several critical dimensions, like efficiency, productivity, responsiveness, ease of use, security, maintainability, adaptability). h development and test teams are not at all focussed on these wooly objectives, They are in fact forgotten forever.

Projects then fail to deliver actual expectations and hopes, to the woolly goals.

3. Systems Engineering: the IT and Software culture is incredibly 'algorithmic centered'. Their whole world is 'delivered code' (even databases are almost never mentioned!).
The problem is that delivery of value requires much more than some functional code, and in many cases we can deliver value best by NOT developing ANY code, even for an it system! For example by training or motivating users or passing a law or implementing a management policy or writing a contract.
So, our REAL solution, needs to be explicit about the DEVELOPMENT ENVIRONMENT. The development environment CANNOT BE LIMITED TO COMPUTER CODE. One way to do this is to focus on real value delivery, and allow ANY MEANS TO GET THERE.

Another view of the same thing is to officially adopt the SYSTEMS ENGINEERING paradigm (INCOSE.ORG). To say " we are systems engineering, we use any hardware, software, or human-organizational 'technologies' to reach our VALUE DELIVERY objectives.

Admittedly, Scrum, as taught by Jeff Sutherland, can be used for projects of any kind, because the essence is simply a rapid cycle feedback learning loop (which Scrum did not invent by any means).
BUT, most Scrum users we know, are code-centric. They do not apply a systems wide perspective.

So, if DANMARK is going to solve the problem of successfully building large government systems WE MUST SHIFT TO A 'SYSTEMS ENGINEERING' (Incose.org) paradigm.
We must put the coders in their place, as one technical component of a larger project, if used at all to solve some problems! People built large national systems without software milleniums ago!

4. The problem with getting successful IT systems is NOT 'the right process' (agile or other).

It is the motivation to deliver value! We have no such motivation. In fact we have negative motivation!

If the projecr runds over cost and time, the suppliers earn far more money

(FOR EXCELLENT DOCUMENTATION SEE Craigs book: Plundering the Public Sector
http://www.amazon.co.uk/Plundering-Public-Sector-David-Craig/dp/1845293746

My suggestion is that we must move in the direction of NO CURE NO PAY contracting. Suppliers only get paid for value delivered, not work done.
http://www.gilb.com/tiki-download_file.php?fileId=38 no cure no pay paper
http://www.gilb.com/tiki-download_file.php?fileId=85 ncnp slides

THE GOVERNMENT SHOULD LEAD, ON MAKING THIS THE NORM!

PS the combined mafia-like (I can't think of a nicer description) forces (D. Craig, book above and below) of Accenture, CSC, Price Waterhouse and their like will massively oppose this. We need strong political leadership. Is anyone in Denmark strong enough to make this happen? Not yet!

5.THE MAFIA CONSPIRACY:
as mentioned SEE Craigs book: Plundering the Public Sector
http://www.amazon.co.uk/Plundering-Public-Sector-David-Craig/dp/1845293746
The biggest problem is not technical. It is about money and power.

See the tragedy of medical systems IT
http://www.computerworld.com/s/article/9141428/
Harvard_study_Computers_don_t_save_hospitals_money?taxonomyId=12&pageNumber=1

THIS IS SO MUCH BIGGER THAN 'AGILE' !
The Prime Minister should lead, and ministers should also support and lead.

Should Denmark have the courage and ability to tackle these problems, I would be happy to help in various ways.

There are no leaders in the world on these issues: be a world leader, Denmark, in stopping to pollution of bad IT projects in government.This is also an 'environmental' problem!

Tom

Systems Architecture and Systems Engineering?

Tue, 17 Nov 2009 14:27:11 +0000

MY ANSWER,
TO THE EMAIL QUESTION COPIED AT THE BOTTOM OF THIS BLOG

NOBODY AND NO 'BODY' HAS AGREED ON A SATISFACTORY DEFINITION IMHO OF 'ARCHITECTURE'
Our profession (as Mark Maier, maiermw at gmail.com, pointed out in a chapter The Art of Systems Architecting) has no agreement on the meaning of (systems) architecture, let alone engineering.

It becomes consequently arbitrary to train and certify them.

KOEN ON 'WHAT IS ENGINEERING'?
I like to defer to the deep thinker, Billy V. Koen, and I agree with his conclusions

http://online.engineering.illinois.edu/webcourses/seminars/ETC/notes/01-24-07.pdf
slides

http://www.cse.hcmut.edu.vn/~minhle/congtackysu_2008/Engineering_Method.pdf
paper

http://www.me.utexas.edu/~koen/OUP/OUP.html
book - a remarkably deep book !

CAN WE EVEN AGREE ON THE COMPLEX NOTION OF REQUIREMENTS?
Actually, since engineering and architecture are completely dependent on the notion of requirements, it might be interesting if we found mature agreement on the concept of requirements! Most of the real world is in a terribly confused state about it, in my view. It is then premature for the same world to decide what an engineer or architect is to do.

HERE IS MY LATEST PLANGUAGE DEFINITION OF REQUIREMENT
A ‘requirement’ is a
stakeholder-prioritized future state.

ARE ARCHITECTURE AND ENGINEERING DIFFERENT?
I believe that they are essentially identical as disciplines. The practical and immediate temporal distinction being scope and viewpoint alone.

"JUST CALLING SOMETHING BY A NAME, DOESN'T MAKE IT SO" (G M Weinberg)
We choose, arbitrarily, to say 'architecture' when we want to emphasize something more whole, more complete. And we say 'engineering' when we wish to emphasize something more specialized, and more of a subset of the architecture we referred to. There is a human communication needs difference. But I do not believe there is a difference in the necessary logical processes to carry out the disciplines, whatever they are named, properly.

Those disciplines, in my personal view, are thoroughly described in my CE book, and my many papers and slides (gilb.com).

SO WHICH VIEW OF ARCHITECTURE AND ENGINEERING DO I BELIEVE IN?
Here is a summary of my direct answers to the 3 options described, below (they are 'in place' there, below)

GILB COMMENT: both disciplines must necessarily find the 'designs'/'solutions' (how?), to meet the requirements (what=function, how well = performance levels, constraints = limits on solution). The only difference is one of detail, and level of consideration.

GILB COMMENT: YES. Architecture is a logically necessary 'swim lane'; which will 'narrow in' on the next set of engineering approaches. An architect for example might choose a 'buy' or 'maintain old system' avenue, rather than a 'build new system' avenue - thus radically changing the disciplines needed downstream. 'Legal/Procurement Engineering' anyone?

GILB COMMENT: the level of experience is immaterial. Good electrical engineers do not become building architects. Both disciplines need intelligent, trained and experienced people, using logical methods to achieve their purpose. Both need access to information that is not in their personal memory.

Tom

MY FORMAL DEFINITION OF CONCEPTS RELATED TO ARCHITECTURE AND ENGINEERING
ps here is a subset of my Concept Glossary, re Architecture and Engineering
engineering and architecture concepts - below is a subset )

http://www.gilb.com/tiki-download_file.php?fileId=287

The full Glossary is at
http://www.gilb.com/tiki-download_file.php?fileId=25

=== here is the email I got today 17 Nov 2009, from Daniel in NJ

Tom,
I found your paper (“Systems Architecture: a View Based on Multiple Impacts”, http://www.gilb.com/tiki-download_file.php?fileId=47) in the INCOSE SAWG web site. I realize that this paper is a couple of years old now, so I was wondering how you view the current initiatives to certify or credential systems architects. How do you view systems architecture in relation to systems engineering? I have encountered at least 3 fundamentally different perspectives on this.

Architecture is emerging as an engineering science separate and distinct from systems engineering. Architects envision the "what" with out-of-the-box thinking that creates solutions that may leverage existing solutions but are not constrained by them. Systems engineers, then, add flesh to the architecture's bones by sweating the details of "how". Those interested in creating new departments (that they can Chair or lead) tend to be attracted to this view. Does that necessarily make it invalid? Companies and organizations are currently standing up separate Boards to "qualify" systems engineers and systems architects. Does this imply that they are distinct engineering disciplines?

GILB COMMENT: both disciplines must necessarily find the 'designs' (how?), to meet the requirements (what=function, how well = performance levels, constraints = limits on solution). The only difference is one of detail and level of consideration.
-----
Architecture is a level of proficiency in that the most experienced and capable systems engineers are qualified to be architects. A novice systems engineer may be good at requirements development or functional modeling but inexperienced in verification planning or discrete event simulation analysis. Architects who lead the team must be reasonably skilled in all these areas. I have had two architects from what was once Bell Labs tell me that this is how the term was used in that industry. "The architect was what every systems engineer wanted to grow up to be." I tend to call this the "Jedi Master" definition since the architect has to do everything that the SE does--only better.

GILB COMMENT: the level of experience is immaterial. Good electrical engineers do not become building architects. Both disciplines need intelligent, trained and experienced people, using logical methods to achieve their purpose. Both need access to information that is not in their personal memory.

---------
Architecture is one of several skill areas that a systems engineer must master. The older engineers will tell you that before Zachman hit it big, we were all systems engineers. We did the same flow diagrams and network layouts, but those were not called architecture artifacts in those days. Architects may not need to do operational analysis trades or verification plans, but systems engineers do. If the previous perspective is thought of as a vertical relationship with architects being at the top of the SE pyramid, then this one might be characterized as the horizontal view with architecture just being one of the "swim lanes" of the total skill set needed for systems engineering-along side requirements analysis, operational analysis, verification, etc.

GILB COMMENT: YES. Architecture is a logically necessary 'swim lane' which will 'narrow in' on the next set of engineering approaches. An architect for example might choose a 'buy' or 'maintain old system' avenue, rather than a 'build new system' avenue - thus radically changing the disciplines needed downstream. 'Legal/Procurement Engineering' anyone?
------

Are you aware of any work being done to clarify the roles of systems architect vs. systems engineer? With these three diverse views out there (at least), we seem to be a long way from reaching consensus.

I would welcome your thoughts.

7 truths about Agile and Scrum that people don't want to hear. Part 1 of 7 Wrong Focus!

Mon, 02 Nov 2009 00:18:30 +0000

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

Part 1 of 7: Completely wrong Focus: Agile & Scrum is not focused on delivering values to stakeholders for a minimum or a reasonable cost.

As developers, project managers, product owners etc. we earn our living by delivering values to stakeholders, by giving our stakeholders improvements to whatever they do, at a cost they are willing to pay. The systems we develop must therefore first and foremost deliver value efficiently. Deliver agreed value to stakeholders, within agreed or reasonable development resources. The problem is … that is not what Agile is doing in practice, good intents to the contrary.

From the Agile Manifesto http://agilemanifesto.org

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The Agile manifesto, being the centerpiece of Agile, states its main values, but does not mention a word about delivering specific and varied values to stakeholders. Agile is far too centered around the developer. The world is seen from the eyes of the developer, the world revolves around the developer. The earth was once considered the center of the universe? Yes there are some customers, and even though not mentioned, some managers, sales people, users etc. They are out there spinning around us developers. But that is not really important enough to analyze in detail, agile is what we value as developers!? Make life easy for us - really delivering measurable value is secondary.

All the ideas in the Agile manifesto are 'solutions' to what is seen as convenient for developers. They are not a set of solutions to solve the challenges of our project, nor for our stakeholders. They don’t even know what these stakeholders and their many values might be. How can one declare in a manifesto, “this over that” without knowing the real ends. What if “that” would better satisfy my stakeholder needs? The Manifesto is overgeneralized, and should instead instruct us better on how to make intelligent decisions for our stakeholders.

Lets look at Scrum, the most popular Agile development practice in 2009. Here is the commonly used process diagram. http://en.wikipedia.org/wiki/File:Scrum_process.svg

Where, in the Scrum process diagram, is 'delivering value to stakeholders'? Not there is it? It is assumed that someone up there is picking valuable stuff to develop. We develop it, and it is valuable??? In alignment with the Agile Values, Scrum has as an output, “working software”. Guess what, who cares if your software is working!

The interesting questions are;

Does the software deliver improved value of any kind to my stakeholders?)
If yes. How much value of what kind?)
When and for how much resources?)

I have experienced lots of “working software” over the years that has giving me negative value. Hard to use, problem prone, slow, feature overloaded software that is “working”. Give me sw that is faster, easier, more secure and that improves my ability to do what I want to do. That is what I want. That is the type of thing that your stakeholders want, and that they are paying us for.

Wait, you might say defensively, what about the Principles behind the Agile Manifesto http://agilemanifesto.org/principles.html
The first principle on their list is:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

So they put this up together with some other principles. That is swell, but it is on the second page. It needs to be on the first page, probably alone, and more sharply formulated, not mixing the goal and the solution: hint "through" - there could be other better means - sometimes!.

And reading further down this list of principles, this principle has to compete with a long list of other principles, like

“Working software is the primary measure of progress.”

Guess what, have you heard the expression, “what gets measured gets done”. So if you measure progress as working sw, lets say through a burn-down chart, then what gets done? “Working sw” gets done. Not “Our highest priority” not value to stakeholders.
It needs to say: we measure progress through the amount of value we have delivered to our stakeholders.

I recently worked on a project that was very successful in the eyes of the Scrum team that developed it, a very competent team. The product had all the functions and user stories it needed, it looked nice and professional, was developed within costs, working sw etc., but the business owners where screaming loudly, since the 'working' product resulted in less sales, than the product it replaced. We re-did part of the product with 100% focus on delivering value improvements to the stakeholders. We did this with the same Scrum team, we just gave them a very different focus.

This is a message, as loud and clear as I can be, to all fans of Agile.

It is not about working software. It is not about your preferred working process. It is not about user stories. It is not only about your customer or user.

It is all about delivering, to your set of stakeholders, value improvements, which they care about, which makes their world better, within agreeable, minimum or pre-determined costs.

If that is not the main focus, if that is not clear to everyone on the team, you will eventually lose! If your methods are not focusing on delivering that value, as todays most popular Agile methods are not, they will fail to deliver, they will become last years fad.

What do you do? Develop sw? No, you (should say) deliver value to stakeholders!

Your truly
Kai Gilb

I don't really need to write part 2 to 7 do I? This one is in-itself such a huge issue. But I will, stay tuned.

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

7 truths about Agile and Scrum that people don't want to hear. Part 0 of 7 Introduction

Fri, 30 Oct 2009 15:33:06 +0000

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

Introduction

Sw development is a creative process where there are seemingly infinite numbers of ways to achieve a defined functionality. But even when a set of functionality is equal in two products, the various qualities of the functionality vary widely. With qualities I mean attributes like performance, usability, stability, availability, portability, security, etc.

Project management methods typically do not take this creative nature of sw development into account, they assume a straightforward model using known solutions. The methods assume it's like building a house, the same way as building another house, just built. While building such a replica house, a management method of tasks and timeframes might be suitable. For sw, these methods could be applied for duplication of already written sw, but they would have little, if anything, to do with sw development. It would be convenient for management if sw development could be managed as a set of tasks with known costs and pre-determined quality attributes, but that is simply not the case.

In addition to sw development being a creative process, there is the fact that what customers and other stakeholders want and need, they don't normally know up front; nor do they know how to express them. Even if they did know, their needs and wants change quickly.

So sw developers were historically “managed” with methods that ignore this dynamic quality environment. With rigid, top-down, frozen Requirements, they planned everything in detail first, and then went and coded it afterwards from the specifications. Failure projects were the norm (as they still are with agile) and frustration was high among developers. Out of this frustration among developers, Agile methods became popular. Agile methods were developed by developers, not by management, marketing, nor finance experts.

Most developers I come across, that are working in an Agile development environment are fairly happy with the process; but there are many serious challenges with Agile. Not all parties are happy with Agile, the popular Agile methods are not necessarily suitable to all situations, many faults with sw development are not fixed with Agile.

In this blog series that will be written in 7 parts, or blogposts, I will highlight 7 major challenges and hint as to what needs to be done to rectify them. Most writings on Agile, talk about its glory, here I will write about the faults: faults that are so serious, that if not rectified will ensure that your favorite Agile method will become last year's fad.

Disclaimer:
I generally like Agile, Scrum and XP a lot. I am a personal friend with Jeff Sutherland, have had a private very enjoyable dinner with Kent Beck and his family, I am a personal friend with Craig Larman, and I know Alistair Cockburn and Mike Cohn. It is with great respect for these, and other Agile people that I write this blog series. They have made huge contributions in the forward movement of the awareness of Agile sw development.

^Agile & me:
Having grown up with the grandfather of Agile, Tom Gilb. I have been teaching and literally fighting the established waterfall based methods my whole career. I remember some 16 years ago, teaching and coaching 1 week value delivery cycles to the likes of Ericsson. At the time people thought we were crazy. The Agile community did not exist yet, not even the word Agile. We were more or less alone with the message of short delivery cycles. An article we (I co-authored) wrote for an internal company magazine was censored by the company’s method owners (Tom & I nicknamed them the waterfall mafia). They had no arguments against our Agile message, but they had the power. We were 20 years ahead of our time (Tom even more). As you might see, I’m born into Agile, but there is trouble ahead, the Agile community needs to wake up … (read on)^

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

On Teaching Fundamentals for Software Engineering - and maybe even Programming?

Sat, 03 Oct 2009 20:04:15 +0000

A public email, in reference to some idealistic efforts to improve our trade, whatever it is.

Papers by Ivar Jacobsen, and Scott Ambler in DDJ.

http://www.ddj.com/architect/220300245

http://www.ddj.com/architect/220300840

Hi Guys
I looked for some comment place for the articles in Dobbs, but found none.

Here are some very concrete suggestions:
I'd be happy to publish this and these remarks in DDJ or elsewhere.

Paper: Undergraduate Basics for Systems Engineering (SE),
using The Principles, Measures, Concepts and Processes of Planguage.

http://www.gilb.com/tiki-download_file.php?fileId=98

The basics are the same for software engineering.

Scott and Ivar (good and deep people both!)

I agree with both your points, up to a point.
We have no decent foundations. We don't even have a culture that seems to care about it. Agreed.

One major difference, is that I read you guys as being 'mere programmers', in culture, and certainly not software engineers. And I do not think you agree or realize it! You are like most of your community.
'Code is it', not 'results for stakeholders', and certainly not anything real engineers would recognize as engineering!

We have misused the term 'software engineering' so long (we used to call it programming) that we seem to believe that programing is software engineering. In my 1988 Principles of Software Engineering Management (now in 20th printing, what does that mean?) I coined the term 'Softcrafters' for you lot.

Nothing wrong with being a good craftsperson! But when Carpenters start calling themselves engineers and architects, most of the world smiles at their ignorant and childish self-aggrandizement. Or do we agree with the US term 'Sanitation Engineers' (Garbage Collectors).

So the first thing you need to take a position on is your domain. Programming, or Engineering!

Even if we had two parallel and related efforts:
1. Master Softcrafter
2. Software Engineer

The bigger problem, I fear, is no one cares enough to change.

Why should we, we have great success at ripping off the world. Why change?

I am already working on the Software and Systems Engineering problem (since 1976 and before, 'Software metrics'), with whoever cares. You are not working on that domain as far as I can see?

I hope you will decide to develop the theory of programming! But be clear about it and don't mess with 'engineering'.

Yesterday (Oct 2 - 09), I made a collection of my (and others) principles - from my Competitive Engineering book, available.
Maybe some of them apply to programming?

http://www.gilb.com/tiki-download_file.php?fileId=352

The principles collection might have something of value to the softcrafters: Here is one I picked because it touches the essential difference between coding today (does not care much about quality or cost, is very centered on function ).

2. The Principle of ‘Thing with Attributes’

A function is the thing, which has the performance and resource attributes attached to it.

Here is another depth sample, regarding quantification of qualities: Chapter 5 of my CE book:
Chapter 5: Scales of Measure:
http://www.gilb.com/community/tiki-download_file.php?fileId=26

In your discussions in DDJ neither of you even mention such concepts as measurable qualities -?
Real engineers woud think that is pretty fundamental!

I think I will make this email a blog on my website, and twitter it. But the full paper (Undergraduate...above URL) is hereby offered to DDJ first!

Best wishes for a more-organized discipline - may our great grandchildren experience it!

I have long ago decided that all I can do is sow the seeds of an oak tree, and hope they are healthy -

Tom

Confirmit awarded Value Management certificate

Thu, 01 Oct 2009 22:05:21 +0000

We are very proud of Confirmit and their use of Evo. Trond Johansen and Peter Myklebust learned about Evo from us in late 2003 and realizing its potential got all its people trained and off they went implementing the Evo methods using Value Requirements, Value Decisions (IET) and Value Delivery. This has led them to the capability to deliver unheard of quantitative Value improvements (see case below) to their Stakeholders. Business success has been huge, and what Evo has done for them have been an important part of that. They have merged/bought their competitor, and they have been hiring throughout the recession ;-) They are continuing their use of Evo (Value Management).

Company Value Management Award

It is therefore with great honor that we on September 21 2009 presented Confirmit with a company Value Management certificate for Value Requirements, Value Decisions and Value Delivery. It was handed over to Trond Johansen (right)(Head of R&D Confirmit Norway) who is the great champion for Evo and Peter Myklebust (left) who is the supporting angel (CTO).

Click on graphic above to download a presentation about their early experiences.

http://www.confirmit.com/software/technology.aspx
Confirmit creates powerful feedback, survey, reporting, and business solutions.

Flyer for next workshop in Oslo

May you continue to evolve Evo within Confirmit and have many more happy users in years to come!
Sincerely Tom Gilb & Kai Gilb

The Engineering Productivity Principles

Tue, 29 Sep 2009 13:54:43 +0000

The Engineering Productivity Principles:

Here are some basic suggestions for a framework for getting control over engineering productivity:

1. Subjective Productivity: Productivity is someone’s subjective opinion of what values we want to create for our critical stakeholders.

2. Measurable Productivity: Productivity can be defined as a set of quantified and measurable variables.

3. Productivity Tools: Productivity can be developed through the individual competence and motivation, the way we organize people, and the tools we give them.

4. Avoid Rework: The initial attack on productivity improvement should be reduction of wasted effort

5. Productive Output: The next level of attack on productivity should be to improve the agreed value delivered to stakeholders.

6. Infinite Improvement: Productivity improvement can always be done: there are no known limits.

7. Perfection Costs Infinity: Increasing system performance towards perfection costs far more than increasing volume of system function.

8. Value Varies: Product attributes are viewed and valued quite differently even by members of the same stakeholder group.

9. Practice Proves Productivity: You cannot be sure how well a productivity improvement strategy will work until you try it in practice

10. Productivity Dwindles: Yesterday’s winning productivity tactic may not continue to work as well forever.

From a paper I forgot to put on the website until today!
I am looking for some places to publish it, websites, periodicals, conferences - suggestions welcome

http://www.gilb.com/tiki-download_file.php?fileId=347

Value Delivery Achievement Awarded

Thu, 03 Sep 2009 11:28:52 +0000

Award

We are proud to announce that Jens Egil Evensen has attained certification level Praxis of Value-Requirements & Value-Decisions and honorary awarded Maestro level of Value-Delivery.

To be awarded Maestro level of Value-Delivery, Jens has perfected the art of delivering high value to stakeholders early.

Among other achievements, he was assigned a job to lead the implementation of a Customer Relations Management (Microsoft Dynamics CRM) system at a Norwegian company in the telecom business. He could have done what other project management methods would lead you to do (including Agile methods like Scrum). Find the functionality needed, build and roll it out. But being a great student of Value Delivery (Evo) he asked.

who are the main stakeholders?
what Value improvements do they want?
how can I deliver the Value improvements early?

Through asking the right stakeholders the right questions (hint: why?) lead Jens to a path of discovering, that the telecom company was losing NOK 75.000.000,- (∼US$ 12.300.000.-) per year in outgoing contracts. The telecom company was not aware they lost these contracts before long after the fact and none of this was at all visible from the outset of Jens assignment.
He then refocused his whole groups efforts on delivering a system that flagged the outgoing contracts and sent them to the right people for action, before they ran out.
This effectively stopped the loss of the NOK 75.000.000,- per year, and it is reported to still be bringing in the huge savings.

And how much time did this tremendous achievement take? 2 weeks!
Congratulations Jens, that deserves a Maestro level of Value Delivery. Jens then continued to roll out the CRM system, now with infinite support from top level management, all the time focusing on delivering maximum value to stakeholders.

We are proud to have Jens on the team of certified Value Management experts, he is bravely following the Value Management principles where others nod but cave in to norms and other pressures.
Tom & I highly recommend Jens when you need help with managing your projects.

Jens Egil Evensen
EDB-Avenir - Dynamics CRM, BI, .NET
jens.egil.evensen at avenir.no

Meetup for certified Value Management (Evo) professionals in Oslo.

Fri, 29 May 2009 11:40:56 +0000

Value Management and Contracting.

We will discuss Value Management and contracting.

This meetup is an invitation only meetup for certified Value Management professionals (Evo). If you are not certified but have received training from Tom or Kai before we started with certification, and you would like to attend, please email kai at gilb.com

Time: tuesday 9 june at 1930
Place: The Scotsman
Karl Johansgate 17
Opp 3 etg. eget møterom.

Sincerely Tom & Kai Gilb

Real Quality Assurance - not Test called 'QA' a Manifesto and a Paper

Tue, 26 May 2009 15:17:07 +0000

^UPDATE: we have the Real QA Manifesto up on this site where you can sign it if you can stand behind it.
Go to Real QA Manifesto(Kai 27 May 09)^

Real QA is far more than testing!

I think it is time to start a small revolution, at least to post a manifesto and see if anybody wants to join the revolution ! it should be on this website this week.

Real QA Manifesto
http://www.gilb.com/tiki-download_file.php?fileId=285

RealQA Paper
http://www.gilb.com/tiki-download_file.php?fileId=286

We will support discussion on this site

QA Objectives

1. NO SURPRISES ASSURANCE: To allow management to understand release consequences fully, in relation to expectations, with the lowest costs, the lowest risks, and the lowest degree of surprises.
2. MEET EXPECTATIONS: To make sure that the project investors and sponsors get, at least, what they expect.
3. BUSINESS PERFORMANCE: To deliver the ‘business’ (or organisational) results envisaged and promised to project and programme supporters
4. TECHNICAL PERFORMANCE: To measure the technical performance (including all Quality attributes) attributes of the system
5. CONSTRAINT COMPLIANCE: To ascertain that the system has not violated any specified constraints.
6. LONG TERM ASSURANCE: To give some assurance that the long term characteristics of the system are as planned. Things like adaptability, maintainability.
7. LEGAL COMPLIANCE: make sure the system is always compliant with legal and other compliance policy items.

Usability Engineering Principles

Fri, 01 May 2009 22:17:51 +0000

Usability can be ‘engineered’ into systems.
Usability can be quantified.
Usability requirements can be quantified
Usability design and architecture can be quantified, estimated and measured
Usability levels can be measured and tested
Usability can be delivered incrementally
Usability needs depend on many parameters
Usability must be architected, not hacked
Usability must be led and driven by management as a top level requirement
Usability is a systems engineering discipline

This is the outline of an invited lecture I will hold 4 June 2009 at
Kongsberg Systems Engineering Graduation Conference (KSSE).
I have not worked out the details yet, but will probably post the slides on this site by June 5th!

Making Management Manage Metrically

Tue, 14 Apr 2009 21:01:30 +0000

Making Management Manage Metrically

Every time I am asked to look at a suffering project, I see the same very basic failing. All the project objectives are clearly vague.
This applies to projects costing over $100 million and ongoing for 8 years, as well as smaller projects. In fact, I have concluded that management everywhere have not got a clue as to how to set clear objectives for projects. The problem is management’s vague nice-sounding phrases: though not in deadlines, sales targets, and budgets.

Here are 3 real examples from the top 8 objectives for a $160 million, 10-year project failure.

“Will provide a much more efficient user experience”.

“Robustness is an essential system requirement”.

“A primary goal is to provide a much more productive system development environment than was previously the case”.

All the objectives had these same characteristics. Unintelligible.

The useful structure of such critical attributes is:
Objective Name:
Scale of Measure:
Goal:

They can all be expressed numerically. Here is an oversimplified example:

Robustness:
Scale: % Probability of System Failure due to defined Cause per day per user.
Goal Cause = Software Failure, Deadline = Version 1 less than 0.001 %

Management seems to wrongly accept that there are some admittedly critical, but ‘soft’ objectives. The projects themselves getting funded don’t tell the managers that they are no good at setting objectives. They happily spend the project budget many times over, since there is no way to demonstrate project progress towards the critical numeric goals. Finally management wakes up and decides they have a ‘technical’ project failure. In fact management failed!

I think we are going to need massive failure (like the Financial and Auto Industry!), and consequent government intervention to actually get managers to manage metrically. Same greedy incompetents, educated equally badly. But if someone out there wants to improve their own management performance, nobody is going to stop you introducing sanity, common sense and clear objectives. I have found a few cherished clients, and even a few corporations who understand the necessity of clear objectives.

Here is my recommended policy for this type of management:
Metric Management Policy
1. All critical objectives (expectations for improvements in quality and performance) will be expressed numerically.
2. All critical objectives will be specified unambiguously, clearly, measurably, and comprehensively – to all intended stakeholders.
3. All strategy decisions (project structure, architecture, staffing, partners) and contracting will be done with direct reference to their capability of meeting the numeric objectives.
4. All project reporting, continuously and frequently we assume, will be with explicit numeric reference to the degree to which the critical objectives are gradually being delivered to real stakeholders, on schedule.
5. The project priority will be to incrementally deliver the maximum real stakeholder values at the earliest stages.

Here are some of the advantages of deploying such a policy:
1. management will be in real control of the project
2. subcontractors can be paid for value delivered, not work done
3. delegation of detailed technical decision-making is possible, but always with reference upwards to the critical few objectives.
4. When resources are constrained mid project, a lot of real value will already be in place.
5. The Return on Investment is better controlled and likely higher.

More detail?

Vision Engineering paper 2008 http://www.gilb.com/tiki-download_file.php?fileId=237
Top Level Slides and cases… http://www.gilb.com/tiki-download_file.php?fileId=180

How To Measure an Agile Implementation?

Mon, 30 Mar 2009 15:21:42 +0000

"If you have any thoughts for the meters/scales you would use to gauge the successfulness of an agile transition, I'd love to know what they are. Thanks." .

Here is my extensive reply, which I hope others will be interested in, too.

Well, we can discuss this, and we should!
Here is a deeper perspective of how to judge ANY process
What Process http://www.gilb.com/tiki-download_file.php?fileId=51
Process slides http://www.gilb.com/tiki-download_file.php?fileId=128

These opinions above, summarized, are:

1. any process (including any agile process) needs to be judged on the multiple dimensions or attributes that are of interest to the Judge (from their local perspective, their current organizational objectives, and concurrently with any current and proposed processes, that are intended to or might inadvertently affect the (organizational) Objectives!

Simple summary: Judge process fit to your needs.

2. A process is only as good as it currently delivers to your objectives, in relation to your scarce resources, and with concurrent consideration of any and all currently available alternative solutions (like 'motivation').

So, If a client asked me that question, I would consequently ask for their Objectives, and also about other current (outside Agile, example lean or outsourcing) strategies being considered or discussed or implemented now.

Normally they have no clear set of quantified objectives, so we would develop them.

Some examples (bad reality and good recommended , sometimes actually implemented, practice) are found in these cases: (of objectives for processes, and strategies, and IE Tables)

Paper: Vision Engineering a paper related to top management vision quantification.
Slides: Top Level Objectives case studies most IT examples

The need, for serious, large organizations, to be quite specific in their own local and current objectives should be obvious.

This specificity-need does not preclude consultants and book/paper writers from suggesting useful patterns like a smart and parameterized Scale definition: example

Scale: The average % residual value delivery per Quarter.
or more complex:
Scale: The average % residual value delivery for a defined set of [Objectives] using a defined set of [Processes] by a defined set of [Professionals] in defined Corporate [Areas] for a defined [Time period] with defined [Resource Constraints] .

The current ideas of how to do this as preached by Agile Community (eg burn rate, percentage check-ins, % backlog items dropped, etc.) are - agreed - useful indicators, and it is probably a good idea for somebody to track them and learn.

BUT, I fear that THEY ARE DISTRACTING FROM THE FAR HIGHER PRIORITY EVALUATION OF HOW GOOD THE PROJECTS ARE AT DELIVERING VALUE TO 'CUSTOMERS' (AN AGILE MOVEMENT principle) - IN FACT, we should have said TO 'STAKEHOLDERS' ('Customers' is dangerously narrow).

In fact, I will go so far as to say that the entire Agile movement is doomed to disgraceful failure UNLESS it turns around and injects far more attention to its own laudable Principles
(like: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.).
Emphasis on VALUABLE.).

I know you are interested in this direction, that's why I take the time to work with you!

best wishes
Tom

DO STANDARDS INHIBIT NECESSARY AND DESIRABLE CREATIVITY ? (SOME DON'T ! :) )

Sat, 21 Mar 2009 15:49:43 +0000

I was reading some slides sent by Bob Marshall
in connection with his Rightshifting site:
http://www.linkedin.com/e/gis/990707

Here are his slides
http://www.authorstream.com/Presentation/flowchainsensei-107787-perspectives-rightshifting-flowchain-rightshift-rightshifting1-9a-science-technology-ppt-powerpoint/

No quibbles - my philosophy too

I like to think that my Planguage (CE book) gives many practical tools for doing all you talk about, Rightshifting.

One 'quibble': the statement about standards leading to bureaucracy, and that they are not appropriate to creative design etc.

Here is my Creativity argument - for some standards.
http://www.gilb.com/tiki-download_file.php?fileId=22

I would argue with Leonardo daVinci here, that rules in themselves are not stifling!

He said:
"these rules will enable you to have a free and sound judgment:
since good judgment is born of clear understanding,
and a clear understanding comes of reasons derived from sound rules,
and sound rules are the issue of sound experience
the common mother of all sciences and arts."
source: The Notebooks of Leonardo da Vinci. 18.

You over-generalise Bob, and should really modify your statement.

Many type of rules can inhibit creativity for solving the right problem in a smart way. But, there are other types of rules that can ensure that best creativity can be applied.

In particular rules that demand clear highest level objectives
Vision Engineering
Top Level Slides
...... will ensure that we can prioritise those objectives, in any creative way we discover.

So, rather than dismiss real wisdom, mixing it up with other less wise standards, we need to discover it, document it, teach it and practice it!

Here is my argument that the 'standards in Planguage/Competitive Engineering' are wisdom that should be taught. I have already packaged it for you!
Underg Basics

ON THE 33% TEAM EFFECTIVENESS OF AN AGILE INSPECTION

Wed, 18 Feb 2009 10:12:37 +0000

A Good friend of mine RG, Germany asked how we calculated remaining defects after an Agile Inspection. There was some debate with his colleagues about whether they were 33% effective (single pass, team total) in finding Major Defects, or more like 50% or more.
Here is my email answer.

The form and process for calculating remaining defects is is page 244-245 in the SQC Chapter of the Competitive Engineering book (I'll send that chapter to anyone who asks, tom at Gilb dot com)

and

and in this paper Case 2
Agile SQC Sl…
http://www.gilb.com/tiki-download_file.php?fileId=239

Here are a set of papers on this site on Inspections
AgileCutter5p http://www.gilb.com/tiki-download_file.php?fileId=64
INCOSE SQC… http://www.gilb.com/tiki-download_file.php?fileId=57

Rule Magazine http://www.gilb.com/tiki-download_file.php?fileId=192
Eng.Rev.Pro… http://www.gilb.com/tiki-download_file.php?fileId=143
Course Cert http://www.gilb.com/Inspection+Leader+Certification

The effectiveness will of course vary depending on many factors (discussed in my SI book) but, general data is given by Capers Jones papers on my website. Be careful, when Jones cites Inspection Efficiency, he is misusing english and means effectiveness, more importantly he is referring to the effectiveness of a set of inspections - THE CUMULATIVE EFFECT OF SEVERAL CLASSES OF DOCUMENTATION IE REQUIREMENTS, DESIGN, CODE. He is also referring to Inspections designed as in my book Sw Inspection, designed to maximize effectiveness (example optimum rate of 1 page per hour per engineer checker, specialized roles, 4-5 inspectors etc.).

In the Agile Inspection/SQC we are NOT trying to maximize inspection effectiveness. It is NOT necessary. We are not trying to remove defects - we are trying to measure. So the important point is
1. have we clearly exceeded the Exit level? ( if exit is max 1.0 major /page and you estimate 100 majors, you have clearly failed exit)
2. is the measure reasonably accurate ?(so that we do not accept bad defect ridden work).

How did I arrive at 33% ? Initially I guessed at this approximately ( I knew it was between 5% and 55%), and then we did 2 things that confirmed that 33% was generally the right order of magnitude:
1. we cleaned up the ones we found, predicted that we would find 1/3 of the remaining 2/3s, AND WE DID FIND THE PREDICTED NUMBER EVERY TIME!
2. In a few cases including Case 2 at GE Aero Engines, Cincinnatti Ohio and in Ericsson Germany (900 person real project) we used the 33% to calculate the project delay, as a function of bugs NOT found. Both these calculations were done blind for us of the facts, and were confirmed delays by our clients! This delay prediction could not have worked ( except for compensating errors in assumptions) if 33% was not a good estimate!

So your reality on a given day with given rules, given people, giving timing, giving motivation may vary say 10% to 50%, but 33% (TEAMS TOTAL EFFECTIVENESS, BEST INDIVIDUAL IS HALF THAT) is as good an engineering approximation as you will get, and it works in ENABLING YOU TO REJECT EXIT OF BAD WORK.

here are some of Capers data. ( see Download from others this site, listed below).

So anybody who is still not convinced can easily test by doing a series of inspection. In a classroom we did 4 consecutive days of bug finding code, I predicted the remaining bugs and how many would be found by the class next day after the coder removed the bugs we found. The coder was always sure there were near zero bugs remaining, but he was always wrong, and the predictions were always right! It is natural that people are skeptical, forgive them their ignorance! The only way people are convinced is by this prediction demonstration.

Defect Removal http://www.gilb.com/tiki-download_file.php?fileId=234

Method Effec… http://www.gilb.com/tiki-download_file.php?fileId=250

St Art 07 http://www.gilb.com/tiki-download_file.php?fileId=147m/tiki-download_file.php?fileId=252

Gilb's Law of Quantification - not done well enough by Agilistas

Fri, 06 Feb 2009 10:45:37 +0000

Taking Agile from Tactics to Strategy
Posted By Glenn Vanderburg on February 04, 2009

Tom's comment

Glenn,
Re Gilb's Law (DeMarco, Peopleware). It is one of my pet peeves that

1. Agilistas do not measure enough of the critical stakeholder values.
I believe this leads directly to lower stakeholder satisfaction with our efforts.
There is no agile principle or value against measuring critical stakeholder requirements.
But thinking like real (software) engineers (thinking about multiple measures of goodness) seems alien to the softcrafter (programmer) culture. Papers and slides on this at gilb.com

2. It is worth distinguishing between the process of 'quantification' (putting a number on it) and 'measurement' (getting feedback, and the consequent process of analyzing it and acting on that information).
Quantification, even without subsequent measurement is a useful aid to clear thinking (what is this about?) and good communication (this is the goal, gang).
Many people use the costs and difficulties of extremely accurate measurement processes (which you discussed in your 2003 blob referenced above) as an invalid excuse to even avoid quantification.
In most situations there is a cheap-enough form of measurement process that would give value for money.
There is not just one single cost of measurement. Sampling is a frequent tactic to reduce costs, yet give sufficient accuracy for useful purpose.

Keep up the good work!
Tom

feb 6 2009 comment to his blog

GilbsLaw http://blog.thinkrelevance.com/2009/2/4/taking-agile-from-tactics-to-strategy
GilbsLaw http://www.vanderburg.org/Blog/Software/Development/Untitled 4.blog

Are non-functional requirements functional?

Sun, 18 Jan 2009 15:10:22 +0000

At Mike Cohn's website

http://blog.mountaingoatsoftware.com/?p=62&cpage=1#comment-30462

There is a discussion on 'non-functional' requirements.
Here is my contribution.

January 18th, 2009 at 2:52 pm
I think you will find that ‘constraints’ is an unfortunate categorization for ‘non-functional’ requirements.
We have some agreement that the term non-functional requirement is not a good one. I seriously suggest that the many people who use it have not yet thought very deeply about requirements. I detest it and its use.
My books, that Mike refers to above go into some depth on this matter for those who wish to go deeper than this reply can do. (Competitive Engineering and PoSEM88)

I used to be confused myself, before I began to work out the terminology deeply. One way to go deep is to access the many requirements concepts in my Concept Glossary http://www.gilb.com/tiki-download_file.php?fileId=25

I used to think that ‘all requirements constrained’ (even function requirements). All requirements constrain our other choices (design, architecture, timing and more) but it is still not useful to call all non-function requirements ‘constraints’.

I got the necessary insight in a flash once, when I realized that some requirements are ‘primarily intended’ to constrain. And some requirements are not primarily intended to constrain.

They might just do so incidentally. They might incidentally inspire, seem stupid, waste resources, be unnecessary, and they might incidentally have many secondary unintended side effects. But I would not classify all non-function requirements as ‘inspirers’, ’stupid’, or ‘unnecessary’ because of these side effects. By the way non-functional (the -al) is bad grammar!

There are many interesting types of requirements that are not function requirements. See the Concept Glossary, under ‘Requirement’ for a chart of them.

The most interesting requirement type, from my viewpoint, is what I call ‘quality’ requirements. Quality requirements describe ‘how well’ a function needs to be done (as Mike points out, mostly ‘ilities’).
But, and this is true of all scalar requirements, there are two basic scalar levels of requirement, and both can be applied simultaneously. I call these two classes ‘targets’ (levels of quality we might value reaching), and ‘constraints’ (levels of quality we would value not falling below).

A simple example in my Planguage:

Maintainability: 
Type: Quality Requirement. 
Scope: All software in products, or their support systems, that we provide to customers. 
Scale: Mean Time to Completely Fix a Bug from its Existence is ascertainable. 

——– Here are 2 different constraint requirements —- 
Fail 2010, UK 24 hours 
Catastrophe 2009, Europe 1 week 

——— Here are 2 different Target Requirements 
Goal 2011, Worldwide, Games Sector Products 1 hour 
Stretch 2013, Worldwide 20 minutes.

The above concepts are explained in the Concept Glossary, but most of you can guess their basic meanings. Concepts like ‘Goal’ have a defined set of attributes such as: must be technically feasible, within budget, prioritized etc. ‘Stretch’, for example, does not have such requirements!

‘Fail’ and ‘Catastrophe’ level requirements are primarily intended to set clear lower limits. But ‘Fail’ simply means that ‘below that constraint level things are unpleasant’ (like ‘difficult to breathe’) but recoverable. ‘Catastrophe’ is a constraint that signals disaster, possibly irrecoverable (suffocation).
This is enough to hint at the potential, useful, distinctions in requirements.

Hopefully the astute reader is beginning to see what we cannot simple declare all non-functions to be ‘constraints’. It is not logically true or useful!
more at the website gilb.com
Tom

Value Management Certification & Agile Inspection Certifications

Tue, 06 Jan 2009 13:08:00 +0000

New for 2009; you can now get certification in a variety of subject.

We have had a early start, with a team that is using Value-Management to manage their Scrum development.

The project management team invited some of their critical Stakeholders, and themselves, and did a 2 day Value-Requirements-Certification workshop where they learned and specified Business-Stakeholder-Values, Stakeholder Values and Product Values.

Then they followed that up with a two day Value-Decisions-Certification workshop where the project management team invited people from the Scrum development team and a usability expert to join them. They created three Value Decision Tables (IET), one between the Business Stakeholder Values and the Stakeholder Values, another between the Stakeholder Values and the Product Values, and a third between the Product Values and Solutions. It was challenging and confusing at times, but it all came together in the end, where they could see what Solutions had the highest Value to cost, tracing the effect of Solutions all the way to the Product Values, through to the Stakeholder Values, and into the Business Stakeholder Values.

Now they can place items in the Product Backlog that will give them maximum effects on their values all the way up the value chain, and they can prioritize all the way back again, from Business Stakeholder Values through Stakeholder Values and Product Values to Solutions. They are using me as a coach, and we are excited to put this into practice and creating a decision flow.

Public Certification courses are set up in Germany, and soon we will announce a public Value-Requirements-Certification course in Norway that is in the works, and a whole set of Certification courses arranged by TSG in London.
If you would like to set up a public or in-house certification course, please contact me.

Kai Gilb

{ADDTHIS()}{ADDTHIS}

The Value of Using Numbers in Requirements

Fri, 02 Jan 2009 14:45:10 +0000

We have a Linked In Evo group
http://www.linkedin.com/groups?gid=689777
where David Peterson, GB questions the cost-effectiveness of metrics compared to intuition.
I thought I would share my reply here.
Grant Rule and Bob Marshall also give comments worth reading there.

Hi David,
Expressing a value or quality requirement quantitatively is always clearer for all parties.

Mere words are invariably open to too-wide an interpretation (ambiguity, lack of clarity). This can easily lead to implementation of something entirely different from the intended stakeholder need.

Requirements are initially 'intuitive' (I feel I need the system to be easier to use) and subjective (I feel). Nothing wrong there. Not avoidable, in fact.

The question is, do we stop there - with great opportunity for misunderstanding of the requirement. Or, do we refine the intention so that it is intelligible to all parties (stakeholders, users, developers, architects, testers, lawyers). Of course refining towards sufficient clarity for purpose is the only responsible and professional act.

It is easy to prove and demonstrate, and no one will seriously argue the opposite, that variable levels of requirements are most clearly expressed numerically. 'Easy' as a level of performance, has a potential numeric range of at least 0.0001 to 1,000,000 depending on the interpretation of a defined scale of measure. If you want 'less than 1 second for most users to learn to do something correctly", say so with numbers!

You need to distinguish between the problem of fuzziness (unclear, ambiguous interpretation) and the necessity of some people being 'general'.
It is quite appropriate for Kennedy to want to 'send men to the moon, and return them to earth safely by the end of the decade'; and to expect NASA to provide quite detailed numeric engineering as the practical interpretation of this political need. Kennedy was general, and was avoiding preempting the engineering decisions. But he was unambiguously clear, indeed testably-by-voter-with-TV clear, about the result he wanted.

The cost of actual measurement or testing should never exceed the value of doing so. Any test can be constructed so as to exceed its value infinitely.In most cases the simple and sufficient demonstration of a level of performance can be quite cheap and simple for most IT system purposes. One of our clients has a policy of never using more than 30 minutes at the end of a one week delivery cycle to test a quality level to get initial feedback (does it seem to work and be the right order of magnitude? Is there clearly the improvement we expected from the last changes?). We are not measuring for a Nobel Prize in physics. Measurement needs to be practical and cost effective for purpose. The cost of measuring 'less than 1 second' is surely more finite and controllable than 'easy to test'.
You ask 'who's to say that the product director's definition of 'easy' is the right one? '. If the product director's specification is numeric, then it will be easier for others to argue that it is 'wrong' (example: 'this is far less than major competitors must be expected to announce shortly'). It does not initially matter whether a numeric requirement is right or wrong. It matters most that it is clear. Then, the forces of culture, market, and logic, can in concert move the number to a level that is agreed by the forces in power. Right or wrong.

Metrics do not 'undervalue human intuition'. Human intuition can far more easily react to a 'bad' number, than to a vague word!

I refer you to numerous papers, slides and cases on quantification in downloads at www.gilb.com, for example:

Quant Q Paper
http://www.gilb.com/community/tiki-download_file.php?fileId=124

Quant Q SLDS
http://homepage.mac.com/tomgilb/filechute/Quantifying Quality MASTER Oct07.ppt

CE Ch5 Scales
http://www.gilb.com/tiki-download_file.php?fileId=26

Best wishes
Tom Gilb

WHAT IS DIFFERENCE BETWEEN INSPECTION WALKTHROUGHS PEER REVIEWS AUDITS: copy of answer by email

Fri, 28 Nov 2008 18:50:23 +0000

Thanks again for your last email. In particular, I was impressed with your keynote at the JUSE, Tokyo in 2008. It is very comprehensive.

TOM REPLY: THANKS, AND THE CONCLUSIONS WE MUST DRAW ARE PROFOUND, THAT INSPECTION IS NOT AN EFFECTIVE OR COST EFFECTIVE WAY TO GET BETTER QUALITY! WE MUST FOCUS ON DEFECT PREVENTION AND CONSEQUENT DEFECT INSERTION REDUCTION BY 100X, TOM

Exposing myself to the risk of being declared a persona non-grata in Norway, I would like to solicit your opinion on one more issue:
I have, in front of me, the IEEE Std 1028-1997 - IEEE Standard for Software Reviews. It defines three software review processes (i.e. Inspections, Walkthrough, and Audits).

TOM: I HAVE TO TELL YOU THAT I HAVE NO RESPECT WHATSOEVER FOR THE IEEE REVIEW STANDARDS. I FELT THAT THE PEOPLE WORKING ON IT HAD NO DEEP KNOWLEDGE AND DID NOT CARE. THIS APPLIES TO MOST SOFTWARE STANDARDS, WASTE OF TIME.

http://www.gilb.com/tiki-download_file.php?fileId=143
Here, above link 143, is a paper I wrote in anger last time I saw the bad work they do. Tom

"To the above I can also add a fourth one: Peer-reviews. So I wonder what (if at all) is the fundamental difference between the four of them?
1. I can say that peer-reviews may be characterized by the fact that one tries to organize them "without management participation".
2. I can say that, often, audits tend to be more adversarial in nature.
But I do not see a basic difference among the four reviews and it seems to me that we conduct each one within pretty similar processes and pretty much for the same purposes. Am I right? Could you please enlighten me on this subject?
Many thanks and best regards, A "

TOM:WELL, THERE ARE HISTORICALLY FAIRLY CLEAR DIFFERENCES. BUT IT IS NOT WHAT YOU CALL SOMETHING THAT COUNTS. IT I THE EXACT DETAILED REAL PRACTICE (NOT THE DEFINED PROCESS!)

Inspections,
Are the class of review processes developed by Fagan and Radice (www.stt.com, he has his own new book on this) at IBM from 1970s early.
And process improved by Gilb and Graham 'Software Inspections 1993, 2008 (Agile Inspections). They are characterized by collecting any numeric facts about the inspections and using these facts to both managed individual inspections in real time ( example fail exit if checking rate was far from optimal) and the long term (example studying the effectiveness of checking rates on different spec types, with a view to recommending/enforcing optimum checking rates).
The method of studying documentation is not necessarily sequential, and not primarily based on analysis of a primary document alone (like reading code). It is characterized by, any analysis tactic ( example specialized roles and special documents or sections of them) that best suits the Inspection Objectives ( for example measure defect density, maximize effectiveness, help engineers learn specs).

Eng.Rev.Pro… http://www.gilb.com/tiki-download_file.php?fileId=143

Walkthrough,
Structured walkthroughs were the immediate ancestor at IBM of Inspections. IBM carried out research which showed that they were very much less effectives in identifying defects than Inspections. They died at IBM there. But many cultures like the format and are not concerned with numeric engineering results.
The idea there was to sequentially analyze source code (in theory logic design) with one person reading it to a group and the others using this to trigger analysis and hopefully recognition of bugs or problems.

'Parnas Inspections' Googled is a source of the best current practices - but it is radically different from what we call inspections above. I would say he misuses the term Inspection, but who can stop him!

Search Results
DBLP: David Lorge Parnas
60, David Lorge Parnas: Inspection of Safety-Critical Software Using Program- Function Tables. IFIP Congress (3) 1994: 270-277 ...
www.informatik.uni-trier.de/~ley/db/indices/a-tree/p/Parnas:David_Lorge. html - 80k -Cached - Similar pages -
8 The Parnas Way
The Parnas approach to software inspection offers a rigorous mathematical ap- ... Some of the key features of Parnas inspections include. PaW:01: ...
www.springerlink.com/index/t22025m7n31v62w4.pdf - Similar pages -
Prof. Dr. David Lorge Parnas: Software Inspections We Can Trust
Dr. David Lorge Parnas: Software Inspections We Can Trust. Software is devilishly hard to inspect. Serious errors can hide for years. ...
www.informatik.uni-stuttgart.de/kolloquium/WS99/ ProfDrDavidLorgeParnas19991213.html - 3k - Cached - Similar pages -
Successful software engineering research
12 Parnas, D. L. "Inspection of Safety Critical Software using Function Tables ", Proceedings of IFIP World Congress 1994, Volume III, August 1994, pp. ...
portal.acm.org/citation.cfm?id=279464 - Similar pages -
by DL Parnas - 1998 - Cited by 8 - Related articles - All 5 versions
Myths and Methods: Is There a Scientific Basis for Y2K Inspections ...
@misc{ parnas-myths, author = "David Lorge Parnas", title = "Myths and Methods: Is There a Scientific Basis for Y2K Inspections? ...
citeseer.ist.psu.edu/11279.html - 20k - Cached - Similar pages -
by DL Parnas - Related articles - All 6 versions

Audits (normally used for Process Audits). To the above I can also add a fourth one:

One model is audits of process standards such as CMMI
They use sampling of actual process performance, to determine if an organization is actually following the practices proscribed, or the ones they claim they are following. This is totally different from examination of documents, specification and code.

However, there are some who choose to use the term audit for specifications
http://www.volere.co.uk/auditing.html
Most software people do not use this termiology for specifications.

Review is a generic term which can include inspection, peer reviews, audits and walkthroughs

Peer-reviews.
Peer reviews means that people judging the specification are normally not the hire-and-fire managers of the document author, nor are they full time checkers or inspections. They are people of the same type. level s the document author. In fact next time they may be reviewed by the people they were reviewing today. The primary idea is the protect the author from being threatened, so they can be honest about their defects. The implication is that defects counts for individuals are confidential and management will neither ask or expect to get them (it would destroy any chance of learning the truth). So any inspection, walkthrough or even audit could be carried out by peers in principle.

CHAPTER OF CE BOOK ON SPEC Q C (AKA INSPECTIONS)

Cutter 5 pg http://www.gilb.com/tiki-download_file.php?fileId=64
INCOSE SQC… http://www.gilb.com/tiki-download_file.php?fileId=57
Agile SQC Sl… http://www.gilb.com/tiki-download_file.php?fileId=239
Rule Magazine http://www.gilb.com/tiki-download_file.php?fileId=192

Agile Ins key… http://www.gilb.com/tiki-download_file.php?fileId=239
Ins Facts Mg… http://www.gilb.com/tiki-download_file.php?fileId=88

Is 'Design To Cost' better than 'Estimation of Cost': I think so!

Fri, 28 Nov 2008 16:02:37 +0000

I just realized that I never made my 'estimation' views available.
So this paper is now on our website. I'd be happy to write a full paper for publication if someone invites me to do so.

http://www.gilb.com/tiki-download_file.php?fileId=259

The essence is that I am very unhappy with most all conventional thinking about software project cost estimation, the the Agile Story culture is no exception. Barry Boehm's COCOMO that long ago recognized that there are at least many dozen cost drivers (such as the availability level) is clearly much more realistic for large and complex systems.
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

I think the Agile Gang do not care about quality in any serious way, and certainly not the way a systems engineer has to worry for space and military projects.

But there is something that Boehm (who I admire greatly!) seems to have missed, Spiral Model notwithstanding. Something that Mike Cohn, the Agile Guru does recognize

http://www.youtube.com/watch?v=fb9Rzyi8b90

home page
www.mountaingoatsoftware.com
blog
http://blog.mountaingoatsoftware.com/

That if you actually do the project, with your team, architecture, and processes, in many early small increments (not really a feature of Spiral Model) you can get a practical insight into what things really cost, and adjust your estimates for the remaining project duration accordingly.

So, at the extreme, any random number, or politically interesting number, can be used as the initial estimate, but week by week a more realistic estimate can be made. And... week by week we can attempt to 'design to cost' so as to increase the probability of meeting any previously committed budgets or deadlines.
Well, here are my views:

Estimation or Control?
• Accurate estimation is impossible for complex technical projects, but keeping to agreed budgets is still possible using feedback and change.

Version: initial draft: 28 December 2006, Latest =29 12 06
First public release Nov 29 2008: at gilb.com.

© Tom at Gilb.com

Introduction
Accurate estimation of complex systems and software projects is seemingly impossible to guarantee. There are many unavoidable reasons for this. Even when estimation seems to work, this might just be a case of stopping the effort when the budget runs out, but as a result - delivering systems of unacceptably low quality.
The main idea of this paper is that there is a constructive alternative to bad estimation processes.
o You use ‘process control’ (do a little, learn quickly, change quickly) to quickly and continuously tune anything and everything about your project, so that prioritized budgets (like time to market, money, human resources) can be met.
o You consciously sacrifice less-holy things for your more-holy things
We are better off stipulating reasonable resource constraints (deadlines and cost budgets) and then learning to live within them. This is acceptable as long as we get our highest priorities satisfied when resources run out. The rest is by definition, marginal.

Why we cannot estimate project costs accurately:
o We do not define requirements well enough to estimate their costs
o We do not collect or have access to experience data that would allow us to estimate costs, even if we did have clear requirements
o Even if we did have historic data for the costs of meeting clear requirements, it would probably not help much because our new project would be different in some way.
o

We do not really need time and cost estimates:
o They are an old custom, intended to prevent overruns, and to give management some feeling that the job will get done in time at a reasonable cost. But they do not in fact prevent overruns or assure value.
o What management needs is delivery of some critical system requirements in a predictable time frame
o And they need to be sure that the project will be profitable, and not embarrass them with unexpected losses.
o This paper describes an alternative way to achieve these management needs.
__
Principles of Resource Control__

The Risk Principles

1. DRIVERS: If you have not specified all critical performance and quality levels numerically – you cannot estimate project resources.
2. EXPERIENCE: If you do not have historic data about the resources needed for your technical solutions - you cannot estimate project resources.
3.ARCHITECTURE: If you do your project solutions all at once without learning their costs and interactions – you cannot expect to be able to estimate the results.
4.STAFF: If a complex and large professional project staff is an unknown set of people, or changes in mid project – you cannot expect to estimate the costs.
5. SENSITIVITY: If even the slightest change is made after an ‘accurate’ estimation, to any requirements, designs or constraints – then the estimate might need to be changed radically. And – you probably will not have the information necessary to do it, nor the insight that you need to do it.

The Control Principles

6. LEARN SMALL: Do projects in small increments of delivering requirements – so you can measure results and costs against estimates.
7. LEARN ROOT: If incremental costs for a given requirement deviate negatively from estimates – analyze the root cause, and change anything about next increments that you believe might get you back on track.
8. PRIORITIZE CRITICAL: You will have to prioritize your most critical requirements and constraints: there is no guarantee you can achieve them all. Deliver high-value for resources-used first.
9. RISK FAST: You should probably implement the highest-risk ideas early, so you have plenty of resource to deal with their uncertainties.
10. APPLY NOW: Learn early, learn often, learn well, and apply the learning to your current project.

Some Constructive suggestions to people who want estimates.
• Stipulate one or more useful deadlines from you point of view.
o Be specific about what has to be done by each deadline.
o Ask if these deadlines seem reasonable for the tasks prioritized.
o If necessary make adjustments.
• Stipulate the value to you of reaching each major (top 10) requirement. Make an outsourcing contract and pay part of that value only when that requirement is successfully delivered.
• Do business with suppliers who consistently deliver value for money. Don’t waste your money on suppliers who make excuses. ‘No cure, no pay’ is one way to motivate suppliers to give you value for money – otherwise their motivation is to keep billing you forever.

GETTING MANAGERS TO REALLY INVEST IN CHANGE, IN BAD TIMES WITH SMALL BUDGETS

Wed, 26 Nov 2008 15:37:10 +0000

On 26 Nov 2008, at 15:37, L. Lars wrote:

Same as "always"; how do we get management to understand the need for improvement. In these days there are a lot of problems in Swedish companies due to the economy. A century ago, when the times were "bad", they fixed the machines, cleared out all problems and generally prepared for better times! I read that the situation in Norway is a lot more positive at the moment.

In the last problematic years, around 2000, I observed the same thing. Companies in other countries were more positive, less problems to sell in process improvements. The management here does not want much improvement since "we can not afford it"...

Lars

OK! Good question!

1. Sometimes the present management is hopeless and suicidal - meaning they would rather allow the company to go bankrupt than to manage well. Nothing we can do except to work with companies who actually care.

2. In some companies there is a new top manager trying to justify his appointment, anxious to make his mark and reputation as a positive changer. If I can get to them they will dictate to the slower middle managers to do things properly (like quantify their objectives to him).

3. Hopefully, if you are 'stuck' working with a certain company, you can find out what these managers claim they are interested in. If they are not interested in any improvement at all then we can stop wasting time with them. Their management needs to get rid of them! If they declare that they want some improvement (even though they don't really care to make the effort, or suffer the pain of change, but are just saying so to look better themselves) then we should try to help them.

4. We start by helping them define the measurable degree of improvement they want or need.

See: Vision Engineering http://www.gilb.com/tiki-download_file.php?fileId=237 />
Top Level Critical Objectives Cases http://www.gilb.com/tiki-download_file.php?fileId=180

5. Most managers, even smart experienced ones, cannot do this well on their own. Have never been trained to do so. Might need to be told by their boss that they have to quantify their objective. Might need some handholding and help to quantify their uppermost objectives.

6. Then these quantified objectives need to be approved by the powers that be, as the agenda for change that they are.

7. Then we can begin the process of finding strategic investments necessary to reach the objectives.

8. Then approving the finding and change process.

9. Then we can carry out the change, evolutionarily, and measure the improvement we are getting for money, and change strategies that are not working as expected to some that are working better.

10. If no responsible manager will engage in this and drive it, we are wasting our time, pearls before swine. But my experience is that there is often one ambitious manager or senior engineer who will welcome the opportunity, and welcome some help from us to make this happen. If there is not - don't waste your time. Let their world fall apart. Let them lose their jobs. Wait until someone is motivated to do things better.

11. "we can not afford it"

Is a challenging starting place. There are many things that can be done with minimum capital outlay, which quickly increase productivity and reduce costs, and have a great return on the little investment, in a short time. A classic Case Study of this is Raytheon.

Author of TR-017 sei 1995 and 1993 article Raytheon process improvement

www.sei.cmu.edu/publications/documents/95.reports/95.tr.017.html

I made some slides for this and a corresponding IBM Study see slides 6, and 7 onward in Inspection Facts for Managers slides http://www.gilb.com/tiki-download_file.php?fileId=88 />
Slide 18 reminds us that the return on investment was $7.70 per $1 invested at Raytheon and that productivity of 1,000 software engineers went up by 2.7 x (slide 13).

{SUBMIT()}{SUBMIT}

IS INSPECTION A COST EFFECTIVE WAY TO GET RELIABILITY IN SAFETY CRITICAL SYSTEMS?

Wed, 26 Nov 2008 13:12:06 +0000

Kai correctly suggested that this should have gone through the discussions, but done is done and I'd like to clarify a widely held misconception about inspections:

they are not about quality, they are about the reduced cost of getting the quality levels you have required.

If you want quality you have to design it in! You have to specify the quality levels you wants, and then architect, design, get evolutionary feedback and stop when you get to your target levels!

You cannot get 99.998% availability by testing or inspections!

On 18 Nov 2008, at 18:32, Thomas Auzinger wrote:

Some say that formal code inspections (i.e. team, Fagan) cannot be justified economically outside areas such as aerospace, defense, or any other area where a bug means catastrophic impact or loss of life.

What do you say?

On 11/18/08 8:43 AM, Thomas Auzinger added the following clarification:
I should have been more nuanced: formal inspections in teams with defined roles (producer, presenter, recorder ...) versus informal peer reviews of one person reviewing another's work in isolation.

On 26. nov.. 2008, at 02.07, Tom Gilb wrote:

Well I have a lot to say on that!

May I assume you have my Software Inspection book?

Cutter Journal paper 5 pg
http://www.gilb.com/tiki-download_file.php?fileId=64

INCOSE SQC
http://www.gilb.com/tiki-download_file.php?fileId=57

Agile SQC slides
http://www.gilb.com/tiki-download_file.php?fileId=239

Rule Based Inspections as printed in a Magazine
http://www.gilb.com/tiki-download_file.php?fileId=192

Agile Inspections keynote
http://www.gilb.com/tiki-download_file.php?fileId=239
Inspection Facts for Managers…
http://www.gilb.com/tiki-download_file.php?fileId=88

But let me answer directly and summarize (the basis is in the Inspection facts slides)

1. Inspection cannot prevent catastrophic bugs. They can just reduce the cost of getting to required reliability levels.
( see Capers Jones slides in the above where 10 test and Inspection processes still let 5% of the bug through!

2. The only way to get really high quality is by designing it in (architecture for product and process,
for example by designing redundant voting software systems (N-version programming, distinct software).
You do not get quality by testing it in or inspecting it in.

3. The economic problem with conventional inspection is that it is focussed on trying to clean up. The cost is too high and the effectiveness, at best, is not good enough!

4. One way to kill the high cost of inspections is to use my agile spec QC process, which focusses on sampling and measurement, and uses the defect density measurement to determine Exit of a spec or code from a process.

5. To your 'nuance': formal inspections are more effective than one person readings and reviews, provably so, but they are not effective enough to solve the problem of the last few bugs. They, for example, move the defect finding effectiveness from 10%-20% range to 60-80% range. Nice but not solving the essential problem.

Best Wishes
Tom

SECOND QUESTION: LATER SAME DAY
The simple answer to
"Sometimes the changes are only one or two lines. How do you sample them? "

is, you do not sample, you do a comprehensive inspection regarding all things potentially touched by the change
code
design, architecture
requirements
test scripts
user documentation
advertising
packaging
with the objective of making sure as possible there are no critical loose ends

of course full automatic regression testing too

Sampling is only interesting when there is a high volume of work to eyeball
{SUBMIT()}{SUBMIT}

Value Delivery Practices and Agile - copy of a comment made by Tom on Linkedin Rightshifting Group

Mon, 24 Nov 2008 14:21:41 +0000

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=990707&discussionID=558208&commentID=694408&goback=%2Eanh_990707#commentID_694408

tom gilb
Independent Computer Software Professional

ON VALUE DELIVERY - AND REQUIRED ADDITIONS TO AGILE PRACTICES

No doubt the intent of Product Owner/Customer specified Stories/Use Cases, and the numeric value and cost devices found in some Scrum practices, intend to deal with value.

Indeed: the Agile Mainfesto,
http://agilemanifesto.org/principles.html
has as the First Principle:
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.", and several other principles support this notion.

Great! So, the intent is there. What Ryan and I worry about is the practice!

We believe and observe that the real practice is normally very centered around delivery of functionality, of technical design. That there is NO up-front statement, and certainly not a quantified statement, about the the top few CENTRAL AND CRITICAL values that drive the project.

For example Productivity, Usability, Customer Responsiveness.

So there is no valid and validated (by sponsors and stakeholders) framework of objectives, to help us decide if the individual increments are really contributing to the primary objectives.

The notion of quantified, global, long-term value statements is completely absent from most agile practices (except Gilb Evo and arguably RUP if you can find the well hidden reference to it, perhaps DSDM, but certainly not Scrum and XP or Crystal (see Larman's comparative Study book)

What Ryan Shriver is arguing for, somewhat simplified, is a modified Scrum practice, where a quantified top ten critical improvement objectives (deliverable value increases defined) a la Evo method, is used to more consciously manage agile projects - to deliver the value primarily expected by primary stakeholders.

It is not quite that simple either. We both believe in a much better analysis of the multitude of real stakeholders (including internal stakeholders such as maintainers and testers) in order to ascertain their values. These values must form an integrated set of top level values, competing for limited resources.

We do not believe that the intuitive or pattern-driven re-factoring is a smart answer to the questions of maintainability. It resembles a 'patching' approach to quality. We believe quality is designed in not tested in. We believe that the value objectives for maintenance need to be stated up front as a primary value by the 'most costly lifetime stakeholders' (maintainers)
see

slides
http://www.gilb.com/tiki-download_file.php?fileId=171
Paper Maint
http://www.gilb.com/tiki-download_file.php?fileId=138

then architected into the initial design, and then worked towards incrementally and quantitatively, like the FIRM case study Green Week (one week a month).
value slide w… http://www.gilb.com/tiki-download_file.php?fileId=152
ppr wrong ag… http://www.gilb.com/tiki-download_file.php?fileId=50
Confirmit Ca… http://www.gilb.com/tiki-download_file.php?fileId=32

In other words, we believe in a systems engineering model, not a coding or programming model - is the right way to go - at least for projects that are large , complex and critical.

Building dog houses and summer cabins does not require engineering and architecture, and I am afraid that is the level of practice we see, and the level of theory we see for most Agile projects.

Some important projects require a more mature approach. And most smaller projects would benefit as well.

Tom Gilb
www.gilb.com
TomSGilb@ gmail.com
Norway 24 Nov 2008

the Group is
http://www.linkedin.com/groups?home=&gid=990707&trk=anet_ug_hm&goback=%2Eanh_990707

Inspection Self Audit Results

Mon, 10 Nov 2008 16:29:33 +0000

Today we usually offer a Agile Inspection process to our clients, but many organizations are still practicing Classic Gilb Inspections with great results. On this Web site, we have been hosting a little Self Audit of the maturity of your Inspection Process. So far we have 15 people who have taken the time to answer the questions on behalf of their organizations. Today I will share the results with you. Thank you to the people who did the self audit.

First a graph showing the total results for each submission. 100% = Top score on every question.

The average score is 50%, and the average time spent answering the audit questions was 6,8 min.

Then to the details about what level people rated themselves at for each question.

Question: Do you prohibit entry to the Inspection process when the source documents for the product to be Inspected have not exited a previous Inspection? If the answer is no, do you first carry out a mini-Inspection on those documents or at least on a sample of them? Do you prohibit Inspection if the source documents are not of adequate quality as a result of your mini Inspection or sample?
Votes Option Average
a. Never 5 33.33%
b. Sometimes 2 13.33%
c. Usually 3 20.00%
d. Always 5 33.33%

Question: Does your kickoff meeting set Inspection goals numerically, and establish corresponding strategies for reaching them?
Option Votes Average
a. Never 6 40.00%
b. Sometimes 1 6.67%
c. Usually 3 20.00%
d. Always 5 33.33%

Question: Are special roles assigned and defined in role checklists? Is there a library of such role checklists available for all Inspection leaders?
Option Votes Average
a. Never 3 20.00%
b. Sometimes 2 13.33%
c. Usually 2 13.33%
d. Always 8 53.33%

Question: Does the Inspection leader check that every issue logged has had some action taken by the editor?
Option Votes Average
a. Never 3 20.00%
b. Sometime 1 6.67%
c. Usually 4 26.67%
d. Always 7 46.67%

Question: Are the rates for both individual checking and the logging meeting updated, compared to the optimum rates, and used to plan the next Inspection cycle?
Option Votes Average
a. Never 7 46.67%
b. Sometimes 1 6.67%
c. Usually 4 26.67%
d. Always 3 20.00%

Question: Is an acceptable logging rate used as an exit criteria?
Option Votes Average
a. Never 10 66.67%
b. Sometimes 0 0%
c. Usually 3 20.00%
d. Always 2 13.33%

Question: Is the number of remaining defects after edit predicted? If this number is too high for the type of document, does the document fail to exit? In other words, is the estimated number of remaining defects an exit criteria?
Option Votes Average
a. Never 7 46.67%
b. Sometimes 0 0%
c. Usually 5 33.33%
d. Always 3 20.00%

Question: Is defect-finding effectiveness computed, based on test and field data?
Option Votes Average
a. Never 5 33.33%
b. Sometimes 1 6.67%
c. Usually 4 26.67%
d. Always 5 33.33%

Question: Is the current known effectiveness used to estimate defects remaining at the end of the Inspection cycle?
Option Votes Average
a. Never 9 60.00%
b. Sometimes 0 0%
c. Usually 3 20.00%
d. Always 3 20.00%

Question: Do you log substantial quantities of issues in your source documents? (for example, on average between 10% and 25% of reported issues resulting in change requests)
Option Votes Average
a. Never 4 26.67%
b. Sometimes 7 46.67%
c. Usually 1 6.67%
d. Always 3 20.00%

Question: Are Inspection leaders formally certified according to written criteria?
Option Votes Average
a. Never 4 26.67%
b. Sometimes 3 20.00%
c. Usually 3 20.00%
d. Always 5 33.33%

Question: Is there an up-to-date list of certified Inspection leaders?
Option Votes Average
a. Never 6 40.00%
b. Sometimes 2 13.33%
c. Usually 1 6.67%
d. Always 6 40.00%

Question: Are non-certified leaders prohibited from running software Inspections (unless under adequate supervision)?
Option Votes Average
a. Never 5 35.71%
b. Sometimes 3 21.43%
c. Usually 3 21.43%
d. Always 3 21.43%

Question: Are rules, procedures and checklists improved to some degree on a regular basis? (for example, weekly)
Option Votes Average
a. Never 1 6.67%
b. Sometimes 6 40.00%
c. Usually 4 26.67%
d. Always 4 26.67%

Question: Are the results of Inspection standards improvements shared among all Inspection leaders and Inspectors?
Option Votes Average
a. Never 5 33.33%
b. Sometimes 2 13.33%
c. Usually 3 20.00%
d. Always 5 33.33%

Question: Is there a library of Inspection material (for example, forms, checklists, rules) which is well-organized and known, and used by all Inspection leaders?
Option Votes Average
a. Never 2 13.33%
b. Sometimes 3 20.00%
c. Usually 2 13.33%
d. Always 8 53.33%

Question: Is a process brainstorming meeting held to analyze the root causes of defects found in the product Inspection?
Option Votes Average
a. Never 3 20.00%
b. Sometimes 5 33.33%
c. Usually 2 13.33%
d. Always 5 33.33%

Question: Are small scale local individual improvements implemented immediately?
Option Votes Average
a. Never 3 20.00%
b. Sometimes 5 33.33%
c. Usually 3 20.00%
d. Always 4 26.67%

Question: Are all improvement suggestions formally logged?
Option Votes Average
a. Never 1 6.67%
b. Sometimes 6 40.00%
c. Usually 1 6.67%
d. Always 7 46.67%

Question: Does someone, or some group of people (for example, the Process Change Management Team) follow up and implement process improvements using the Inspection database?
Option Votes Average
a. Never 1 6.67%
b. Sometimes 6 40.00%
c. Usually 3 20.00%
d. Always 5 33.33%

Kai
{SUBMIT()}{SUBMIT}

Project Failure Causes and Cures

Tue, 21 Oct 2008 22:14:53 +0000

My main concern these days is the high rate of project failure, partial and total.

My main conclusion as to why, is that we are not motivated to succeed, we IT people get so well paid for failure anyway. We are not focussed on delivering real value to stakeholders - and we are not rewarded for it.

One cure is 'No Cure No Pay Contracting' (in my opinion)
http://www.gilb.com/tiki-download_file.php?fileId=38
www.nasscom.org/download/Tom_Gilb-.ppt
http://www.gilb.com/tiki-download_file.php?fileId=85

The two most immediately critical technical project development processes, that seem to be at the root of failure in the projects we analyze are
1. the top level requirements (what are sponsors expecting for their money)
2. the delivery cycle and feedback and learning process.

The problem is:
1. The top ten most critical requirements are not quantified and not focussed on for the project
http://www.gilb.com/tiki-download_file.php?fileId=237 Vision Engineering Paper
http://www.gilb.com/tiki-download_file.php?fileId=180 Top Level Requirements Cases slides

2. The feedback from real delivery of value to stakeholders is too late , too infrequent and too badly utilized
http://www.gilb.com/tiki-download_file.php?fileId=30 Agile Now What, Kai
http://www.gilb.com/tiki-download_file.php?fileId=27 Kai Gilb Evo book

However most all IT projects seem to care little to do things 'properly'.

So the key change is going to be radically different motivation. This will not be provided by Agile, Lean, or conventional IT/Software forces (CMMI, TSP). They have shown this in practice for too long.

Leadership must come from top executives (by demanding as policy quantification of primary objectives, and early frequent delivery and analysis of feedback), and government institutions (for example by going to No Cure no Pay contracting).

I am just amazed how pervasively 'stupid' we as a culture continue to be! And how little we seem to care?

Do we have to get totally bankrupted as the financial industry has just been, to wake up? I fear we do.

If there are any powerful people out there who at least want to change their own Corporation or Organization - read the above sources and count me in as an ally if that helps.

There have got to some exceptions to this 'Rule of IT Insantity'

Tom

{SUBMIT()}{SUBMIT}

Software & Systems Quality Conference United Kingdom 2008

Fri, 12 Sep 2008 22:28:53 +0000

We are attending and presenting at the; Software & Systems Quality Conference - United Kingdom - 2008 that runs from 29th of September to 1st of October.

Web site: http://www.sqs-conferences.com/uk/index.htm
The main site where you will find an overview of the whole program etc.

http://www.sqs-conferences.com/uk/program/day2.html
30th sep. 4.15 - 4.55
Management: Optimising Testing
Testable Requirements: What are the Standards we need to adopt to make sure Requirements are Testable?
by Tom Gilb

http://www.sqs-conferences.com/uk/tutorials/t6.htm
1st of October 09:00 17:00 Track 6
Agile Testing: Improving Productivity
by Tom & Kai Gilb

You can get a 10% discount by contacting Julie Wells Julie.Wells (at) sqs-uk.com Tel: 0207 448 4624 Mob: 07769 882211 and mentioning that you got this information from Tom & Kai Gilb

We hope to see you there!

Tom & Kai Gilb

From Sony, HitachiSoft & JUSE in Japan

Fri, 05 Sep 2008 14:28:07 +0000

Sony in Tokyo

))HitachiSoft(( in Tokyo

Union of Japanese Scientists & Engineers (JUSE)

{SUBMIT()}{SUBMIT}

Website url change & Registration Issues NOW FIXED!

Sun, 17 Aug 2008 17:37:56 +0000

Update:

OK, the tikiwiki that this website is running on, is now successfully upgraded. (no more registration issues)

There are numerous improvements, but I like to point out one. On many places, as a logged in user, you can now tag content using the Folksonomy box located at the top right of this website. And we can all search using the tags.

In addition to the upgrade, I have moved the website away from the /community/ sub domain, so if you have pages bookmarked, they need to be changed

from: www.gilb.com/community/...
to: www.gilb.com/...

and the url that is generated from clicking on the menu items on the left side, are much more human friendly.

Kai

What is Productivity?

Wed, 06 Aug 2008 17:10:10 +0000

Productivity: Concept *659. August 6 2008 (New)
Productivity is delivering promised value to stakeholders.

‘Deliver’ means actually measurable handed over and available to stakeholders.

‘Promised’ means that clear written agreements, are made in contacts, requirements, documents and slides, or clear undeniable expectations are set.

‘Value’ means something of perceived use, to the stakeholder; they need it, they want it, they are willing to sacrifice resources to get it, they will be unhappy if it is late or lower in power than their expectations.

‘Benefits’ are the results of the perceived value to stakeholders. Benefits are what really happens, though time, as a result of the engineering value delivered.
It is an open question whether systems engineering should attempt to take some planning responsibility for enhancing benefits realization, or whether this is the system recipient stakeholders that should be responsible for planning an environment to maximize benefits. Someone has to take this responsibility, and I fear that the system users with their ‘day jobs’, do not feel they are responsible or capable. In which case an opportunity for systems engineers, to enlarge their conventional scope of planning, exists.

So, we can simplify and say ‘engineering productivity’ is the ability to deliver agreed requirements.

{SUBMITBLOG()}{SUBMITBLOG}

Advanced Practical Skills for Project Management. Public Course Workshop in Oslo

Sat, 02 Aug 2008 13:32:40 +0000

Vi gleder oss over å kunne tilby, i samarbeid med Nordnet, et prosjektstyrings seminar i Oslo 17. September 2008.

Advanced Practical Skills for Project Management
How to Quantify Top Level Project Objectives, and How to Decompose Projects into Very Small Value Delivery Increments

For mer informasjon, se: Prosjektledelse med Verdiskaping http://www.nordnet2008.no/gilb/index.htm
og http://www.bekk.no/aktuelt/nyheter/Spennende-Evo-kurs-med-Tom-og-Kai-Gilb/

{SUBMITBLOG()}{SUBMITBLOG}

Gilb's - Risk & Uncertainty conference

Thu, 26 Jun 2008 12:22:40 +0000

The Gilb London course is growing year by year.
This year the theme is Risk & Uncertainty, and experts from all around the world is presenting and participating (very lively).

Speaker List
^Bran Selic - Malina Software Corp - Canada
Risk Factors in Model-Based Software Engineering

Matthew Leitch - MLA - UK
Progressive risk and performance management with mental models

Don Mills - e-testing consultancy - UK
Risk, Testing, and AS/NZS 4360

Manfred Bundschuh - University of Applied Sciences, Cologne - Germany
Risk reduction

David Gelperin - ))ClearSpecs(( Enterprises - USA
Recognizing & Controlling Reqts Risk

Rolf Goetz - Deutsche Post AG - Germany
Risk Experiment
Heaps of Risk

Clifford Shelley - Oxford Software Engineering - UK
Imagining Managing Risk

Niels Malotaux - N R Malotaux - Consultancy - Netherlands
Controlling Project Risk by Design

Kai Gilb
Risk & Uncertainty techniques in Evo Project Management

Tom Gilb
A Major Case of IT Project Failure

Risk Principles

Design Maintainabilty in

Lorne Mitchell - IBM - UK
May you live in uncertain times

Jens Egil Evensen - Avenir - Norway
Some stories about Evo and Agile

Andre Klingsheim - ))NoWires(( Group - Norway
Security Risk Management part 1

Lars-Helge Netland - ))NoWires(( Group - Norway
Security Risk Management part 2

Ryan Shriver - Dominion Digital - USA
Agile Engineering

Russ Vane - IBM Global Business Services - USA
Bounding Risk

Matthew Leitch - MLA - UK
Finishing my talk

Chris Dale - Business Transition Technologies Ltd - UK

David Stoughton - Value Kinetics - UK
Something about Risk

Philip John - Cranfield University - UK

Eckhard Jokisch - Orange-Moon produktions GmbH - Germany
Triangle of communication, trust and risk

Allan Kelly - Software Strategy - UK

Manfred Bundschuh - Germany
Awareness for software measurement

Renze Zijlstra - KZA - Netherlands
Stear clear of cliffs

Lisa Liu - Glasgow Caledonian University - UK

Margaret Fordyce - Pilat Media - UK & NZ
Case study

NV Krishna - Microsense Software Pvt Ltd - India
Ideas from the Thar Desert

Lech Krzanic - Finland^

{SUBMITBLOG()}{SUBMITBLOG}

Using Evo with Scrum

Mon, 09 Jun 2008 18:34:13 +0000

From Agile Thinkers

One interview with Ryan Shriver of dominion digital and
one interview with Jens Egil Evensen of Avenir
sharing their experiences of using Evo methods!

What might interest some of you is that they both are Scrum Masters, adding Evo to Scrum to get better customer and stakeholder orientation and value delivery. Both of them are Champions of Evo, working within consultancy organizations.

{SUBMITBLOG()}{SUBMITBLOG}

The power of clearly articulated end states, and the “law of attraction"

Tue, 13 May 2008 10:06:52 +0000

Many people worldwide have watched the film “The Secret”. It highlights the “law of attraction” and how powerful and essential it is to personal achievements. It teaches how essential it is to set clear end state goals, and how, just by setting them, and having them clear in your mind, they will manifest through the “law of attraction”.

From their Web site: www.thesecret.tv “The Secret reveals the most powerful law in the universe. The knowledge of this law has run like a golden thread through the lives and the teachings of all the prophets, seers, sages and saviors in the world's history, and through the lives of all truly great men and women. All that they have ever accomplished or attained has been done in full accordance with this most powerful law.”

The film runs like a US infomercial, I had to laugh at times at how it was presented and the values they represented, nevertheless, I think there is much truth in the core message. The film is pitched to individuals, and how they can use the “law of attraction”. I am, though with a very different style, pitching the same message to corporations for project management and development.

With clear visions of what the end states of a project is, “the law of attraction” will greatly support your accomplishment of those end states. With one person having a clear vision of what they want, the “law of attraction” is powerful. When everyone on your project shares a unified clear vision of the projects end states, the totality becomes extremely powerful. Everyone’s energy and efforts will pull, push and cheer the project in the direction of the end states.

The most powerful method you can learn in project management is being able to envision, state and share, the Stakeholder Values and or Product Qualities, the success criteria’s void of solutions, in clear meaningful quantified ways.

Kai

{SUBMITBLOG()}{SUBMITBLOG}

New Offering, Focused Knowledge Transfer Workshops

Tue, 06 May 2008 14:52:03 +0000

Short of time, want to get right to it. We have designed some workshops just for you and your group. An excellent alternative if you want Tom and me to visit your organization for a day or less. Check them out at Knowledge Transfer

Kai

Add your comment, must be logged in.

{SUBMITBLOG()}{SUBMITBLOG}

Tom Answers Interview Questions from www.agilethinkers.com

Mon, 05 May 2008 21:50:36 +0000

Here's my first few questions to you:

Q1: Hi Tom. I started University in 1988 ... which is the same year that your classic book "Prinicples of Software Engineering Management" was published. According to my calculations that means your book has now been around for 20 years. I only came across it a few years ago but it has influenced my thinking more than any other "software development" book. I know of several of the better known Agile guru's who say similiar things. Can you tell us a little (or a lot) about what lead you to write the book and where your ideas came from?

Yes PoSEM is now in 20th Printing - I was asked by my publisher to make an 'evergreen' - and apparently it is!

I like to think my 2005 book, Competitive Engineering (CE), is a worthy successor. It treats the same subjects, but more deeply. It is not such an easy read, but we have other books to serve that purpose including Kai Gilb' s "Evo" book http://www.gilb.com/tiki-download_file.php?fileId=27

It was important to me that the CE, which officially defines Planguage, was reasonably rigorous. Time will tell, but it is in Second Printing and is well reviewed, so there is hope for the future!

What led me to write the book?
Well, let me remind you of the book's predecessors:
1976 Software Metrics (coining the term, and the official foundation for IBMs CMM Level 4 (I don't take all blame for CMM!). In USA 1977.))
1974-5 Reliable EDP Application Design, and Data Engineering (neither in USA, but both in Sweden and UK).
These were the real beginnings - PoSEM was second generation!

You might say the centre of my technical universe is 'quality quantification'.
The driver there is - the Lord.

OK! Lord ..... Kelvin.

About 1965 the following appeared in a Norwegian newspaper: (I joined IBM Norway 1958, at 17)
"I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it;
but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind;..."
http://zapatopi.net/kelvin/quotes.html,

That got me thinking about whether we could quantify critical quality properties like portability and security. I had no internet to search, and my international personal network from conferences was a good Who's Who (Dijkstra, Langefors, Naur, Nygård, Dahl) - so I tried common sense and invented and published some ideas on how to quantify them. I also quickly found out that they worked in practice.

As I worked as a consultant, I got challenged with extending the vocabulary, for example extensive work with ICL UK in the early 1980's led to defining Adaptability, and from 1980 with IBM led to defining Usability. As late at 1995 at Ericsson (Erieye airplane) we extended Usability with Intuitiveness and Intelligibility. And these and others became stable, and became patterns for tailoring local variations. More recently my friend Lawrence Day of Boeing pointed out to me that my method is in the Bible, 1st Corinthians, defining Love by decomposition into several quantifiable factors ('endureth long'). And I realized that Rene Descartes was on to 'my' method centuries ago.

Another early inspiration was a UK Professor Christopher Strachey, Oxford University Computing Labs, in the 1969 NATO Science Council "Software Engineering Techniques" Proceedings page 65) http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF
Christopher Strachey (Oxford) : “Computing science has been under some attack on the grounds that it isn’t software engineering. I propose to attack it on different grounds. I think we should seriously ask ourselves the question: is computing science?

Recently I did a small survey as to whether computing is suitable as an undergraduate subject in an English university. I did this by grading all the topics I could think of under the headings of relevance and state of development. The premise is that it is clearly wrong to teach undergraduates the state of the art; one should teach them things which will still be valid in 20 years time: the fundamental concepts and underlying principles. Anything else is dishonest.

The gradings for relevance ran from “clearly relevant and essential” to “part of another subject” (like numerical analysis) and those for state of development from “well developed with theorems, laws and text books” to “a fruitful field for research”. Note, incidentally, the importance of text books. They are designed to be taught from; they are quite different from treatises and even further from research papers. Now, it turned out that all those subjects which score highly for relevance score very low on state of development and vice versa.

Until we have a sufficient body of topics which are important, relevant and well developed we cannot call the subject a “science”. I am quite convinced that in fact computing will become a very important science. But at the moment we are in a very primitive state of development; we don’t know the basic principles yet and we

must learn them first. If universities spend their time teaching the state of the art, they will not discover these principles and that, surely, is what academics should be doing.

I do not for a moment underestimate the importance of the state of the art in engineering. Clearly it is essential and furthermore from engineering practice we must get our experience and material from which we develop theory. But, before teaching students we must get our basic principles right." (Strachey 1969)

Well, I found he was right. There were not many principles published or available (Langefors (Theoretical Analysis of Information Systems) and Naur had a handful).

So, I drafted a number of principles, based on my 'engineering experience'. About 124 principles were published in PoSEM (1988) and at least 100 Principles in CE (2005).

I like to think they "still be valid in 20 years time". In fact we can now test the 1988 Principles - would anyone like to argue they are not valid today?

My own arguments for subjects that will "still be valid in 20 years time". is in my paper Undergraduate basics
http://www.gilb.com/tiki-download_file.php?fileId=98

The paper argues that principles, concepts and measures are primary tools to learn about.

A few academics have understood this, but not many, as far as I can see. I also see the consequent helplessness and waste in software projects that seem to me to be the consequence of the lack of fundamentals. We cannot seem to get decent quantified requirements at the top level for large projects - ever. We never seem to get past step One.

Q2: How did your life change after you published the "Principles" book?

Not much. My working life has been similar for almost 50 years, teaching, lecturing, consulting, writing, reading, networking, inventing, travelling - running my own company. So much fun - who would want to change it!

Q3. Can you tell us a little about your personal life?

Yes.

Ohhh you mean will I detail it here now?

Well I can tell you it has been fun - and to protect innocent people I can't tell you all the details!

The essence starts when I was 17 and met this wonderful Norwegian girl of 18 in London. She is sitting next to me in my living room as I write this. True Love = Endureth Long! (Corinthians 1 again). I was in my first year of 6th Form (boring). So of course I got engaged, moved to Norway and got a job at IBM just by asking! All really great decisions.
I mean who knew that Norway was going to be the richest country with the best quality of life in the world?

I continued my studies at University of Oslo for about 10 years, on the side of full time job, and a family from 1964. Sociology, Economics, Political Science, Philosophy. What fun - and I did it for fun, not for a job. Yes it is all useful for me today. I realized that I would not be a good bureaucrat at a University - and also realized that 95% of University people dislike me or my ideas. That is probably a good sign. The key is who the other 5% who do!

Thank goodness I never had to do a Thesis approved by the 95% who dislike my ideas! So I decided my books would be my 'Thesis". My ideas are evaluated by the readers - and I have full respect for that - even from those who feel they do not like my ideas. At least they had a look at them!

We have 4 boys and 5 grandchildren. We live just outside Oslo in a new apartment, half hour away is our amazing beach-front cabin on the Oslo fjord, and we have a "town cabin" in Covent Garden - which is useful as we love to go out in London, and visit my London Family.

In January 2008 the Norwegian Government decided to pay me a nice sum (which I have apparently been forced to save for 50 working years) every month for the rest of my life. I still continue working with my son Kai - but I am even less focussed on earning money, and more focussed on fun, travel for me and my wife, playing grandfather, and writing creating and spreading the word. I like the model of my friend W. Edwards Deming (Statistical Process Control) who held his last lecture at 93. I like to tease my listeners that I will teach their grandchildren when they are retired.

I enjoy perfect health, which I know is a gift at my age. No, I never smoked.

I am Norwegian Chairman of the Board for The Art of Living Norway (artofliving.org) which has made available to me a lot of wisdom, and contact with a younger generation.
I think I believe, but cannot measure or prove, that we had past lives and will have future lives. This explains some things to me - but I might be wrong - so I am doing the best I can in this life. If I can get back to you afterwards and confirm my hypothesis, I will. Watch this website. Failing that I hope we can discuss this 'afterwards'.

One consequence of this hypothesis is that maybe my ideas are not as 'original' as I might like to believe: maybe I either 'remember' ideas, or are fed them by spirit guides? A least I get to keep the income and royalties. And spirits don't sue for plagiarism! Hey with a bit of luck I will either remember, or find an old copy of, my books, when I am young in my next life, and can follow Newton's idea of standing on the shoulders of giants. Well, even if I can't - you can!

My philosophy, from 17 years old: do what you love, do it well, don't let money dictate what you do - you will survive.

Q4. I first met you at XPDay2004. You were one of the keynote speakers. I loved your talk because it resonated with my own concerns about "Agile". Can you elaborate on those concerns? Do you still have them?

You bet!
For readers who were not there, the slides are at
Paper: http://www.gilb.com/tiki-download_file.php?fileId=50
Slides http://www.gilb.com/tiki-download_file.php?fileId=170

The good news is that some people who have practiced Agile thoroughly, now see my point - and realize that if we are to deliver value to our customers, we need to add to the conventional Agile vocabulary. We need to be far more explicit about what value improvements our stakeholder need, and how we are going to deliver them.

'Stories' and 'Use Cases', Features and Functions - are nowhere near what we need to deal with. Quantification of Values (Qualities) is essential. The Agile boys got the message about small iterations OK, but they completely ignored the message about quantified quality requirements. I put that down to immaturity. We are all immature at some stage. It has to be put right in time. Rapid delivery of the wrong values is still wrong.

A great example of a Scrum Master who 'gets it' is a friend I met at the Agile Business Conference in London, Ryan Shriver:
Ryan's home page www.dominiondigital.com
Slides… http://www.gilb.com/tiki-download_file.php?fileId=148
Goalkeeper Tool http://goalkeeper.dominiondigital.com

I have a very simple message to all those failed projects for which we are so famous, and will be more infamous:

1. Quantify the critical stakeholder values (current Agile culture does not understand 4 of 5 of those words)
2. deliver those values early and frequently. (delivering value to stakeholders is NOT the same as delivering code or a story)

The survivors will get it

My favourite theory of how to change our world: "no cure no pay"
No Cure Paper http://www.gilb.com/tiki-download_file.php?fileId=38

Slides No Cure http://www.gilb.com/tiki-download_file.php?fileId=85

I cannot believe there are so many managers, 99.999% of them, who prefer to pay for effort and failed results, when common sense says they should only pay for good results.
People called 'programmers' sometimes crowning themselves 'software engineers' , have learned to fleece these rich managers thoroughly. A fool and their money will soon be parted. Hang in there guys, it may soon be illegal!

Well, I'd better quit before I insult too many people, after all they have a right to use their company's money any way they want to?

Warm Wishes to You All

Tom

Add your comment must be logged in.

{SUBMITBLOG()}{SUBMITBLOG}

Agile Research at PHD Level

Fri, 02 May 2008 19:58:14 +0000

http://www.gilb.com/tiki-download_file.php?fileId=183

Is David Rico's
EFFECTS OF AGILE METHODS ON WEBSITE QUALITY FOR ELECTRONIC COMMERCE

and http://www.gilb.com/tiki-download_file.php?fileId=182

has MAPPING AGILE PROJECT MANAGEMENT PRACTICES TO PROJECT
MANAGEMENT CHALLENGES IN SOFTWARE DEVELOPMENT
by Saya Poyu Sone

If you want some serious insights into the much hyped area of Agile - download these and spread them!

Tom

{SUBMITBLOG()}{SUBMITBLOG}

System Engineering Requirements: for software and hardware Engineers

Wed, 23 Apr 2008 21:46:07 +0000

On Behalf of a long time Mulit-national Client, we have been rethinking our syllabus for teaching requirements. It will come as no surprise to those who know us well. But I thought I would share it.

If you have any suggestions, questions, or would like the links to our requirements writings, let me know.] by Email: tom at gilb dot com.
You are welcome to steal the ideas for your own use! (Just credit sources as we would).

System Engineering Requirements: for software and hardware Engineers

Intended for : In House or Public Use
o Version: 23 April 2008
o Responsible Editor: tom at gilb dot com
o

Duration: 2 to 5 days depending on depth and capability required

Prerequisite Course:

Next level Advanced Course: Quantifying Quality Master Class (Gilb)

Intent: to give specific best practices for requirements gathering, analysis specification, quality control and evolution.
• The emphasis will be on:
o Giving specific tools (templates, rules, procedures)
o Motivating to do requirements the right way
o Clearly spelling out bad practices
o Practical ability to go back to work and make much better requirements.

Note: our domain initially is software, but the course is suitable for any class of systems engineer. In the longer term we should have same language, same process for any of our product/system and service requirements.

Class Mode: lectures, with frequent exercises, Q&A, and Exam.

Assumptions About Participant needs: They need:
• To get one recommended set of practical practices that will help them to write good and clear requirements.
• To get requirement practices that are suitable for the size, complexity, life cycle length, and customer base that our corporation deals with normally.

Syllabus:
• What exactly is a ‘requirement’?
o ‘Stakeholder-desired future state’
• What, by comparison, is a ‘design’ or ‘solution?
• Stakeholders: why are they essential to requirements?
• The distinction between stakeholder values and needs, and product or service requirements.
• Translating stakeholder needs into suitable requirements.
• Relating requirements to needs, using Impact Tables.
• Analyzing stakeholder needs and inputs: how to determine their real needs.
• Analyzing so called requirements, and classifying them into useful categories.
• Generic Rules for Requirement Specification
o Dealing with ambiguity, clarity, uncertainty.
• Specification of Function Requirements (templates, rules)
o Let us agree on the meaning of a ‘Function”’!
• Specification of Performance Requirements (templates, rules)
o Quantification of Quality Requirements (Scale)
• Constraints: specification of fixed and scalar constraints (templates, rules)
• Quality Control of Requirements: Rules, Defects. Exit Levels.
• Evolutionary Requirements:
o Refining requirements based on feedback from deliveries
o Top Level Control of using critical few requirements
• Prioritizing Requirements
o Priority Concepts:
• Constraints
• Targets
• Conditions
• Degree of Fulfillment
• Other priority Factors.
• Basic Principles of Requirements.
o General Requirement Principles
o Performance Requirement Principles.
• Case Studies of real and well-written requirements.
• Understanding related disciplines
o Use Cases
o User Stories
o Features
o Design that is really requirements.
• How to measure the value/effects and costs of requirements methods.
• Requirement Policy
• Steps to Change your requirements culture.
• Next Related Steps: Design, Project Management, Quality Assurance.
• OPTIONS
o Final Exam: 1 Hour.
o Diploma Work: after the course, participants will submit one day’s work or about 5 pages of requirement they have written to the new standards, for approval as a reasonable proof of learning.
o Course Diploma will be awarded based on:
• Attendance, exam, practical submission afterwards ‘Diploma Work’, course feedback handed in

Resulting Participant Capability: participants will be able to apply official corporate standards for requirements specification.

{SUBMITBLOG()}{SUBMITBLOG}

Master Class in Quantifying Quality:

Wed, 23 Apr 2008 15:34:30 +0000

A client of ours asked us to develop a Master Class in our specialty - Quality Quantification.
You might be interested in seeing our ideas of how to teach this subject in more depth than we can usually cover in more general elctures and more general requirements classes.

Duration: 3 days : 9-5 or more

Participants: any engineers or managers who want to master the art of quantifying and product, service or organizational quality aspect, for purposes of planning, setting requirements or objectives.

Outcome: Participants should be reasonably well qualified to teach, consult, and do – the quantification of any critical systems performance characteristics – particularly Quality (‘How Well’ the system performs).

Training Method:
• Lectures: probably less than 1 hour per day
• Practical Exercises on real corporate projects. Most of Day
• Exam: 1 hour at end.
•
What We Need To Teach (Subject Matter): The Quantification Body of Knowledge
• How to analyze any incoming stream of needs, wishes, requirements, objectives – however vague and unstructured
• How and why to classify incoming wishes
• Levels of Perception: Stakeholder level, System/Product level
• Identification of the top level
• Prioritization: aspects and process
• The Quantification Process
• Quantification Specification Rules (Standards for written specification): best Practices for specification
• Quality Control of Written Specification: Measuring levels of defects
• The use of ‘Ambition Level’ to scope and initiate the process of quantification
• Resolving Conflicting Opinions: The Ambiguity Test
• Knowing When a Quality should be decomposed into sub-qualities. Complex and Elementary Qualities
• Quality Patterns
• Tailoring the Patterns
• The Scale of measure: Basics
• Scale Parameters: making a general and reusable scale.
• Cross referencing initial inputs to the quantification process
• Getting stakeholders to understand and agree to quantifications
• Templates for specification
• Benchmarks: Past, Trend, Record, Ideal
• Qualifiers: when, where, If? Conditions for a level of quality
• Constraints: Fail /Tolerable Border, Catastrophe Border
• Targets: Wish, Goal, Stretch
• Meters and Tests: measuring the levels of Quality
• What are ‘good’ scales of measure?
•
• === Advanced overview Subjects (if time)======
• The use of Impact Estimation Tables for multiple qualities evaluation
• Specification of Designs, including quantified impact on qualities
• The role of Evolutionary project feedback in tuning quality understanding
• The Planning Language Framework: the larger picture
• Top Management Objectives level: a good place to start quantifying
• How to motivate change towards serious acceptance of quantified qualities
• The relationship between quantified qualities and costs
• A Policy Framework for Quality Quantification.
•

What Participants need To learn: (Ability):
• How to accept almost any stream of ideas from domain experts regarding their requirements, and analyze constructively
• How to specify quality requirements unambiguously for serious projects engineering purposes.
• How to dialogue with requirement stakeholders to the information needed and to get their understanding, acceptance and cooperation
• How to express any interesting system, service or product quality using numbers.
• How to teach others to quantify any quality

The Examination: (with textbooks and internet)
• 30 minutes: quiz on basic facts
• 30 minutes (or more) solve specific problems of quantification.
•
Class Environment:
• Individuals or teams (Project Groups) May Attend
• All participants will be expected to either
o Bring with them real projects documentation to work from
o Or join a team with such real project documentation
• The instructors will assign a series of problems based on the documentation, to be solved by small teams
• The instructors will discuss, evaluated work in progress , give feedback and guide the teams.
• The end result we will be working towards is
o that each individual will feel confident that they can help any domain expert to clearly articulate their most critical qualitative system improvement.
o That the individual will know what written tools they can access to solve problems
o The individual will be able immediately to consult and teach with others to quantify

On Request we can send you the links to the slides, books and papers on this subject - but they are already at this site in various places.

{SUBMITBLOG()}{SUBMITBLOG}