Improvement Principles

I assembled this set of principles to guide me and others through the sometimes stormy times of change. To me, 'times of change' equals 'always'. If there's one common theme among all my different job positions and private challenges, it's the wish for improvement. Use these principles whenever you embark on a journey.

Praise! Use numbers to show quality impact.

I just stumbled upon a very nice blog entry by Fergal McGovern of Visible Thread. It is about my article on "Extreme Inspections". Fergal appreciates that I showed ROI figures:

What was doubly exciting for me in this article is that you see the actual ROI of inspection in clear terms. Utilising the approach of ‘extreme inspection’ in one case Rolf cites, we see a reduction in the number of defects per page by 50%. Clear empirical evidence of actual defect reduction as a consequence of inspections in real projects is hard to come by and so Rolf’s case studies are useful to consider.

Thank you Fergal!

I took a looong look on Fergal's company and website. Their solutions look very promising in terms of document quality assessment and improvement. Visible Thread does detailed quality checks on Office documents and shows the results, for grounding decisions on data is always better than on gut feeling.
Head over and see for yourself.

Hyper-Productive Teams

The Agile Engineer Ryan Shriver has stunning news from the productivity front. After he 'produced' a whopping 1.750 attendees for his webinar on the topic, he was kind enough to share the presentation slides and a companion article. I quote from the article:

Hyper-productivity describes a state of being where teams are working at much higher levels of performance such as two, three and four times more productive than their peers. 

The interesting question for agilists and other method-interested people alike is: How can I do it? Well research shows than hyper-productivity seems to come with a couple of practices, all to be found in Ryans slide set and article. Be aware, don't get trapped into the logic than you only need to follow these practices to be hyper-productive.
I'd like to highlight one theme here, and Ryan probably says it best (mark-up is mine):

[...] the difference with the hyper-productive teams is their ability to stick to the practices over the project while continually removing impediments limiting performance.  

This resonates quite a bit with something Eric Ries posted about a startup lessons learned conference, in which Kent Beck happened to develop another manifesto, apparently (mark-up is mine):

Team vision and discipline over individuals and interactions (or processes and tools)

Validated learning over working software (or comprehensive documentation)

Customer discovery over customer collaboration (or contract negotiation)

Initiating change over responding to change (or following a plan)

I wouldn't go as far as calling this the new agile manifesto. This is more a set of paradigms for startups, so one could call it a startup manifesto ;-).

Adding to Acceptance Testing

James Shore has sparked a lively discussion about sense and nonsense of acceptance testing. To be honest, my very first reaction to this piece of text was forbidding:

"Acceptance testing tools cost more than they're worth. I no longer use it or recommend it."

But James expanded on his statement in another post. And there he impressed me.

"When it comes to testing, my goal is to eliminate defects. At least the ones that matter. [...] And I'd much rather prevent defects than find and fix them days or weeks later."

Yes! Prevention generally has a better ROI than cure. Not producing any defects in the first place is a much more powerful principle than going to great lengths to find them. That's why I like the idea of inspections so much, especially if inspections are applied to early artifacts.

James also very beautifully laid out the idea that in order to come close to zero defects in the finished product, you need several defect elimination steps. It is not sufficient to rely on a few, or even one. Capers Jones has the numbers.

I'd love to see this discussion grow. Let's turn away from single techniques and methods and see the bigger picture. Let's advance the engineering state of the art (sota, which is a SET of heuristics). Thank you, James!

Who is your hero systems engineer?

These days, I‘m inquiring about engineering. I‘d like to know who your hero systems engineer was or is (or will be?). Please comment, or send me a twitter message. Thank you!

Thank you again for making it past the first paragraph. ;-) It all started when a couple of weeks ago I again was confronted with a colleague‘s opinion which said that I am a theorist. I refuse this opinion vehemently; quite the contrary, I believe my work, especially my work for the company, is a paragon of pragmatism. ;-)

So my argument against the opinion usually is ,no, I‘m not a theorist!', in a more or less agitated voice. Obviously, I need a better basis for making that point. Kurt Lewin said:

Nothing is a s practical as a good theory.

I used this sentence for a while as a footer for email that I suspected to raise the ,theorist‘ criticism again.

After all this sentence is only a claim as well, just like my stubborn phrase above. It may be stronger because it carries Lewin‘s weight. Unfortunately very few people instantly know who Kurt Lewin was, and that he most of all used experience - not theory - to advance humankind.

Then a friend of mine, a U. S. citizen who at some point in time chose to live in Norway (which is a very practical move in my eyes :-), pointed me to the work of Billy V. Koen, Professor for Mechanical Engineering at the University of Texas. You should watch this 1 hour movie if you are least interested in engineering, philosophy and art. Or in more mundane things like best practices, methods, techniques, recipes, and checklists, many of which concerning business analysis and project management can be found at Planet Project in case you don‘t know.

Here is Prof. Koen‘s definition of engineering from the movie:

The Engineering Method (Design) is the use of heuristics to cause the best change in an uncertain situation within the available resources.

Causing change in an uncertain situation within the available resources sounds a lot like project management to me. Like program or portfolio management, too. Maybe like management in general.

It is always when an improbable connection opens up between two different fields of my thinking when I find there is useful truth in it. Next, I want to learn about engineering and me, and one way to approach this is to find out who I admire for his or her engineering skills. I tried thinking of a couple of candidate names and found surprisingly few. I‘ve already identified Leonardo Da Vinci (who is not a Dan Brown invention like my nephew once suggested. :-) A quick request to the twitterverse offered nothing, no new name.

So this is my next take: I‘d like to know who your hero systems engineer was or is (or will be?), and why. Please comment, or send me a (twitter) message. Thank you!

Quantum Mechanics, Buddhism, and Projects - Again!

Today I'm proud to announce that my QMBP :-) article was again published by a major web site on business analysis, requirements engineering and product management: The Requirements Network. The site is full of interesting material for beginners and experts. I recommend reading it.

You'll find the piece of mine and some interesting comments here.

And - ha! - mind the URL of my article: ... node/1874.

Did you know that Winston Churchill was born that year? Must say something ... :-D

Find out more about 1874.

A Quest for Up-Front Quality

Today I'd like to point you to the presentation slides of a talk I gave at this year's Gilb Seminar on Culture Change in London. 

You'll find the file if you go to this PlanetProject page on Zero Defects, navigate to principle P6 and click the link titled "presentation".

The title was "A Quest for Up-Front Quality".

Short outline:

• Why I wanted to have a rigorous QA effort for the first steps of a real-life project
  
• What I did to achieve this (Tom Gilb's Extreme Inspections, aka Agile Inspections, aka Specification Quality Control (SQC))
  
• What the outcomes were, in terms of both quality and budget (with detailed data)
  
• What the people said about the effort
  
• What the lessons learned are
  

If you want to see truely amazing results for one of the most effective methods of software development history, don't miss the slides. Any questions? Just ask!

The talk was warmly welcomed by the great Value-Thinkers of the seminar, special thanks to Ryan Shriver, Allan Kelly, Giovanni Asproni, Niels Malotaux, Matthew Leitch, Jerry Durant, Jenny Stuart, Lars Ljungberg, Renze Zijlstra, Clifford Shelley, Lorne Mitchell, Gio Wiederhold, Marilyn Bush, Yazdi Bankwala, and all others I forgot to mention. 

Understanding the exponential function

I was pointed to a set of videos that explores the exponential function and what most people think about its consequences. Seems to be a boring topic.

It isn't. I watched the first 10 minutes, only to realize my jaw has dropped to the floor. This is stuff I knew and didn't grasp at the same time. I strongly suggest you invest the ∼75 minutes and watch it.

It hit me two days after I started to drivel about me liking sustainable solutions. I wasn't up to all my senses, obviously. ;-) 

Do you care about your customer, every day?

There's a wonderful parable on real customer satisfaction on the "i must be an acrobat" weblog by Joshua Hoover.

He compares eating out in a restaurant with inattentive waiters to developing software without delivering real results to a customer.

Software Development Practice in the 21st (22nd?) Century

A couple of months ago I published an article about 10 Critical Requirements Principles for 0-Defects-Systems (on Ravens Brain). Anecdotal evidence on how I once achieved zero defects in one of my projects.

If you like the thought of reliable software (sic!) you might as well like Charles Fishman's article on the On-Board Shuttle Group, the producer of the space shuttle's software. Yes, they have a lot of money to spend, but many lives and expensive equipment are at stake.

This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. -- Charles Fishman on the software product the Group puts out

BTW, they seem to use three key pracices: very detailed requirements, inspections and continuous improvement.

The way the process works, it not only finds errors in the software. The process finds errors in the process. -- Charles Fishman on the On-Board Shuttle Group's process

Happy New Year! (Note that 2009 is a year of the 21st century. Can't we do any better?)

PS: I'm going to go on vacation from Dec 28 to Jan 20. More interesting topics still to come, please be patient.

All you want to know about Stakeholder Management

Alec Satin of the "Making Project Management Better" weblog has a brilliant list of links to Stakeholder management resources.

From his explainatory text:

In this list are articles to get you thinking about some of the less obvious issues in pleasing stakeholders. Primary selection criteria: (a) quick to read, (b) good value for your time, and (c) of interest whatever your level of experience." Markup is mine.

Enjoy!

7 Rules for High Effectiveness

Name: 7 Rules for High Effectiveness
Type: Rules
Status: final
Version: 2008-07-03

Gist: Effective problem solvers develop a mind set of effectiveness. Here are the 7 Habits of Highly Successful People, from Stephen R. Covey, Simon & Schuster, Inc., 1989

R1: Be Proactive - take the initiative
R2: Visualize the end from the start - know where you're going ' it is better to do this quantitativly
Note: A good technique for doing R2 and R3 is the Kepner-Tregoe-Method, which is quite well described here. Better, still, is using Impact Estimation Tables (because of their much better handling ob quantitative information.)
R3: List priorities ' it is better, still, to do this quantitativly
R4: Think WIN/WIN
R5: Understand - listen, listen, listen / learn, learn, learn
R6 Synergize - make the whole more than the sum of the parts
R7: Seek Personal Renewal in various areas:
- Physical: exercise, nutrition, stress management
- Mental: reading. Thinking
- Spiritual: value clarification, meditation
- Social/Emotional: empathy, self-esteem

12 Helpful Rules for Refactoring a System

Name: 12 Helpful Rules for Refactoring a System
Type: Rules
Status: final
Version: 2008-04-25

Gist: to provoke 2nd thoughts if you are to take some part in a refactoring. Refactorings seem to come about more frequently these days, maybe because even the stolid of the business people start to talk about 'agile'. Like all these now-buzzwords, there's a lot of potential misunderstanding hiding in the very word.

Refactoring DEFINED AS modifying something without changing its externally observable behaviour with the purpose of making maintenance easier. Note that you can refactor many things, ranging from systems to architectures to design to code. However, relevant literature suggests that Refactoring is meant to relate to Design and Implementation. See Martin Fowler's Website. Also see Code Refactoring.

R1) Whenever you hear the word refactoring, run! 'just joking...

R2) Precisely understand what the various stakeholders think a refactoring is. You'll be surprised. Correct the wording if needed.

R3) Precisely understand what purpose the refactoring has, from each of the stakeholder's point of view. Align expectations before you start.

R4) Assume a great deal of resistance from the people who pay. Refactoring for them is another word for "Give me $$$, I'll give you what you already have! " Find out who will pay for maintenance.

R5) By all means reduce the risk of having a system with new bugs after the refactoring. This can be done by rigorous test driven or even behaviour driven development for example. Any change in behaviour should be treated as a bug.

R6) Challenge the business case (if any ...) of the refactoring. At least, do proper cost-benefit analysis. For example, the system may not live long enough to amortize refactoring.

R7) Prepare for the situation that nobody can provide exact and dependable information on how future budgets will be affected by the refactoring

R8) Back off from refactoring if significant portions of the code will be both refactored and worked over due to new requirements. Do one thing at a time and bear in mind R5.

R9) Prepare for 3 different points of view if you ask 2 people for what specific refactorings should be done.

R10) Think of short-term and long-term effects.

R11) The improvement must be both quantified beforehand and measured afterwards, at least for non-local changes to the system.

R12) Be suspicious if someone suggests only one or two specific refactoring techniques will suffice to reach a project-level goal.

Calculate Process Efficiency

Name: Calculate Process Efficiency
Type: Process
Status: final
Version: 2008-04-10

Gist: to find out, where in a process you can improve efficiency, with respect to added value to the customer
Sources: http://www.shmula.com/458/the-hidden-factory-would-the-customer-pay-for-that

Process DEFINED AS a systematic chain of activities with a customer observable outcome.
Note: this may be a use case, a scenario used to plan the user experience for a product, a company's process chart ...

Process efficiency DEFINED AS value adding activities in a process divided by all the activities, in seconds, minutes, hours, days ...
Note: You could also measure it in money, or people, or other resources.

S1: Plot the process, maybe using a UML activity diagram

S2: For each activity in the diagram, decide if it's either
- adding value to the customer,
- not adding value to the customer, but is absolutely necessary, or
- not adding value to the customer

S3: Measure with a stopwatch how long each activity takes.

S4: Sum the measured times for each category of S2

S5: Divide the measurement for the 'adding value'-category by the sum of S4, that's your Process Efficiency.

Note: Most likely you will come up with a number smaller than 1, because of the 'not adding value' activities that are necessary.
Note: the 'not adding value' category is the cost you bear on your customer, but does not add any value to the customer. (uh!)
Note: Obviously, from this point on work to eliminate not adding value activities. Or at the very least reduce the time needed for them.

12 Tough Questions for Waterfall Projects

Title: 12 Tough Questions for Waterfall Projects
Type: principles
Status: final
Version: 2008-08-22
Gist: to show waterfall projects what they are missing; to show waterfall projects that say they have always been 'agile', that they really have not.
Source: I stole the idea from Tom Gilb's (generic) 12 Tough Questions.

1) why aren't you able to show some useful piece of product after less than 10% of scheduled project time?
2) how do you know that you will hit the scheduled delivery date, at the start of the project?
3) how productive is your team, in terms of features delivered per month? why don't you know?
4) how do you prevent gold-plating before all the necessary features are done?
5) do you know how many defects you have implemented in the latest version of your product? why did you implement those?
6) what if you want to choose between fixed-date and fixed-scope near the end of your schedule?
7) how long does it take you to know wether a change to the system caused ripple effects?
8) how do you know that every feature you deliver is useful by the date of delivery?
9) why aren't you able to deliver a useful system halfway through the project schedule if management wants you?
10) why isn't your team committing to deliver the feature set planned for the project?
11) if the requirements will change anyway, why do you write them down way in advance?
12) do you pay your contractors cash money, even if they have not provided you with a valuable solution to your problem yet?

Do Job Interviews Efficiently

Title: Do Job Interviews Efficiently
Type: Rules
Status: final
Version: 2008-08-22
Gist: selecting people to join your project team in an efficient and fun manner

R1) invite all candidates at once
R2) talk to the group, let the group talk to itself
R3) wait for the silent people to be asked questions by other people
Note: You will need to explain the project only once. You will feel the people you want to be with in a couple of minutes anyway.
You will save time.

Go Agile, Enterprise Wide

Title: Go Agile, Enterprise Wide
Type: Rules
Status: final
Version: 2007-07-26
Source: Pollyanna Pixton, talk at APLN 2006, Gerhard Wohland, Niels Malotaux, my own thoughts

R1: make sure the individuals in the enterprise want to learn and are allowed to learned
- unleash creativity
- lead change (not adopt to change)
Note: since business is global now, you have to put pressure on competitors if you want to sustain and succeed. You cannot just follow, because your market share will be eaten up by others.

R2: prioritize: all decisions are based on business value
- what is the most valuable thing to do *now*
- change lubricant slogan: "take the fun out of being disfunctional"
- finding business value of new products: give the product away for free

R3: do cascading agile:
- Do a business-level roadmap cycle every 3-6 months. "Do the tactical objectives still comply to the enterprise's strategic plans?"
- Do a project-level tactical cycle every 1-3 months. "Does our business unit / project still comply to the tactical objectives?
- Do a delivery-level cycle every 2 weeks or less. "Are we moving towards the right product?"
- Do a task-level cycle every 1 week. "Are we doing the right things in the right order?"

R4: Iterate: Review Goals and Objectives
Principle 1: full transperancy, give all information to everybody
Principle 2: fail early, fail fast!

Leadership

Title: Leadership
Type: Principles
Status: final
Version: 2007-07-25

P1) Step aside and let your team members work
P2) Only do 2 things
- make shure everybody has what they need to succeed
- create a place where people want to be

Note: If your people are passionate about what they are contributing to your endeavor, THEY will work things out (better than you can). You just sit and watch!

Note: It is a leader's responsibility to protect the team from leaders higher up in the food chain, that are trying to dictate how to do things.

Evolutionary Development, Waterfall and Change

Title: Evolutionary Development, Waterfall and Change
Type: Principles
Status: final
Version: 2007-07-10
Gist: Explain which conditions make a case for evolutionary development.
Source: Scott Selhorst on http://tynerblain.com/blog/2007/07/09/enabling-and-resisting-change/
Find a less brief description of Evolutionary Development here. http://kw-agiledevelopment.blogspot.com/2007/06/scrum-agile-development-uncommon-sense.html

P1: Evolutionary Development can very briefly described as:
Decide what needs to be done.
Do the most important things first.
Release the product incrementally as you complete items.
Re-evaluate and repeat.

P2: Waterfall Development can very briefly described as:
Decide what needs to be done.
Do things in an efficient sequence.
When finished, release the product.

Note: Kelly Waters descibes waterfall as: "Seeking to complete *everything* before releasing *anything*."

P3: There are at least 3 types of change where, if they occur, evolutionary development is better in handling than waterfall development.
Change in business needs (less frequent, large change each)
Change in requirements (frequent, medium change each)
Change in business rules (more frequent, small change each).

Humbling Exercise on Estimation

Title: Humbling Exercise on Estimation
Type: Process
Status: final
Version: 2007-07-27
Gist: show the participants of the experiment that they are not very good at making estimates and not very good at knowing what the requirements for a solution are
Source: Niels Malotaux, Gilb Seminar on Decision Making, London, UK, 2007

S1: Explain the 'project': "multiply 2 numbers of 4 digits each, on paper". Every participant will conduct the project on his or her own.
S2: Ask for everybody's estimate, how long the project will take to be finished.
S3: Everybody shall measure the time needed, from reception of the requirements to delivery of the result.
S4: Give the requirements: "The numbers are: 4-5-6-7 and 9-8-7-6".
S5: Let them re-estimate.
S6: Interrupt them now and then by talking, because this happens to every project.
S7: Yot down the times needed.
S8: Ask if they have testet the result. Make them test their results and take the time again.
S9: Add the times and compare them to the original and second estimates.
S10: Show them a solution to very different requirements. Make something up, like changing the order of the digits.

Note: There are a couple of interesting questions to ask here.
Like "What does 'finished' mean?",
"What was the reason for the adjustment of the original estimate?",
"What was the impact of the interrupts?",
"Is it rational to forget testing, and why does it happen all the time?",
"Why were we assuming that we really understood the requirements?"