Single-point, Multi-point

There are many things that are different in the “new world of development” as opposed to the way it was in “the old”. One of the more subtle, but perhaps fundamental is the way that decisions and communication has switched characteristics.

When a developer was developing code “in the old days” he or she had a task defined by some designer, project manager or architect. This was usually the only point of communication that was available to discuss the features. But frequently sales persons or other customer contacts would show up at the developers desk and ask about some features, estimates or changes that could be made “since doing them at the same time would not cost anything”. This single-point communication, multi-point control has been one of the primary sources for unpredictability in the “old” way. Although detailed plans was made and project managers tried everything possible to keep them, the urge from business to rush and push unplanned things into the workload of development ensured failure to meet the plans, no matter how strict control was applied.

In agile development one of the most important techniques is to enable developers to communicate with stakeholders of various kinds, users, customers, business people. This multi-point communication is essential to ensure that valuable features are developed. On the other hand decisions are focused around the product owner and his power of prioritization. This is exactly enough to work as a single point of decision. In conjuction with the multi-point communication it is “right-sized” decisions.

So removing the single-point communication, multi-point control and replacing it with single-point control, multi-point communication gives us controlled flow of tasks and predictability of development.

“Agila Sverige” a success!

We’re back from the first real agile conference in Sweden, “Agila Sverige 2008”. There have been a couple of other conferences, of course. Some of them with Responsive as sponsors. But this was a conference arranged by the non-profit organisation “Agile Sweden”. It was mimicing the format from “Smidig 2007″,  lightning talks before lunch, and open space in the afternoon.

Andreas and me had two talks each. They seemed all to be well received. Both of my talks where listed on more than one sticky note voting for best lightning talk. So that was a personal success.

It was also a success as a conference. It was so full of inspiring talks, interesting people to talk to, some of them whom I only had had mailing list exchanges with. Nice to meet them face to face. Many of them also people on the “Computer Sweden Top List of Developers”, numbers 12, 30, 44, 49, 51, 53, so sometimes even CS is right…

But the big success was that everybody contributed. Thank you everybody!

My biggest insight was that “10 minutes is enough, you can say everything you want in 10 minutes”. So maybe Agile 2008 in Toronto will be a bore, all those 90 minute ramblings…

Agile isn’t about trust…

Many people have said that “Agile is all about trust”, and I have sort of agreed. Up till recently. A collegue and me had a lunch conversation with Mary Poppendieck at XP2006 in Oulu. Mary talked a lot about the relation Toyota had built with their sub-contractors, how it was all trust, aligning sub-contractors goals with Toyotas and not pressuring the sub-contractors to minimize their prices, no matter what. Instead Toyota promised that if the sub-contractor could not meet the required price levels, Toyota would put people and knowledge into helping the sub-contractor reach that level. And, I suppose, the sub-contractor had similarly promised to make any changes to their operation to reach the level.

Such trust is of course the goal also of agile practices, responsible development and, of course, any other type of business relation. But us agile people can not start such a relation by saying “You’ll have to trust me…”

The software industry has burned those bridges far too many times already. “Well, we’ll try a more structured way to programming…”, “Ok, so that did not work, but trust us now, we have come up with this this object orientation…”, “Hmm, we understand that programming isn’t everything, so trust on this process and quality thing we’ve got going…” No, it is us agile people that have to interface with the “traditional world” first. They will never come to us just because we say that we can be trusted. We must find ways to prove, in real world combat, that there finally are ways to build a trust relation with a developing organisation.