Agile Thinkers

Tom Gilb - Q1

Tom Gilb is one of my Agile heroes.  He's been doing and teach agile for a looooong time, but many Agile newbies may not recognise his way as the agile way.

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

Tom Gilb - Q2

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!

Tom Gilb - Q3

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.

 

Tom Gilb - Q4

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

Tom Gilb - an example from Jens ...

Jens Egil Evensen has been using Tom and Kai Gilb's EVO approach with Scrum.  Here's a few questions and some very interesting answers with Jens.  I strong recommend you read on ...

A very

Q: Hi Jens, Tom said that you've been using Scrum combined with EVO.  Can you tell me a little background about the project and what problem EVO solved that Scrum didn't?

I’ve been studying and using Evo for the past four years. First as an employee in the Norwegian Product Register (governmental) after attending a course with Tom Gilb,, and later as a consultant in one of Norways largest IT corporations (EDB ASA (Avenir)). Avenir has a rather complex and “heavy” framework for managing large waterfall like projects called AvePro (“homemade” PMI inspired) that they have been working on and used for 20 years.

One of my first assignments in Avenir (in December 2006) was when Microsoft asked us to be an implementation partner for a Norwegian telecommunications company that had decided to implement Microsoft CRM 3.0 as their standard CRM platform. The requirement specifications that where presented to us where purely functional, and there where no references to what goals or business values they wanted to achieve by implement the system. I quickly concluded that our traditional methods of project management would not cope with such a project. One of the reasons where that I suspected that if we just developed a system based on the specification that we had received, the changes in requirements during the course of the project would turn the project into one giant contract nightmare, and that delivery of the system would be infinitely delayed. It would simply join the majority of all other software development projects in the basket of failure.

We agreed to do a one month test period with one consultant (me), kind of no cure no pay, to qualify us and the system for their needs. I told the customer that with the method I intended to use, we were quite sure to give at least some stakeholder some value, and that this value would be far beyond the cost of the initial implementation of the project.

To do this I had two simple requests for the customer. I wanted one workshop with the sales managers ad the director of sales, and one workshop with the employees from their internal IT department that where suppose to participate in the project.

I started the workshop with the management by asking two simple questions:
1: What is this company's vision?
2: If you don’t think about IT or software at all, what are your greatest problem today, that prevents you from fulfilling this vision or goal?

(BTW, I’m not of the very formal types, so I attended this meeting with the management in my usual work outfit; T-shirt and jeans – in Norway that is almost perfectly okay)

At question #1, they answered a bit staggering, and after a short while, they said with a little laugh that is was their vision to be a leading telecommunications company in Norway. Laughing as if they where embarrassed by this vision (I call this Norwegian modesty). I thought that was an excellent vision, and a good starting point for our project. No point in setting the goal to low. If you’re aiming for the moon you are more likely to reach the sky than if you only aim for the roof of the nearest building.

At question #2, the director of sales had a clearer view. He said, and I quote: “We are loosing xx million Norwegian kroner each year on contracts that are ending and lost, without even trying to win them back, or prolonging them. Nobody knows they even exist”.

I answered: Okay, so if I implement a function in your system that alerts the account manager of a customer, let’s say, 2 month’s in advance that a contract is ending, you will potentially earn xx million kroner more?”. He answered yes.

This was actually a function that they could have implemented in their existing system at any time, but the management of sales had never discussed this business related problem with the IT department, and the IT department where probably to busy surviving bugs in the existing systems to listen to the real stakeholders everyday problems.

I told them that I could implement such a function for them in only 14 days and where met with a short silence... Then the director of marketing said: I never thought I would hear such a thing a IT consultant”.

In the workshop with the resources from the IT department, we discussed all the practical tasks necessary to install and configure the CRM database and server, and some other technical stuff. Just enough for me to gain their respect, and to make them know that I really knew what I was talking about when it came to programming and technical issues.

I also told them that to be real heroes to the management, they had to deliver solutions that really made some increased business value for important stakeholders in the management. Cool features might be impressive, but they are short lived and soon forgotten. Business value is sustainable. They where very skilled resources, and had many years of experience, but they had never thought of it in that way.

I told them: When your boss ask you to do something for him, you must ask why. Only then will you know what his real goal is, and only then will you be able to really help him. The answer to his question is never yes or no, it is rather one or more design ideas with an explanation, a cost estimate, and an impact estimate on his goal and other relevant impacts (good or bad). This information will make your boss able to make a smart decision on whether the solution should be implemented or not, and it will make the IT guys real heroes in the eyes of the management.

After working in this way for a month, creating business value they really needed, and showing the potential of the method, they prolonged the contract, and wanted more resources from our company. The total number of hours for this project became about 5,300. In Norway, that is considered a mid size to large project. We kept delivering business value to the customer in small weekly (!) increments for 15 months.

When the number of people working on the project increased, organizing the work became challenging. Mostly because of the rapid increments in the project, and  that not all of the developers working on the project where experienced, and needed more follow up. Evo is a great method to break down top level goals into business value and end state requirements, but contains no mechanism to organize the developers, and how they work. Although design specifications where made in detail, we had trouble with developers that where developing outside the scope of the project, and struggling for days with problems that weren't important to solve at all, without telling anybody (also called thrashing?).

To get the necessary control of the production environment Scrum where partly implemented with one team, daily stand-up and a product backlog. That product backlog where populated with design specifications from the Evo cycles. This, I found, was an ideal combination. Now I had total control of the most important requirements, expressed as the business value they wanted to achieve. A breakdown into end state stakeholder requirements. Mapping between business value and designs that where implemented. The stakeholders received business value for their money (bang for bucks), and the programmers no longer wrote code; they created business value!! Their work had suddenly got meaning, and they loved it.

As far as my knowledge goes, no single method widely used today covers all aspects of a project, from Vision to values, values to requirements, requirements to design, and design to working systems.

All methods seems to cover the “project layer” where the author of the method works, and maybe one layer up and one layer down. To cover all layers you will have to use more than one method, and select methods that have compatible interfaces, such as Evo and Scrum (Evo design specifications into the Scrum product backlog).

Avenir has now added this methodology (in a modified form) as one of our preferred agile project delivery methods (Avegility). It’s built up as three parallel cycles named “Goals and requirements”, “Production (ie Scrum)” and “Delivery and measurement”.

Q: How did you learn enough about EVO to get started?  Was that easy?

As mentioned earlier, I first learned about Evo when I attended a course held by Tom Gilb, and I must admit that the first two days of the course, I did not understand where he was going with this at all. After the course I tried it in a project at work, and I was truly amazed with the result. Lifting my eyes from the code and the software, and focusing on the required results opened up a whole new world of possible solution for me. As a consultant for a software company I must admit that this sometimes is a problem; when looking at clients requirements and goals today, I far too often sees that the best solution seldom is buying or developing new software, but to begin with the existing software, or the way they work.

If you got that business gene, and a true passion for the results you create, living the Evo is easy. If code, technicalities and gadgets are all you live for, you will probably not get the point at all.
Some people never realize that the best system is the one delivering the best results for the business, and not the fastest, prettiest and the one with the perfect architecture (although we have to care about those things as well, but then as expressed quality and performance requirements related to business values and goals)

Q:  Did you have to change Scrum much?

I suppose I get a lot of people angry now, but in this particular project, because of the short cycles, we removed the Sprint term, and worked continuously with developing and delivering items from the back log, meeting every day in the daily stand-up. In the formal method Avegility Scrum is unchanged but for one thing: It’s not the product owner that is responsible for handling and prioritizing the product backlog, it’s the Evo cycle’s output in the form of design specifications. Cost/benefit ratio decides the priorities.

Tom Gilb Q5

Q: Is it true that you are related to Santa?

I love giving gifts, especially knowledge, and I have many helper elves who help spread my gifts. I live nearer the North Pole than you do.

And my Summer cabin is right next to Drøbak - home of Santa Claus

http://www.emb-norway.ca/facts/Traditions/Christmas/julenissen.htm

But, I am not allowed to admit any more.

Tom Gilb Q6

Q: Where and when do you think it all went wrong in our industry?  I'm particularly interested in the historic misunderstanding that caused the waterfall model to spread.  What made it so "sticky?" compared to incremental / evolutionary development?

(I have asked Craig if i can put this on my website).

Well, It is a long story! Once Upon A Time, we had small hardware memories, and small programs, and smart people. So projects were short, simple and worked pretty well.
Then memory started getting much bigger.  Software got much bigger, and complexity of the software got horrendously much bigger. Things got late and buggy.

The obvious solution seemed to use good 'engineering methods'. So, based on a misunderstanding of Winston Royce, who pointed out that a Waterfall Process would only work for small systems, and that iteration/feedback/learning was necessary for complex systems, the US DoD, encouraged by Barry Boehm (a TRW Colleague of Royce), adopted the Waterfall Standard (DoD 2167 and 2167a). Well, it was not intended to be a strict Waterfall Process, the author personally told me, but it got misinterpreted that way. A little bit of requirements and design before coding is not such a bad idea. But the DoD, whose project size was exploding during this time, discovered that half of their $40 Billion annual software projects were total failures anyway. So in 1994 thy officially cancelled the 2167a Standard, and officially instituted the Mil Standard 498 Evolutionary Standard. It turns out that smart rocket scientists, who were not forced to do Waterfall, had always used Iterative/Feedback methods (http://clublet.com/examples/docs/IIDHistoryByLarman.pdf).  I campaigned for Evolutionary methods, mostly for deaf ears  practicing in Sixties, and publishing in Seventies. But the real awakening came when the Agile Boys read Principles of Software Engineering management (1988) and made iteration a fundamental practice. Too bad they did not read the entire book and realize that to control the iteration and learn, you also need to quantify the top level critical improvement objectives of the system. Some of my Agile friends, like Ryan Shriver, have recognized this failing and are actively practicing iterative control as I would advise. With focus on delivering measurable value to stakeholders, and not just stories to customers.

My underlying theory is that the Waterfall Method allowed Software Companies to earn a lot o money without actually delivering any or much value. So the real culprit is not unenlightened programmers, they are just foot soldiers. The real problem is the political leaders (top managers) who persist in paying so much for so little to so few.

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

So there was a historic misunderstanding (of Royce's message) - but the real problem, as I see it was lack of responsible management - to pay for value , not pay for useless programming work.

Tom Gilb Q7

Q: Can you give us a simple example (or two) of how to quantify requirements?  I recall one interesting example you gave when you did training for us at AgileScotland that involved (I think) making online survey forms easier to use ...

Well, the longer answer is available:
http://www.gilb.com/community/tiki-download_file.php?fileId=124  <- Quantifying Quality Paper.

But the main idea is that for a critical improvement (usually 'Quality') attribute - we need to articulate the idea with Numbers.

This involves two steps:

1. Define  scale of measure
2. Define some useful numeric points on that scale.

So instead of 'better user friendliness"

we might write:

Usability:
Scale: The average time needed for an average user to correctly perform representative tasks.
Past 10 hours.
Goal [2009] 1 hour.

Most people can quickly pick up on doing this.
When you get stuck there are lots of available Scale patterns to use, and to tailor to your specific purposes.

My favorite teaching example is quantifying 'Love' !
A friend pointed out the Bible, Corintians 1, had the solution! - as I pointed out earlier.

Google them!  For example:  "Intuitiveness software metric"  , if all else fails try   Intuitiveness software metric gilb  :)