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


post & read comments, must be logged in.

Share this blog:

---

Permalink (referenced by: 0 posts / references: 0 posts)

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.

add your comment, must be logged in

Share this blog:

---

Permalink (referenced by: 0 posts / references: 0 posts)

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

add your comment, must be logged in.

Share this blog:

---

Permalink (referenced by: 0 posts / references: 0 posts)

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:

---

Permalink (referenced by: 0 posts / references: 0 posts)

Here's my first few questions to you:


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


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!


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.


You bet!
For readers who were not there, the slides are at
Paper: http://www.gilb.com/community/tiki-download_file.php?fileId=50
Slides http://www.gilb.com/community/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/community/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/community/tiki-download_file.php?fileId=38

Slides No Cure http://www.gilb.com/community/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:

---

Permalink (referenced by: 0 posts / references: 0 posts)

http://www.gilb.com/community/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/community/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:

---

Permalink (referenced by: 0 posts / references: 0 posts)

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:

---

Permalink (referenced by: 0 posts / references: 0 posts)