The Champion, the Chief and the Manager

March 25, 2011

Successful product development projects are often characterized by having an enthusiastic product champion with solid domain knowledge, a visible and proud chief engineer, and a clever and supportive project manager. And of course, the most important thing, a group of exceptional developers. From an organizational point of view it makes sense to require that all projects should clearly identify these three roles:

The Champion: The product champion is a person that dreams about the product, has a vision about how it can be used and can answer questions about what is important and what is less important. The product champion is required to have a deep and solid domain knowledge and will often play the role of a customer proxy in the project. This position can only be held by a person that is deeply devoted and has a true passion for the product to be created. The product champion is the main interface between the project and the customer/users. (Sometimes also known as: Product Manager, Project Owner, Customer Proxy…)

The Chief: The chief engineer is a technical expert that has a vision of the complete solution and is always ready to defend this vision. At any time, the chief engineer should be able, and willing to stand up to proudly describe the solution and explain how everything fits together. He/she should feel responsible for technological decisions that the exceptional developers do, but also make sure that the solution is supporting the business strategy. The chief engineer is the main communication channel between this project and other projects. (Sometimes also known as: System Architect, Tech Lead, Shusa, …)

The Manager: The project manager is a person that leads a team to success by managing the resources on a project in an effective and sensible way. He/she will be responsible for actively discovering and removing impediments. The project manager is the main interface between the project and corporate management. (Sometimes also known as: Scrum Master, Team Leader, …)

Of course, for very small projects these three roles can be fulfilled by one person, but for projects of some size there should be three people filling these three roles: one product champion, one chief engineer and one project manager. These three people must work together as a team, form an allround defence (aka kringvern) around the project, while being available to the developers at any time. Their task is to “protect” and “promote” the project to the outside world so that the exceptional developers can focus on doing the job.

I believe that identifying these three roles is the only thing an organization needs to impose in order to increase the chance of success. Then the team of exceptional developers together with their servants decide everything else, including which methodology and technology to use.

1 Comment | agile, architecture, lean | Permalink
Posted by olvemaudal

Technical Debt

October 19, 2009

With borrowed money you can do something sooner than you might otherwise. If you are willing to incur technical debt you can release a product earlier than you might otherwise.

We all recognize these stereotypes: The sales team is willing to (and sometimes do) sell a product and cash in the money long before development is finished. While the engineers are reluctant to let go of their baby because there are always things that can be improved. A successful business needs engineers and salespeople that are willing to compromise and cooperate on this conflict of interest. Technical debt is a powerful metaphor that can be used to work on a compromise, especially when we are talking about software development.

Technical debt in a software project includes internal things that you choose not to do now, but will impede future development if left undone [1]. Examples of technical debt might be: We need to upgrade our compiler to a more recent version, but let us ship the product now and upgrade the compiler later. We do not properly understand how to implement this feature properly anyway, but this hack seems to make the customer happy for now. We have identified some dirty code that is slowing us down, but we choose to fix it in the next release instead. These are all examples of prudent and deliberate reasons [2] for taking on technical debt which can be compared to borrowing money for sensible housing. There are also less responsible ways of incurring technical debt though, perhaps caused by; lust, gluttony, greed, sloth, wrath, envy or pride. Examples might include: writing bad code, skipping analysis and design, over-engineering, résumé-driven development and so on. This kind of technical debt is more like unauthorized overdrafts and check bouncing, and is best avoided if you have a long-term vision for your product.

Like financial debt, a technical loan will incur interests, and if you are not able or willing to pay back the loan then you risk go into bankruptcy. The nice feature of software however is that paying back is usually both possible and comparatively cheap. While making effective and strategic decisions about what internal qualities to postpone you should keep track of them and write down an estimated effort needed to do it properly. This will give you an idea of how much you owe at any point in time. Then, after rushing a release out of the door, you can immediately start to pay back by doing the postponed things properly and get a flying start into the next release. Retrofitting stuff like this might appear to be more expensive than “doing it right the first time”, but since we are dealing with software it is often the right approach.

Perhaps the most powerful feature of the Technical Debt metaphor is that it communicates well between technical and non-technical people [3]. By quantifying the current technical debt in your product it should be possible to get management both interested and involved in the importance of controlling the debt burden.

References:
[1] www.c2.com
[2] martinfowler.com
[3] blogs.construx.com/blogs/stevemcc

UPDATE June 2010: At Smidig 2009 and XP2010 I presented a talk titled “Technical Debt is Good!” based on this material. Here are the slides (pdf) that I used in norwegian and english respectively.

4 Comments | agile | Tagged: , , , | Permalink
Posted by olvemaudal

Advanced Feedback-driven Development

March 26, 2009

For any non-trivial project: Software development should be considered a continuous learning process and a cooperative game of communication between professionals. Effective software development can be achieved through frequently repeating cycles of preparing, changing, observing, reflecting, and learning.

While the statement above is obvious to many, it is easy to miss the key points. For instance, you must make sure that you facilitate the learning process by implementing effective feedback mechanisms, do frequent iterations and be willing to re-plan the project continuously. You must also implement information radiators, enable osmotic communication, and get rid of things that hinders communication (yes, I am a fan of Alistair Cockburn). But first of all, you must assume that your developers are professionals that know what to do given a vision, trust and enough information. You should certainly not treat your developers as mere resources that need to be directed and told what to do and how to do it.

I am fortunate in that I work for a company that really gets it. I invite you to take a look at these slides. The key thing that this particular project do better than most is to do fast and automatic testing on all levels which gives developers confidence when making changes. Automatic feedback from all levels was a key success factor to get the first version out of the door, and now we have a workflow that will support further development for years. I think it make sense to describe what we do as advanced feedback-driven development – AFDD.

3 Comments | agile, lean | Tagged: , , , , | Permalink
Posted by olvemaudal

Daily Stand-up Meetings – Perhaps the third question should go first?

May 15, 2008

It is about 10 years since the first time I participated in a project using daily stand-up meeting. I was immediately fascinated. Since then I have always encouraged development teams to do daily stand-up meetings and to get rid of the traditional weekly status meeting.

Modern software development is about taking advantage of the fact that most often you have a group of very intelligent and capable individuals working together as a team. Given accurate information developers will know what is the right thing to do for the project to succeed. Given enough freedom (this is often forgotten) the developers will also be able to do the right thing. The daily stand-up meeting is an effective mechanism for making sure that everybody on the team have enough information to do the right thing.

There are a lot of formats for running the daily stand-up meeting (ref). But common for most of them is that everybody on the team should answer three questions in this particular order:

1. Did?
2. Will Do?
3. Impediments?

Sometimes I observe stand-up meetings where the third question is skipped. Nobody in the team mentions anything about problems, hindrance, obstacles or anything that impedes their work. It is very unlikely that this is true. In a software project there is always something that can be improved to speed up the team.

Actually, of the three questions, the third question is by far the most important in a daily stand-up meeting. The “Did?” and “Will do?” question is also important, but the information is often also available in the software repository and the task bord. Apart from the daily stand-up meeting, there is often no formal mechanism for making sure that everybody knows about what slows down the team.

Therefore, I propose that we should order the questions according to their importance. Allow me to suggest that in the daily stand-up meeting the team members should answer the following questions:

1. Any impediments in your way?
2. What are you working on today?
3. What have you finished since yesterday?

2 Comments | agile | Permalink
Posted by olvemaudal

Oslo XP Meetup: Lighting Talks

February 6, 2007

Yesterday I attended the Oslo XP Meetup. More than 20 people gathered at Scuba bar to watch a series of lightning talks – that is, maximum 10 minutes. There were seven sessions of very high quality – I really enjoyed all the presentations. Here is a quick summary of each presentation as I remember them:

Marius opened the evening with a talk about JavaScript. He claimed that it is probably the most important language around. It is used everywhere, and is currently driving the direction of how the web evolves. Maybe he has a point? Although it is hard do love a language which usually looks so ugly, he did point out several tricks to improve the quality of your javascript code.

Thomas talked about use cases and how they tend to grow into a massive pile of hard to maintain information. As an alternative he reported success from a project using Selenium to record scenarios and thereby reducing the need for some of the details in use cases. Thomas has also written a blog article about this subject.

Dagfinn, one of the authors of the PHP in Action book, presented some interesting ideas around Fake services. How to test an application without having to also run all the services that the application depends on. Is it high level mock objects we are talking about?

After the break, I did a 10 minutes presentation of TDD in CPP which is basically just Uncle Bob’s Bowling Game Kata converted to C++ and QUnit.

Trond had some amusing observations about the absurd mathematics behind the so-called risk matrix. Trying to categorize risks a matrix by estimating probability vs consequence gives some strange results if you try to actually do the maths. The basic idea is that you will see that the degree of probability does not really matter much in the end. A high consequence risk will always be red, while a low consequence risk will always be green.

Aslak presented some best practices about building software in agile projects. He called them “Build Patterns”, and it was about the need for having both a fast and slow build process, how to use a flag to focus the project team on a broken build, the need for a common check-in procedure for the developers.

Finally, Kjetil talked about three trends in the agile world. Even the Norwegian government is now asking for agile developers and projects, techniques from different methodologies are mixed together as they now can stand for themselves, and the word Agile is about to loose its meaning. The presentation triggered a few interesting discussions afterwards.

1 Comment | agile | Permalink
Posted by olvemaudal