Tom and Kai Gilb blog

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 +0100

Part 0 of 7 Introduction
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity

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

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 +0100

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 +0100

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 +0100

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 ...

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

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 +0100

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 +0100

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, , 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 +0100

Part 0 of 7 Introduction
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity

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

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 +0100

Part 0 of 7 Introduction
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity

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

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

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

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 +0100

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 +0100

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 +0100

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

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

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

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

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 +0100

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 +0100

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 +0100

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 +0100

"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 +0100

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 +0100

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 +0100

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 +0100

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 +0100

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

The Value of Using Numbers in Requirements

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

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 +0100

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 +0100

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.

©

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 +0100

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).

Share this page:

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

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

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

Share this page:

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

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

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 +0100

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

Share this page:

Project Failure Causes and Cures

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

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 :)

Share this page:

Software & Systems Quality Conference United Kingdom 2008

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

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 +0100

Sony in Tokyo

HitachiSoft in Tokyo

Union of Japanese Scientists & Engineers (JUSE)

Share this page:

Website url change & Registration Issues NOW FIXED!

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

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 +0100

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.

Share this blog:

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

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

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/

Share this blog:

Gilb's - Risk & Uncertainty conference

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

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

Share this blog:

Using Evo with Scrum

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

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.

Share this blog:

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

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

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

Share this blog:

New Offering, Focused Knowledge Transfer Workshops

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

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.

Share this blog:

Tom Answers Interview Questions from www.agilethinkers.com

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

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.

Share this blog:

Agile Research at PHD Level

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

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

Share this blog:

System Engineering Requirements: for software and hardware Engineers

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

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.

Share this blog:

Master Class in Quantifying Quality:

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

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.

Share this blog:

London Gilbs Seminars May and June

Sat, 19 Apr 2008 14:31:58 +0100

Below is information about 6 days of 1 day seminars in London:

In addition we have our usual invitation only annual seminar last week June - this time on Risk. We already have a great set of contributors coming - but room for interesting experts - talk to Tom if you are one or know one.

The seminar overviews have been uploaded to the following page on TSG’s website:

· http://www.testing-solutions.com/index.php?cid=173

The page can be referenced directly from the homepage, which is to be changed substantially over the next week to reflect your material and activities and references I think relevant.

Kind regards
Bernard Melson
Chief Operating Officer
Testing Solutions Group

St. Mary's Court
20, St. Mary at Hill
London EC3R 8EE

Mob: +44 (0) 7771 635735
Off: +44 (0) 20 7469 1500
Fax: +44 (0) 20 7623 8459

Share this blog:

Registration process now fixed

Sat, 29 Mar 2008 20:17:05 +0100

Those of you who have tried to Register to Gilb.com in the last few weeks will have found that process to be broken. It is now fixed. Thank you David http://www.davidpratten.com for the heads up and help with the fix.

I am on a 10 day windsurfing vacation in Hawaii practicing old skills;-)

Share this blog:

Thu, 13 Mar 2008 16:21:12 +0100

http://www.testingexperience.com/testingexperience01_08.pdf

Just published Testing Experience, with my Quality Manifesto paper, and many good papers by my friends!

Tom
On route to Seattle and San Diego (17-19 March) 08

Share this blog:

Expanding and Clarifying the "Benchmark" concept. Glossary Edit.

Wed, 23 Jan 2008 16:11:57 +0100

Benchmark Concept *007 January 23rd 2008

A benchmark is a specified reference point, or baseline. There are two main types: scalar and binary benchmarks.

Notes:
1. A scalar benchmark is a reference level for a performance or resource attribute. It is usually used for comparison purposes in Requirement specification, design and implementation.

2. A scalar benchmark is normally defined using the benchmark parameters {Past, Record, Trend}.

3. It is arguable that the concepts Ideal, Perfect and Wish are also reference benchmarks, rather than actually required states. The Wish is a Stakeholder need, but not a formal system requirement. Perfect and Ideal are two classes of extreme states, not likely to be seriously affordable, feasible or prioritized into constraints or targets. If they are in any case really ‘required’ we would need to state them as targets or constraints (added Jan 23 08 tg)

Example:

Usability:
Ambition: Order of magnitude better than future competitors.
Scale: Average time needed to learn to do Typical Tasks for Typical User.
Perfect: 0 seconds.
Estimate [This Year, Our Old Product] 10 minutes.

4. Function and design attributes are specified as binary benchmarks: binary attributes are either present or absent in a system.

Related Concepts [Benchmark *007]:
• Baseline *351
• Past *106
• Record *127
• Trend *155
• Estimate *058
• Perfect *648
• Ideal *328
• Wish *244

Type [Benchmark *007]: Specification Type.

====

The full Updated Concept Glossary 23 Jan 08 is on this site at

Glossary

and a fairly new paper explaining the Glossary concepts is at
Paper 2006 I… http://www.gilb.com/tiki-download_file.php?fileId=46

Share this blog:

I have rethought the concept of a requirement target, and excluded Wish.

Wed, 23 Jan 2008 15:52:05 +0100

Target Concept *048 January 23 2008
Targets are a class of Requirements that we seriously plan to reach. They contrast to Constraints that we seek to avoid; and Benchmark Levels which are merely analytical information, without formal commitment to reach them..

Notes:
1. NOT CONSTRAINT. A target is not a constraint. Targets specify the success levels for scalar Requirements, and any stakeholder-desired binary requirements.
Constraints by contrast specify any failure and/or survival levels for scalar Requirements, and any mandatory Requirements for binary requirements.

2. Function TARGETS. Function targets, or ‘valued functions’, are subtly different from Function constraints. Function constraints are mandatory. If a Function constraint is not met then some degree of failure will occur, or even total system catastrophe. Function targets do not have implied penalties – but can have specified ones (‘Rationale’ and other attached specs): nevertheless, they are considered required by some stakeholder.
3. CONTENT. A scalar target specification consists of a numeric value (its target level) and its relevant qualifiers and a priority-level classification of Goal, Budget, or Stretch.
Wish, Ideal, and Perfect scalar levels are initial reference points, and are classified as Benchmarks. They are not targets, unless the levels they refer to are also formally acknowledged as such, by being specified as Goal, Stretch, or Budget.
4.COLLECTIVE USE. Target can also be used as a collective noun, applied to a set of Function targets and variable scalar targets with their individual qualified levels.
5. AIM NOT AVOID. A target is distinguished from constraints in that we are aiming to reach, at least to, the target levels, or to deliver the Function target; while scalar constraints are Requirements levels we want to avoid. Function targets are functions we want to deliver, while ‘function constraints’ are functions we want to avoid.

6. PRIORITY: Target level Requirement specifications can be expressed by the parameters Goal/Budget and Stretch. Each one of these indicates a different level of commitment and priority. Benchmark levels (Past, Record, Trend, Ideal, Perfect) can be thought of as indicating a weaker level of Stakeholder interest or value, if any. Constraint levels (Fail, Catastrophe) are a stronger level of priority than Target levels.

7. SPECIFICATION ACTIVATION. Target specifications can become committed Requirements (become ‘prioritized’, or ‘activated’),
• when their qualified conditions are true, (especially in the case of Goal) and
• when it is economically and technically possible (in the case of Stretch)
• when other higher priority targets are fulfilled, and there is still resource available to meet them (this applies to Stretch and Wish, as well as lower priority Goal requirements).

8. There are two kinds of target: ‘scalar’ and ‘binary’.
9. Scalar targets can be expressed using the parameters {Goal, Budget, Stretch}.
10. Binary targets are Function targets.
Related Concepts Target *048: • Goal *439: a performance target • Budget *421: a resource target
• Benchmark *007 updated Jan 23 08
• Constraint *218
• Function Target *420
• Function Constraint *469
• Scalar Target *470
• Stretch *404
• Wish *244
• Requirement *026

Keyed Icon Target *048: @

Figure *048 Scalar targets can be specified for both performance and resource requirements. (new diagram Jan 23 08)

Type Target *048: Requirement Level Specification Type.
=======

The full Updated Concept Glossary 23 Jan 08 is on this site at

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

and a fairly new paper explaining the Glossary concepts is at
Paper 2006 I… http://www.gilb.com/tiki-download_file.php?fileId=46

Share this blog:

Modeling Modeling

Sun, 06 Jan 2008 03:58:14 +0100

MODELING MODELING REALISTICALLY ENOUGH FOR SERIOUS PURPOSES

by
Version January 6 2008

I was asked to comment in more depth on my disquiet about the Model description used by Grady/Green and attributed to Selic. See Jan 5 blog below for more general comment.
This is my off the cuff 'blog'.
Substantial depth behind these details will be found in my book "Competitive Engineering" 2005.

"This paper uses models to describe architecture description frameworks so those two words must
be clearly understood as a prerequisite. Bran Selic, a respected name in modeling work,
described a model by listing its characteristics as follows:
a. The use of abstraction to emphasize important aspects while removing irrelevant ones.
b. Expressed in a form that is really understandable by observers.
c. Fully and accurately represents the modeled system.
d. Predictive such that it can be used to derive correct conclusions about the modeled system.
e. Inexpensive meaning it is much cheaper to construct and study than simply building and
observing the modeled system."
Source Grady/Green 2008 (not known where it is on internet yet). Copy on request from Grady, , who has initially shared with with the INCOSE Requirements Working Group.

Gilb DISCUSSION of the Selic Quotation:

1. THE Function OF A MODEL

a model is some representation of a PAST/PRESENT/FUTURE reality.

Here is my Planguage Concept Glossary definition

(source
http://www.gilb.com/tiki-page.php?pageName=Competitive-Engineering-Glossary)

----------~~- paste of Concept *448~~------
Model. Concept *448 August 2, 2001 (updated Jan 6 08 with 2 a->e below)

A model is an artificial representation of an idea or a product. The representation can be in any useful format including specifications, drawings and physical representations.

Rationale: to convey information about an idea without having to deal with a full Scale and real version of it.

Related Concept: Template , *254
• templates purpose is to give us ideas about possible patterns or ideas.
• model purpose is to convey information about one or more aspects of a system or product.

Type: engineering concept.
---------~~- end *448~~----------

2. CHARACTERISTICS OF A MODEL.

a. A given model may have any interesting limited Function (what the model does)
b. and any given DESIGN (how the model achieves its performance and cost characteristics - its efficiency)
c. a model can have any real set of perceivable (measurable, testable) performance characteristics
d. a model can have any real set of costs (for acquisition, learning, setup, operation, evaluation)
e. a model can have a set of constraints (legal, cultural, conventional, physics)

Examples of Performance characteristics 2 c. above (including all Quality characteristics):
1. Usability <- b. in Selic. Note this can be defined with 12 sub attributes, such as Intuitiveness
2. Representation Accuracy <- c. in Selic
3. Representation Completeness <- c. in Selic
4. Abstraction <- a. in Selic Note this may turn out to be a design, but we need to define it better before we decide.
5. System Characteristic Focus <- a. in Selic
6. Prediction Accuracy <- d. in Selic
---- this is a limited set that Selic mentions arbitrarily (which might give the incorrect impression that these are the only or dominant characteristics.

an extended set can be brought in as needed, and the list is open ended, and may be highly tailored to one users interests
for example (I am purposely not detailing these terms with defined Scales of Measure, but I could if I wanted to - all performance characteristics, see CE book, esp Chapter 5 Scales of Measure for detailed examples)

7. Operational Speed
8. Capacity
9. Responsiveness
10. Portability
11. Extendability
12. Tailorability
13. Security (can hackers screw it up?)
14. Ownership Rights (do have IP rights?)
15. Secrecy (can we keep it secret from competitors, enemies)
16. Acceptability (do defined Stakeholders accept the model as relevant)
17. Insight (can we determine who it operates?)
18. Maintainability (this can be defined with about 12 sub-attributes such as revalidation testing time)
19. Robustness
20. Availability
21. Reliability

Examples of Cost Characteristics dimensions:
1. Acquisition/Lisencing
2. Training
3. Setup
4. Operation.
5. Analysis

3. SPECIFIC CHARACTERISTICS OF A MODEL

3.1 All the above (and additional) Performance and Cost Characteristics can be expressed using
a. defined sub-attributes
b. designed scales of Measure
c. defined Meters or Test processes to Measure real model characteristics
d. using other Planguage (Gilb: CE book) specification capability to describe them (example Constraints. Dependencies, Risks).

3.2 All the above Performance/Cost model attributes can be applied in the following modes:
a. analysis of the ongoing operational characteristics of any given modeling method
b. comparison of alternative and supplementary modeling methods (example using Impact Estimation Tables)
c. for setting Model Requirements, future states we would like to create
d. presentation and description of specific instances or generic capability of given modeling methods.
e. research into modeling methods

4. CONCLUSIONS
a. any modeling method can be more realistically described and evaluated in terms of the above attributes

b. if we arbitrarily limit our model attribute knowledge to fewer attributes, then our understanding of the modeling method is dangerously incomplete

c. people dealing with modeling, need to upgrade their maturity level of modeling models to the level suggested above (an engineering, scientific, management level), or they cannot be taken seriously.

d. one problem with the Selic quotation is lack of other attributes (like 7 to 21 listed)

e. another problem is lack of acknowledgement that there will be different levels for any one given attribute, for any modeling tool and any given use
",Fully and accurately", "really understandable", "correct conclusions", "much cheaper" are not a useful level of description: too vague, and too general.

Based on the above, it is my conclusion that the Selic quotation is not a good basis for understanding models in general, and that the Grady/Green work would be better served by a more realistic, and more general, model of models such as the Planguage ideas above.

We hope Selic/Grady and Green would wholeheartedly agree ! :)

Share this blog:

Universal Software/Systems Modelling Languages/Standards, by Tom

Sat, 05 Jan 2008 11:31:53 +0100

This morning (Jan 5 2008) a friend sent me a 50 page PAPER he thought I should know about
" A GRAND SYSTEMS DEVELOPMENT TRAINING PROGRAM
VERSION 11.0
The union of sound system engineering, domain engineering, functional management,
and program management for the greater good of the enterprise and customer base.
VOLUME 2T DIVISION 1
UNIVERSAL ARCHITECTURE
DESCRIPTION FRAMEWORK
Re-closure of the Problem Space Model ".

This 5MB paper is not to my knowledge web available but I will post a URL when one appears.

This prompted me to write the note below in order to say what I disliked about the approach suggested (Yet Another Universal Modelling Language !!!), and what my constructive alternative/suplemental ideas were.

I have of course sent this to the authors and other friends of mine.
I understand that the authors are restricted by their current market and culture, and simply doing the best they need to do there. Good luck.

My point is to inject some alternative constructive thinking about the whole issue of these graphical modelling methods: they are NOT useful enough for what they claim to do, because they do not explicitly contain the numeric performance, cost and constraint information needed to do it.

Things that I am unhappy about in :
• I see no redeeming ideas in the paper or suggestion. We are just as well off without them.
o Integrating weak and poor ideas, does not make them better.
• There is no significant forward movement towards a modelling language idea that improves on the simple flowchart (geometrics shapes with text , connected by lines)
• This paper is too heavily influenced by the poor systems thinking of software people (let us call them the URL/SEI Crowd) who clearly have not got the slightest clue about real engineering. These are the people that have for years devised systems of modelling that still allow our software projects to fail on a massive scale.
• I like to think that good systems engineering culture, has much better ideas!

Some suggested Improvements:
• Bring in a clearer notion of quantification and Measurement http://www.gilb.com/tiki-download_file.php?fileId=26
o For all variable performance Requirements and constraints
o For all designs and strategies
• Their impact estimation (see Gilb: Competitive Engineering, Impact estimation chapter, http://www.gilb.com/tiki-download_file.php?fileId=146)
• Include data and references to the known cost effectiveness of any suggested technique for modelling,
o Including frank admission that the proposal is experimental and the cost/effectiveness is not known.
o Including, if not known, a numeric assertion of the expected range of cost and effectiveness.

Some constructive principles for systems modelling:
• Any modelling language is acceptable as long as it:

o 1. Is verifiably intelligible to the intended readership.

o 2. Serves a stated set of purposes adequately

o 3. Permits and encourages both automated and manual cross reference to any related models and model details.

o 4. Has a set of defined ‘Rules’ for specification that can both be used to teach specification, and to systematically review the specification with respect to those rules
• deviation from the rules would constitute a (spec) defect, and there must be a specified and official limit (like max. 1 major defect/page remaining) on acceptable defect levels in a specification before that spec is acceptable for defined purposes. (see Gilb: Competitive Engineering for review process and Rules examples).

o 5. Has a competitive effectiveness/cost ratio
• including training, creating and maintaining costs.

o 6. Ultimately, it must have a research-proven track record in reducing serious systems engineering problems (like predictability, quality, success, costs, delays)
• Locally: where used (our corporation)
 In many projects
• Globally: (many organizations)
 Example Defence, Space, Commercial Product development, etc.

o 7. Pending proper research on model capability, there should at least be a specific numeric assertion about the expected or hitherto experiences effectiveness and cost levels that are expected with proper use of the modelling method.
• Notice that makes no such references at all to effectiveness and cost data.
• Such studies do exist of course for software methods, and they should not be difficult to find.
 Try Google: ‘comparative studies UML’ for example .
 I would be happy to supply both studies and cases for my own methods.

Share this blog:

Requirements Completeness and Reusability: How can we measure them?

Fri, 30 Nov 2007 23:05:38 +0100

Requirements Completeness and Reusability
By Tom Gilb Nov 30 2007

A professional friend of mine, asked me about how one should Measure Requirements completeness and reusability.

He suggested that completeness was something about “Shall be measured as the difference between number of Requirements in the first set delivered, and a defined second or even third set in percent.”

His notion of reusability was ‘shall be measured as the amount of Requirements that can be copied into the next project without any changes measured in percent of the overall existing requirements.”

I did not agree and here is my reply:

1. COMPLETENESS: I agree that Requirements should be 'complete' in some sense, but I do not think the Measure you are suggesting is a good one.

2. REUSABILITY: I like the concept of reusability as such, but there is a danger that we reuse when we should 'tailor'.

The first error I believe you have in thinking, is that you
a. think in terms of whole Requirements, as being complete.

COMPLETENESS
I think:
a. that the degree of completeness of a single Requirement , is the interesting question!
b. for example if we have a target (Goal) but fail to specify a critical constraint (Fail, Survival)level then we have a serious case of incompleteness.
c. one way to determine if a Requirement is complete is by checking it (Simple Spec QC ) against the corresponding Rules (see CE book).
d. Another way is to look at the parts of a large potential template (also in CE book) that are not filled out at all.
e. missing but necessary part specifications, in a single Requirements, are counted as 'defects'. if we focus on essentials, they are Major Defects. The Measure you want is Major Defects/Page.
See SQC Simplified in CE book or
.

Regarding the question of whether the actual number of Requirements is complete, is entirely different.
1. I do not think there is any such concept. It is a static concept in a moving world.

2. this is related to the question of priorities. See papers: Managing Priorities and Choice and Priority

3. The problem is that Resources are always finite (deadline, budget, staff) and the human desire for Requirements is always something far exceeding any finite set of requirements. There is no fixed set. There is however a set of Requirements that equals or exceeds our current resources.

4. So the interesting trick here is to pull in the highest priority Requirements first, and deal with them before you run out of resources. Then, assuming you do a great job of delivering value for money, the world will happily give you more Resources, and you can continue infinitely (without stop).

5. from this discussion, it should be obvious that the interesting thing is
a. to have the ability to identify (as opposed to forget) really valuable requirements.
b. then to have the ability to reasonably accurately understand and estimate its value to a set of Stakeholders over time. Most people are really bad at systematic Stakeholder analysis, and value over time.

REUSABILITY:
1. I would warn against prioritizing the resusability of Requirements (in the literal sense - repeat or duplicate).

2. the reason is that the advantage of reuse (is it saving time, or is it getting it right?) is probably overwhelmingly lost because you then fail to tailor the Requirement to the new purpose at hand!

3. We can however speak about degrees of reuse, which I practice widely in the Planguage. But there is always some tailoring, for the task or project at hand. The tailoring to the real world is powerful, and much more important that any advantage in reuse. I just 'claim' this but I could argue the case with examples. It is overwhelmingly obvious to me.

4. TYPES OF PARTIAL REUSE IN PLANGUAGE
a. we reuse the defined terms in the standard Planguage Concept Glossary (over 650 concepts).
b. we reuse and locally defined (corporate, product, project level, even 'this Requirement ' level) terms
c. we reuse the templates (see many at end of Requirements and design chapters in CE book) which guide us to give a complete description of a requirement.
d. We can reuse parametrized scales of Measure across projects
Scale: time to learn defined [Tasks], using defined [Employee Types] in defined [Environments].
The final tailoring is in the definition of the parameters, for example:
Goal [Tasks = [Task A, Task Z}, Employee Types = New, Environments = High Pressure] 60%.

Share this blog:

New Papers!

Sun, 04 Nov 2007 01:05:44 +0100

What is wrong with QFD

Updated Paper, Major update and edit of Dec 06 version
http://www.gilb.com/tiki-download_file.php?fileId=119

Engineering the Review Process MASTER

New Paper, Nov 2 2007
http://www.gilb.com/tiki-download_file.php?fileId=143

Engineering Productivity: Some ways to Measure it and manage it.

New Paper 4 Nov 2007
http://www.gilb.com/tiki-download_file.php?fileId=144

Share this blog:

Tom and Kai Gilb blog

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

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

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

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

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

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

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

Systems Architecture and Systems Engineering?

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

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

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

Introduction

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

Confirmit awarded Value Management certificate

The Engineering Productivity Principles

Value Delivery Achievement Awarded

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

Value Management and Contracting.

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

Real QA is far more than testing!

QA Objectives

Usability Engineering Principles

Making Management Manage Metrically

How To Measure an Agile Implementation?

These opinions above, summarized, are:

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

No quibbles - my philosophy too

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

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

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

ON THE 33% TEAM EFFECTIVENESS OF AN AGILE INSPECTION

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

Are non-functional requirements functional?

Value Management Certification & Agile Inspection Certifications

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

The Value of Using Numbers in Requirements

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

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

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

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

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

Inspection Self Audit Results

Project Failure Causes and Cures

Software & Systems Quality Conference United Kingdom 2008

From Sony, HitachiSoft & JUSE in Japan

Website url change & Registration Issues NOW FIXED!

What is Productivity?

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

Gilb's - Risk & Uncertainty conference

Using Evo with Scrum

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

New Offering, Focused Knowledge Transfer Workshops

Tom Answers Interview Questions from www.agilethinkers.com

Agile Research at PHD Level

System Engineering Requirements: for software and hardware Engineers

Master Class in Quantifying Quality:

London Gilbs Seminars May and June

Registration process now fixed

Expanding and Clarifying the "Benchmark" concept. Glossary Edit.

I have rethought the concept of a requirement target, and excluded Wish.

Modeling Modeling

Universal Software/Systems Modelling Languages/Standards, by Tom

Requirements Completeness and Reusability: How can we measure them?

New Papers!

Value Engineering

Designing Maintainability in Software Engineering: a Quantified Approach

Making Metrics Practical

Quality Manifesto: Software Quality is a Systems Engineering Job

What is wrong with QFD

Engineering the Review Process MASTER

Engineering Productivity: Some ways to Measure it and manage it.