Give Kelly Waters a Hand

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

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

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.

1. One school of thought describes requirements decomposition as a process to help us select and evaluate appropriate designs.
2. 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)

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

• Theory of Knowledge
  
• Knowledge about Variation
  
• Deming's Fourteen Points for Management
  

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

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

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.