Teams in the driving seat

Two weeks ago, InfoQ published our article about many experiences with Scrum at Port of Rotterdam. Several people contacted me afterwards with questions and one of them was an IT manager in a large organisation. He made a very short and interesting summary:

So, developers / teams are in the driving seat!

This characterisation is pretty good and can be used as a test for knowing how Agile your teams really are.


Very often, “being Agile” is confused with having teams following some set of practices “correctly”. That could be XP practices, Scrum practices (3 roles, 4 meetings), or something else.

“Teams in the driving seat” means that in a large organisation, information and artefacts are pulled instead of pushed. In a big enterprise, business has some need, which is usually pushed to IT management or product owner, translated by (business) analysts, pushed to Agile teams, which deliver a product in increments.

In case of really effective Agile teams, the need is much more pulled than pushed. The business still pushes the high level idea, with its very limited definition. After this, the initiative is taken over by teams. This switch may happen with a statement from the product owner:

My need is ….. Please enlighten me if this is sensible and what more you need from me so you can pick this up.

From this moment on, teams are in the driving seat and request or pull everything they need in order to deliver value. They are the ones actually deciding which information needs to be gathered, questions answered, artefacts delivered, process followed, and so on. They may request assistance from domain experts, BA’s or architects.

For large organisations with strict processes where first architects and business analysts are involved, direction actually set by IT people instead of business, different levels of management approval is needed, this is a major change in behaviour.

So, next time you hear someone telling you about their Agile teams, ask them who is actually driving the car and who is giving directions.

Technical debt metaphor is wrong

Martin Fowler has an explanation of technical debt metaphor as originally defined by Ward Cunningham. Many have misunderstood this metaphor. Interestingly, even Fowler gives an explanation, which fits the metaphor, but not explanation by Ward Cunningham. Cunningham even warns audience to not mistake this metaphor with intentionally creating unwanted design or a mess. Cunningham does not believe in “dirty way of doing things” as explained by Fowler, just to fix them later on. Fowler mentions deadlines as a major reason for quick and dirty. I believe that deadlines themselves are the actual problems, and therefore not a good reason.

debt-free Continue reading

Continuous Architecting & DevOps

A lot is improved since Agile Manifesto. Still, one of the major complaints from non-Agile community is architecture and long term quality. The usual statement is that Agile people don’t care about architecture.

The price of short cycled incremental and iterative delivery of business value is paid with low long term quality and a mess in overall corporate IT landscape.

There is some truth in this, and there is a solution – already applied in corporate world- which does not only remove this argument against Agile methodologies, but delivers a better long term perspective than we ever had before.


Continue reading

Corporate world needs high quality Scrambled Eggs

Hong Kong is a culinary paradise. You can eat here almost anything, the quality is great, and the price is low. Major difference with European restaurants is the perception of service. In Europe we are accustomed to long evenings in restaurant with several courses, about half an hour between each course, a lots of wine, beer, or coffee at the end. Perception of service is about personnel being polite, knowledgeable, sociable. Also comfy chairs and tables, with enough space in between. Slow service is ok, even integral part of having relaxing evening, as long as it is not excessive. We don’t mind paying hefty price, but we also usually prefer eating at home because of it.

In Hong Kong, on other hand, perception of service is almost opposite. First and foremost, Hongkongers expect speed and food quality. Eating in restaurant saves time. Everything else seems secondary, as long as we are not talking about high-profile, more western-style type of restaurant.

An extreme example is Australia Dairy Company restaurant. It is a fast-paced, authentic place – more than 30 years old – where you can have very tasty scrambled eggs with toast! There seem to be a permanent row of people standing in front.

Australia_Dairy_Company_outlook Continue reading

How to make software architecture decisions?

Today, a friend of mine asked me this question. We both know how companies usually make architectural decisions, but how Agile teams (should) make significant architectural decisions is less obvious. A difficulty with this question is that answer has many perspectives: one could talk about business need, technology choices, documentation, who is involved in decision making, how they actually do it, what kind of meetings, etc.


Continue reading