Clear Conceptual Thinking

Testing is indespensable. Or is it?

noreply@blogger.com (Rolf) — Mon, 15 Aug 2011 14:54:00 +0000

I added a set of rules (questions, really) to my wiki, concerning product test as measurement of product quality. Please check it out and spread the word: Article on PlanetProject.

No Ads.

noreply@blogger.com (Rolf) — Mon, 02 May 2011 14:31:00 +0000

Just a quick note: I decided to make ClearConceptualThinking.net an ad-free blog. I'm also working on making PlanetProject.wikidot.com an ad-free wiki.

Improvement Principles

noreply@blogger.com (Rolf) — Sat, 19 Feb 2011 13:56:00 +0000

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.

Links to Web-Resources on Agile

noreply@blogger.com (Rolf) — Tue, 28 Dec 2010 12:43:00 +0000

I gathered a list of web resources on Agile, especially Scrum and Evo, for a friend of mine. Far from complete!
You can access it here:

http://planetproject.wikidot.com/links-to-resources-on-agile

Enjoy!

The Power of the Prototype-Refine-Cycle

noreply@blogger.com (Rolf) — Fri, 09 Jul 2010 05:23:00 +0000

Ted has another brilliant short (6:30 min) video from Tom Wujec. It shows two remarkable insights into design:

The power of building things evolutionarily
The power of having someone on the team who understands process

See for yourself:

Nice, ain't it? Let's go for more Ta-Da! moments.

Praise! Use numbers to show quality impact.

noreply@blogger.com (Rolf) — Thu, 08 Jul 2010 08:27:00 +0000

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.

What are the most valueable specifications?

noreply@blogger.com (Rolf) — Wed, 23 Jun 2010 09:00:00 +0000

During my last vacation I came across evidence of good technical value specifications. At VW's Autostadt there is a display of this wonderful old Phaeton Sedan (sorry the photo is blurred).

There also is a reproduction of a poster that was used to market the car at its times. It clearly states the most important values the car delivers. Reading through it, and thinking of the extreme focus on functions nowadays, I ask you: Did we forget to focus on the really important things, like value?

The poster reads:
It is our belief that the most important "specification" of the Cord front-frive are: Do you like its design? Does the comfort appeal to you? Does it do what you want a car to do better and easier? When a car, built by a reputable and experienced company meets these three requirements, you can safely depend on that company to adequately provide for all mechanical details. -- E.L.CORD

Hyper-Productive Teams

noreply@blogger.com (Rolf) — Mon, 07 Jun 2010 06:44:00 +0000

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

noreply@blogger.com (Rolf) — Thu, 04 Mar 2010 19:42:00 +0000

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!

New Layout for ClearConceptualThinking.net

noreply@blogger.com (Rolf) — Sat, 27 Feb 2010 07:21:00 +0000

I finally found the time to change the layout of my blog. Hope it's much clearer now, improved readability. There are some issues with the way Google displays ads, but I hope to fix this within the next couple of days.
Let me know what you think, please!

Problem to Solution - The Continuum Between Requirements and Design

noreply@blogger.com (Rolf) — Thu, 25 Feb 2010 06:33:00 +0000

Christopher Brandt, relatively new blogger from Vancouver, Canada, has an awesome piece about the difference between problem and solution. If he blogs more about problem solving, and in this outstanding quality, he definitely is someone to follow.

While I do not completely agree with the concepts, I believe everybody doing requirements or design should at least have this level of understanding.

Requirements written that imply a problem end up biasing the form of the solution, which in turn kills creativity and innovation by forcing the solution in a particular direction. Once this happens, other possibilities (which may have been better) cannot be investigated. [...] This mistake can be avoided by identifying the root problem (or problems) before considering the nature or requirements of the solution. Each root problem or core need can often be expressed in a single statement. [...] The reason for having a simple unbiased statement of the problem is to allow the design team to find path to the best solution. [...] Creative and innovative solutions can be created through any software development process as long as the underlying mechanics of how to go from problem to solution are understood.

Which brings me to promote again and again the single-most powerful question for finding requirements from a given design: WHY?

Don't forget to have fun ;-)

Using Extreme Inspections to Significantly Improve Requirements Practice

noreply@blogger.com (Rolf) — Wed, 03 Feb 2010 13:46:00 +0000

Today I'm pround to announce that one of my latest articles has been published on modernanalyst.com:

Using Extreme Inspections to Significantly Improve Requirements Practice

It will be showcased next week in the Feb issue of the eJournal of ModernAnalyst.

From the introduction:
Extreme Inspections are a low-cost, high-improvement way to assure specification quality, effectively teach good specification practice, and make informed decisions about the requirements specification process and its output, in any project. The method is not restricted to be used on requirements analysis related material; this article however is limited to requirements specification. It gives firsthand experience and hard data to support the above claim. Using an industry case study I conducted with one of my clients I will give information about the Extreme Inspection method - sufficient to understand what it is and why its use is almost mandatory, but not how to do it. I will also give evidence of its strengths and limitations, as well as recommendations for its use and other applications.

Thank you, Adrian, for your support!

Project management template for FREE download KOSTENLOSER Download: Projektmanagement Vorlage

noreply@blogger.com (Rolf) — Thu, 24 Dec 2009 06:28:00 +0000

Projects by the book or by the trenches?

The PRINCE2 project management standard by the OGC is a very practical piece of work. There is no obligation to do it by the book while you meet certain criteria. And it is supposed to be helpful, not an obstacle. I believe it is indeed helpful, and that is exactly why I based upon it the design of some quite central piece of paper document for some projects I work on, the Project Identification Document (German: Projektleitdokument).

I wanted to fulfill the following requirements:

• Mustn‘t be lengthy.

• Mustn‘t become shelf-ware.

• Must be easy to maintain.

• Must be interesting for the steering committee, the project manager and the project team.

• Must include everything relevant to guide projects of 5 - 20 week‘s duration.

• Mustn‘t shut off readers who are not familiar with PRINCE 2.

• Must facilitate checking defect density, i. e. number of defects per page.

• Must combine the PRINCE 2 Project Identification Document, Business Case, Project Mandate and Project Brief into one (1) manageable document (huh!).

I decided to design a standard document structure for one of my clients, along with guiding descriptions of every document section and a checklist for each section. As you might suspect from my background, my former work and my friends, I not only rewrote the respective PRINCE 2 product, but included my 12+ years experience with projects and some relevant pieces of good engineering, as taught by honorable Tom and Kai Gilb.

Out came the RTF template you can download for free from PlanetProject. Be aware that RIGHT NOW IT IS IN GERMAN only. If you would like to have it in English, please contact me and provide me with a good reason to work on the translation :-) (or maybe YOU translate it and provide it on Planet Project, too?)

Let me know what you think, please!

German Planguage Concept Glossary

noreply@blogger.com (Rolf) — Thu, 24 Dec 2009 05:28:00 +0000

I published a German Version of the Gilb's Planguage Concept Glossary on Google Docs. It comprises the 178 core terms of systems engineering and RealQA concepts that are part of the Competitive Engineering book. In the future I plan to translate the rest of the over 500 carefully defined terms.

The German words have been chosen to form a body of terms that is similar to the English original version, similar in coherence and completeness. Therefore, it is not a simple word to word dictionary translation. To the German reader, some of the words may seem to be translated badly. However, if you study the original glossary carefully, you will see that they make sense.

Furthermore, the terms have been tested in corporate practice and professional German conversation over a period of about a year. Most of them can be intuitively understood by Germans or German-speaking people; others need a quick look into the glossary definitions (which is something that is restricted to English-speaking readers ;-).

I'm happy to take your comments, critique and encouragement!

Who is your hero systems engineer?

noreply@blogger.com (Rolf) — Sat, 05 Dec 2009 08:24:00 +0000

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!

Why High-level Measurable Requirements Speed up Projects by Building Trust

noreply@blogger.com (Rolf) — Sat, 03 Oct 2009 10:20:00 +0000

(Allow 5 minutes or less reading time)

Stephen M.R. Covey‘s The Speed of Trust caused me to realize that trust is an important subject in the field of Requirements Engineering.
Neither the specification of high-level requirements (a.k.a. objectives) nor the specification of measurable requirements are new practices in requirements engineering after all, just solid engineering practice. However, they both are extremely helpful for building trust between customer and supplier.
The level of trust between customer and supplier determines how much rework will be necessary to reach the project goals. Rework – one of the great wastes that software development allows abundantly – will add to the duration and cost of the project, especially if it happens late in the development cycle, i. e. after testing or even after deployment.

Let me explain.

If you specify high-level requirements – sometimes called objectives or goals – you make your intentions clear: You explicitly say what it is you want to achieve, where you want to be with the product or system.
If you specify requirements measurably, by giving either test method (binary requirements) or scale and meter parameters (scalar requirements), you make your intentions clear, too.
With intentions clarified, the supplier can see how the customer is going to assess his work. The customer‘s agenda will be clear to him. Knowing agendas enables trust. Trust is a prerequisite for speed and therefore low cost.

“Trust is good, control is better.” says a German proverb that is not quite exact in its English form. If you have speed and cost in mind as dimensions of “better,” then the sentence could not be more wrong! Imagine all the effort needed to continuously check somebody’s results and control everything he does. On the other hand, if you trust somebody, you can relax and concentrate on improving your own job and yourself. It’s obvious that trust speeds things up and therefore consumes less resources than suspiciousness.
Let‘s return to requirements engineering and the two helpful practices, namely specifying high-level requirements and specifying requirements measurably.

High-level Requirements
Say the customer writes many low-level requirements but fails to add the top level. By top level I mean the 3 to 10 maybe complex requirements that describe the objectives of the whole system or product. These objectives are then hidden somehow implicitly among the many low-level requirements. The supplier has to guess (or ask). Many suppliers assume the customer knew what he did when he decomposed his objectives into the requirements given in your requirements specification. They trust him. More often than not he didn‘t know, or why have the objectives not been stated in the requirements specification document in the first place?

So essentially the customer might have – at best – implicitly said what he wants to achieve and where he is headed. Chances are the supplier’s best guesses missed the point. Eventually he provides the system for the customer to check, and then the conversation goes on like this:

You: “Hm, so this ought to be the solution to my problem?”
He: “Er, … yes. It delivers what the requirements said!”
You: “OK, then I want my problem back.”

In this case he would better take it back, and work on his real agenda and on how to rebuild the misused trust. However, more often than not what follows is a lengthy phase to work the system or product over, in an attempt to fix it according to requirements that were not clear or even not there when the supplier began working.

Every bit of rework is a bit of wasted effort. We could have done it right the first time, and use the extra budget for a joint weekend fishing trip.

Measurable Requirements
Nearly the same line of reasoning can be used to promote measurable requirements.
Say the customer specified requirements but failed to AT THE SAME TIME give a clue about how he will test them, the supplier most likely gave him a leap of faith. He could then either be trustworthy or not. Assume he decided to specify acceptance criteria and how you intend to test long after development began, just before testing begins. Maybe the customer didn‘t find the time to do it before. Quite possibly he would change to some degree the possible interpretations of his requirements specification by adding the acceptance criteria and test procedures. From the supplier‘s angle the customer NOW shows your real agenda, and it‘s different from what the supplier thought it was. The customer misused his trust, unintentionally in most cases.
Besides this apparent strain on the relationship between the customer and the supplier, the system sponsor now will have to pay the bill. Quite literally so, as expensive rework to fix things has to be done. Hopefully the supplier delivered early, for more time is needed now.

So...
Trust is an important prerequisite to systems with few or even zero defects; I experienced that the one and probably last time I was part of a system development that resulted in (close to) zero defects. One of the prerequisites to zero defects is trust between customer and supplier, as we root-cause-analyzed in a post mortem (ref. principles P1, P4, P7, and P8). Zero defects mean zero rework after the system has been deployed. In the project I was working on it even meant zero rework after the system was delivered for acceptance testing. You see, it makes perfect business sense to build trust by working hard on both quantified and high-level requirements.
In fact, both practices are signs of a strong competence in engineering. Competence is – in turn – a prerequisite to trust, as Mr. Covey rightly points out in his aforementioned book.

If you want to learn more on how to do this, check out these sources:
Measurable Value (with Agile), by Ryan Shriver.
How to rewrite a requirement / How to make it measurable (See a live example of a bad and a good high-level specification), by Tom and Kai Gilb.
You can also find related material on Planet Project:
How to Specify High-level Requirements (aka goals).
Requirements Hierarchies and Types of Requirements.

Quantum Mechanics, Buddhism, and Projects - Again!

noreply@blogger.com (Rolf) — Thu, 10 Sep 2009 08:36:00 +0000

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.

Give Kelly Waters a Hand

noreply@blogger.com (Rolf) — Wed, 29 Jul 2009 17:28:00 +0000

Follow me on Twitter: @rolfgoetz

Kelly Waters, the creator of the wonderful All About Agile Weblog, in a recent post is striving for more reach.

I can recommend his work, it's all about agile software development and agile project management. He highlights interesting things about agile all over the web and writes original content explaining some of the key agile principles, how to implement Scrum, user stories and lots more. A really rich source of information about the topic, and easy to read and grasp. He also has ann extensive home page there, so you'll find things easily.

Go check him out and stay with him!

PS: In case you somehow loose the link to the All About Agile Weblog, you can always come back to my site and scroll down to the "links."-section on the right. It will be there.

Why it is stupid to write specifications and leave out background or commentary information

noreply@blogger.com (Rolf) — Tue, 28 Jul 2009 11:07:00 +0000

Follow me on Twitter: @rolfgoetz

I wrote a set of rules over at PlanetProject that explain why it is a good idea to specify requirements (or designs) giving commentary or background information, and how to do it.

The article is based on a rather tiring discussion with a hired reqiurements specification writer in one of my projects. She seems to get defensive as soon as I suggest she should supply more 'context' for the readers of her request for proposal document.

More education please, this will bring us closer to the 'professional' bit of 'professional business analyst'.

Read the article here. Comments or addidions welcome! (It's a wiki...)

Refurbished: Non-Functional Requirements and Levels of Specification

noreply@blogger.com (Rolf) — Tue, 28 Jul 2009 07:54:00 +0000

follow me on Twitter: @rolfgoetz

After an interesting and insightful discussion with Tom Gilb and Sven Biedermann about one of my latest PlanetProject articles I decided to work it over. It is a how-to for a good requirements hierarchy. A good requirements hierarchy is an important prerequisite to a more-conscious and logical design or architecture process. This is because real requirements drive design, not designs in requirements clothes. (Thanks Tom for yet another clarification!)

It seems, in trying to write as short as possible I was kind of swept away from good writing practice and got sloppy with wording. I also found out that there is a philosophical, hence essential difference in how the process of 'requirements decomposition' can be seen.

One school of thought describes requirements decomposition as a process to help us select and evaluate appropriate designs.
The other school describes requirements decomposition as being a form of the design process.

Personally, I subscribe to the second meaning, because of a belief of mine: mankind is very used to solution-thinking, but very new to problem-thinking (Darwin weights in). So most forms of thinking, including requirements decomposition, are outputs of a solution-finding or design process. Or, as Sven put it, requirements decompostion is a shortcut to designing, where 'designing' takes on the meaning suggested by number 1 above.

However, it can be very useful to assume there actually is an essential and clear destinction between requirements decomposition and design processes. The point here is: you need to define it that way, then all is well :-) I didn't define it properly, and thus gave rise to many arguments written and exchanged.

Anyway, I hope the article now sheds even more light on the the constant quarrel about so called 'nonfunctional requirements', i. e. what they are, what they are for, why they are so sparse in the common requirement specification documents.

Most requirement specification document I see these days have lots of required functions, and few (if any) requirements for other attributes of the system, like all the -illities. AND many analysts (including me from time to time) confuse non-functional with scalar. Read the article on PlanetProject to learn more.

Intro to Statistical Process Control (SPC)

noreply@blogger.com (Rolf) — Sun, 26 Jul 2009 10:44:00 +0000

In exploring the web about Deming stuff I stumbled upon this site from Steve Horn. It introduces Statistical Process Control (SPC).

There are a number of pages on various aspects, like

The articles are read quickly and understood easily. They are written to the point.

I'd like to add that in Deming's 14 Points, Point 3 needs a special interpretation for software or (IT) project people.

The point says:

3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

Deming was talking about (mass) production. In that field, "inspection" means roughly the same as "testing" in our profession.

In fact, inspections (of requirements, designs, code and test cases) are among the most effective activities you can do in software, for building quality into the product in the first place.

BTW, if you worry about your software development organisation NOT really testing their products, it is a very wise idea to first introduce a couple of inspection stages, for this is both more efficient (economic) and effective (less defects). It is also a sensible way to introduce learning.

Testing is about finding defects, Inspections are about pointing out systematic errors and give people a real chance for preventing them in the future.

Here's one quote from Steve I like in particular:

Confident people are often assumed to be knowledgeable. If you want to be confident the easiest way is to miss out the 'Study' phase (of the Plan-Do-Study-Act-Cycle) altogether and never question whether your ideas are really effective. This may make you confident but it will not make you right.

(words in brackets are mine)

Levels of Spec Principle, Non-Functional Requirements

noreply@blogger.com (Rolf) — Mon, 13 Jul 2009 06:49:00 +0000

Follow me on Twitter: @rolfgoetz

Just a quick remark: I added a grammar representation to the "levels of specification principle" on PlanetProject. For those of you who like precision.

If my boss sees this, he again will call me a "theorist." :-)

A Quest for Up-Front Quality

noreply@blogger.com (Rolf) — Fri, 03 Jul 2009 10:46:00 +0000

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.

History Repeating?, or A Case for Real QA

noreply@blogger.com (Rolf) — Mon, 01 Jun 2009 10:47:00 +0000

Jeff Patton of AgileProductDesign.com has an excellent article on Kanban Development. He does a great job in explaining the kanban idea, in relation to the main line of thinking in Agile. The article is about using a pull system rather than a push system like traditional (waterfall) development or agile development with estimation, specification and implementation of user stories.

Reading the first couple of sections got me thinking about another topic. Isn't this agile thing "history repeating"?

First of all, I'd like to question how common agile development really is. It's clear that the agile community talks a lot about agile (sic!), but what does the numbers tell us? I don't have any, so I'm speculating. Let's assume the percentage of agile developments is significant. (I don't want to argue against Agile, but I want to know if my time is spent right ;-)

Jeffs writes:

"Once you’ve shrunk your stories down, you end up with different problems. User story backlogs become bigger and more difficult to manage. (...) Prioritizing, managing, and planning with this sort of backlog can be a nasty experience. (...) Product owners are often asked to break down stories to a level where a single story becomes meaningless."

This reminds me so much of waterfall development, a line of thinking I spent the most of my professional career in, to be honest.

First, this sounds a lot like the initial point of any requirements management argument. You have so many requirements to manage, you need extra discipline, extra processes, and (of course ;-) an extra tool to do that. We saw (and see) these kind of arguments all over the place in waterfall projects. Second, estimation, a potentially risky view into the future, has always been THE problem in big bang developments. People try to predict minute detail, the prediction covering many months or even years. This is outside most people's capacity. Third and last, any single atomic requirement in a waterfall spec really IS meaningless. I hope we learn from the waterfall experience.

Jeff goes on:

"Shrinking stories forces earlier elaboration and decision-making."

Waterfall-like again, right?

If user stories get shrunk in order to fit in a time-box, there's another solution to the problem (besides larger development time-boxes, or using a pull system like Jeff has beautifully laid out): not make a user story the main planning item. How about "fraction of value delivered" instead, in per cent?

Jeff again:

"It’s difficult to fit thorough validation of the story into a short time-box as well. So, often testing slips into the time-box after. Which leaves the nasty problem of what to do with bugs which often get piped into a subsequent time-box."

This is nasty indeed, I know from personal experience. BTW, the same problem exists, but on the other side of the development time-box, if you need or want to thoroughly specify stories/features/requirements. Typical solution: you put it in the time-box BEFORE.

Let's again find a different solution using one of my favorite tools, the 5 Whys.

Why do we put testing in the next time box? Because it consumes too much time.
Why does it consume a lot of time? Because there is a significant number of defects to find and fix (and analyse and deploy and...), before we consider the product good enough for release.
Why is there a significant number of defects to be found with the testing stage? Because the product brings a significant number with it.
Why does the test-ready product have a significant number of "inherent" defects? Because we have not reduced them significantly them further upstream.
Why didn't we reduce it further upstream? Because we think testing is very effective in finding all kinds of defects, so testing alone (or along with very few other practices) is sufficient for high defect removal efficiency.

It is not. Period.

From an economic standpoint it is wise to do proper QA upstream, in order to arrive at all subsequent defect removal stages (including testing) with a smaller number of defects, hence with fewer testing hours needed. This works because defects are removed cheapest and fastest as close as possible to their origin.

What do I mean by proper upstream QA? Well, I've seen personally that inspections (on requirements/stories, design, code, and tests) deliver jaw-dropping results in terms of defects reduced and ROI. I'm sure there are a couple more, just ask you metrics guru of choice. The point is, see what really helps, by facts and numbers not opinions, and make a responsible decision.

Estimation with Use Cases: Deeper Thoughts

noreply@blogger.com (Rolf) — Fri, 22 May 2009 08:20:00 +0000

I came across a thought provoking white paper written by John Smith of Rational Software. It's on Estimation of effort based on Use Cases.

If you have ever tried estimation with use cases, you know that the various levels of decomposition encountered in the wild are troublesome. John does an excellent job in conceptualizing this problem.

The article seems to be from 1999, and I'm not sure whether John's ideas made it into the various estimation tools. For me, reading them brought a great deal of clarity in the levels-of-use-cases concept, so I think it's worth reading anyway.