1/30/2008

Islands of Expertise Can Get You Lost

You may be familiar with the following scenario. The embedded software development department has finally launched a large new system. The system obviously immediately gets new feature requests and other modification needs. During the initial development each developer has found a pet part in the overall system. When the improvements/modifications start it is intuitive to assign these smaller projects to a person whose area the change mostly concerns. In this approach we launch several, as many as there are developers, projects to run in parallel. This seems like a natural way to go.

While tempting at the first look, there are several problems in the above scenario. First is the customer’s role. It is difficult enough to get a functioning product owner for one project. Running multiple projects at the same time is ridiculously challenging. If we get one person to act as a customer proxy for all these small projects, this person soon becomes a bottleneck for all these projects. A project needs collaboration with the customer representative, and the sooner we get the feedback the better. The customer needs to be available at all times, and this is easier to achieve for one project at the time.

Second problem follows from the fact that it is rare that all these projects are completely independent. While we think that no one works on more than one project at the time, we actually have created a highly complex hidden multi-project environment. Typically one, or few, developers know something about everything. This means that people that are supposed to be working for their own project need to consult other projects continuously. These people become the bottlenecks for other projects, and their own project is impossible to estimate. As a net result we push all our projects to be more, and more, late without any control to what is going on.

Thirdly, assigning a developer to her previous pet part of the system further develops the specialization in a narrow part of the overall system, creating small islands of expertice. More and more closed silos of expertice emerge in the department. This is a high risk path as in an unfortunate case of loosing that person for one reason, or another we halt the development of that part for unpredictable period of time. Yes, I have heard that documentation should be there for allowing anyone to work on new part. Well, having been in the development game for nearly 15 years I kind of have lost faith to that approach. Maybe if the previous developers have focused their energy mainly on enabling future work –type of documentation. Never the less, safer path is to several developers to know the work.

The fourth problem is the lack of possibility to gain from the superior performance of true teams. Assigning each person to a single small project will at its best only accomplish the sum of each developer in development department. If we are successful in getting a true team to jell we can accomplish a lot higher performance that the sum of team members. This is important especially when the work we are engaged with gets more complex, and needs higher problem solving capability.

Changing to work in teams and in the same part of the system may feel difficult and weird at the beginning. Progress may also appear slow as most of the team members are unfamiliar with the parts of the system they need to work with. It may also take old school engineers by the surprise that they also need the softer skills, interaction and communication. It is crucial that collective ownership is still enforced. Teams have a remarkable capability in finding the ways to work. The practices supporting the work of team will merge rapidly. You don’t have to know everything to start working this way. Just follow the basics;

  1. do fast paced iterative development,
  2. have reflective retrospectives, and
  3. create open, learning-driven culture.

1/22/2008

Post leak

A friend told me that one of my drafts leaked into feed. It was probably an user error by yours truly. I apologize for your incovenience.

What comes to that draft, I hope to find time to finish writing about Preston Smith's latest book "Flexible Product Development" and agile in non-software development soon.

1/18/2008

Is It Death of Innovation - or Birth of Innovative Modifications

In "Your NPD portfolio may be harmful to your business health" (Cooper, 2005) presents data showing that true new product development has decreased by 43.7% between years 1990-2004. According the same article improvements and modifications to existing products has increased by 80.1% during the same time period.

September 2007 issue of Embedded System Design Journal revealed the results of reader's vote. Parts of the results add recent data to above observation. According to reader's vote the fraction of "new to the world; a new project from the scratch" compared to "an upgrade or improvement to an earlier or existing product" products has decreased from 48% to 39% in the past three years. 79% of those upgrades or improvements included "New or different software features".

Do not feel sad if it's been a while since you started to work on a brand new product. You are not alone. Working with new product seems to be getting more and more rare situation. If you get to do this, enjoy while you can. The data shows that there is a fair chance that you will be working with that product for a long time.

From the agile development point this data shows that it is ever more important to invest in automated regression test suite and refactored, clean, code. It is a safe bet that the software will be under heavy modification.

Very few of us have a chance to work in true high-tech fields which are generally understood to require innovation. Products developed are increasing in size and complexity. Building something from scratch based on a novel idea is most of the times in mega-project category. Mega-projects will take a long time, and thus include a mega-risk. This means that they are not so attractive to management. They do not get the funding so easily. However to me innovation means combining some, typically existing, technologies and ideas in a novel way to create some value to some one. By this definition adding ethernet connection to traditional product, and figuring out a valuable meaning for it, is innovation. We also need innovation in designing and improving the products so that they more easily adapt even more change. The need for innovation has not disappeared, it is just the nature of it that is shifting.

1/02/2008

New Year, New Tricks

There has been a quiet period again in writing. There's a reason, it's the same as always - I've been busy. Now it is new year, and we kind of think we can have a fresh start. We all know that this is not exactly going to work like that, but this time the new year happens to actually be interesting for me; I have a new employer. I still remained within the same organization, but I'm now working at completely different business unit. I'm still going to work with agile methods, probably more so than ever. Of course it is still embedded stuff, no question, but there are major changes:

I'm now engaged with much larger systems.
Application changed from lighting control to fire alarm system.
Resource budget has also increased quite a bit. Basic setup now contains:

Renesas H8
2M program flash
2M RAM
Commercial RTOS

As a result I'm learning a bunch of new stuff every day. I have a good feeling about this year.