Comparing Production to Software Development

I regularly come across people comparing the (mature and structured) production of industrial goods (mostly cars) to the (immature and chaotic) discipline of software development (or actually software engineering) .

I have to admit that I am not a fan of those kind of comparisons. Particular the analogy between software development and industrial production is falling short, that is apples vs. pears. If at all the comparison should be made between the design of industrial products (say cars) and software. Like software development the process of designing a new car is not as straight forward as the later production of the thing.

I do not want to belittle the challenges and performances of designing a new car by any means. Having said that, I think that the design analogy falls short also because of the complexity involved. The requirements of physical world products is constraint by a lot of facts. A car needs to fit for a human beeing, needs to be steerable and needs to fullfil some speed and security requirements. Within those limitations the designers can build the thing around the remaining degrees of freedom.

Software on the other hand has a lot more degrees of freedom (that is what soft means) aka a higher complexity (the same holds true for other “mental” products like e.g. art and movies). In a lot of domains the truth is even worst: requirements are not clear in the beginning (which can have a couple of reasons).

So what is my point here? Well, analogies do help us to capture certain concepts and building up a paradigm. However, you should clearly define the limitations and boundaries of a analogy. Further you could try to apply aspects of one domain to another, but you should always respect the character of the domain at hand (software in my case).

There are a lot of concepts and strategies out there that allow us to handle this complexity, but seeing software development as a industrial (production) process will not work…

InfoQ Interview on Lean

The guys over at InfoQ have an interview (video) with Mary and Tom Poppendieck on Lean online.

The explain the heritage of Lean as well as the basic principals applied to software development in general and product management in particular. They explain some of the seven principles:

  1. eliminate waste
  2. amplify learning
  3. delay commitment
  4. deliver fast
  5. build integrity (in the product)
  6. engage the intelligence of the people involved
  7. optimise the whole system

They discuss some of those principles in more detail (my favourite one is the discussion on late decisions). They are positioning Lean to Scrum, RUP and CMM. They also have a open discussion on the constraints of applying Lean principles (I particularly liked the statement about the level you have to aim for and the discussion about Lean under contract).

You might also want to check out the Poppendieck’s website.

Information diversity

While commuting this morning I listened to the latest episode of TWiT. In there the guys had a discussion about news papers vs. online news (around the 1h mark). Wil Harris brought up a very interesting point: Are tailored/personalised information (feeds) harmful? One “feature” of an old fashioned paper newspaper is that you get information that you are not interested in in the first place instead of just getting your usual food.

On one hand there is more information that ever before these days, so you have to stay focused and try to get the information you are interested in without having to spend much time searching for it. Internet, customised feeds and portals are good means of delivering these kind of information needs.

On the other hand it is quite essential for us to look beyond one’s own nose from time to time. To get new perspectives, to think out of the box, to build new analogies. IMHO this is the essence to progress and develop. You can do that by browsing a new paper, reading something totally different on the internet or zapping around in television a bit. Doing this for a couple of minutes each day helps to broaden my view.

Just staying with your primary interest doesn’t bring you further…

Done or not done: that is the question

“How far are you with this task?”. This question is quickly asked and chances that you get an answer like “we are 80% done” are very high.

Does such an answer really makes sense? How do humans assess the progress of a task? According to the Pareto principle we might need 80% of the effort to fulfill the last 20% of the task, but most likely we perceive this differently (more linear). So even if we have the best intentions, the human brain is being tricked here.

So what are the options?

There are a couple of ways to report the completion of a task (see e.g. Rob Thomsett: Radical Project Management):

  • binary (0-100): Either a task is finished or considered as not yet started
  • binary (50-100): As soon as a task has been started, it is considered as 50% done
  • linear: If a task is scheduled to take 10 days and 8 have been spend on that task it is 80% done. This is the Microsoft Project way
  • subjective: Most often used in ad hoc reporting. The team is asked and tells their gut feeling (more or less)

The advantage of the binary strategies is that you are not tricked by the nonlinearity of things. There is no false security of having plenty of time.

And there is another positive effect: Designing tasks to be suitable for binary evaluation. By the team being aware that a task is either done or not, they will most likely start to design tasks that are actually suited for this approach: Not too big but still one entity. However it is very critical to resist the tendency of making tasks too small (to get them done quickly). Unfortunately there is no rule of thumb of how long a “standard” task should be (do not trust anybody who states otherwise).

There is another very important aspect to this: Defining the task in general and the criteria of completion in particular is key. As said above, a task needs to be a kind of atomic effort. You should not confuse this with an artifact or deliverable. A task can be a part of an unfinished deliverable but needs to have clear completion criteria.

Binary reporting also prevents micro management. The team will report the task done, when it is done. Asking beforehand does not make much sense as the binary answer is not done yet (either 0% or 50%). Having said this, it is the responsibility of the person or team that owns the task to escalate in time when they see a risk of not being able to complete the task in time.

Whatever you do, always remember to keep a buffer in project planning… But this might be another post.

Update 2007-03-01:  Johanna Rothman has a post on this topic: There is not such a thing as Percent complete.

Effectiveness of Communication

Why thinking about this? Thing is that work tends to be more and more distributed and the temptation to use the modern communication methods like email (in one form or another) and instant messaging is bigger than ever.

Before going any deeper into this, let me first admit that I do not have an scientific data/evidence or other sound foundations for my theories. All of this comes from my own observations and the writings of others (namely Alistair Cockburn).

So, what is the most effective way to communicate? IMHO the best way to communicate (two persons up to small teams (about seven people)) is a vis a vis scenario with flip chart or white board. This way you can talk, listen, sketch, see, feel, smell. You see the reactions (say emotions) of people, you can even stop in the middle of a sentence if people do not react as expected.

The more I do in terms of (project) management the more I value this form of communication. My feeling is that the effectiveness (and risk) of communication is dropping quite significantly if you go from live to video conference to telephone conference to instant messaging to email.

Why is this? In the end of the day, communication is the interaction between human beings. We have a long history of implicit knowledge in communicating to each other vis a vis. This is what we are conditioned to since a couple of 1000 years…. We use a lot of our senses.

With video conferencing you loose smell (let alone that most people are feeling uncomfortable in front of a camera and “act” unnaturally).

With telephone you loose seeing emotions and reactions.

With instant messaging you loose hearing emotions.

With email you loose interactivity.

So, what’s left? A lot of room for misunderstandings?!

Please do not get me wrong here. I do like the modern means of communication. Sometimes it is so much easier to write something in a brief email instead of having to talk to someone extensively, it is even very essential if you want to document things. But I do think that you should choose the best possible (say effective) way of communication if the topic at hand really matters to you.

Dimensions of a project

There are a couple of factors that define a project. Usually you have three or four of them. So what are those?

* Scope
* Cost
* Time(line)
* Quality

Why are they key? They are highly coupled (think rubber bands) and modifying one of them changes the other dimensions as well.

You say this is common sense? IMHO you are right.

However, if you try to communicate changes in one dimensions (aka change requests) and mention the consequences for the others, even seasoned project managers seem to forget this…

Welcome to YAB

Welcome to my new blog. Isn’t that what the world needed? Some other random thoughts from an other guy looking for his 15 minutes? Anyway – and even if I am definitely no early adopter her – I intend to bother me and you from time to time with some blatter.

However, do not expect entries every day, it will be more now and then style. So let’s see how this will work out…

BTW and sure you already guessed that: YAB is yet another blog.