Opening talk – Alistair Cockburn

The opening talk title was “Effective software development in the 21st century”. As promised by the title this session was packed with so many great insights, advices and ideas for me to be able to repeat them all. But some stuff did stick and I thought i should share.

Agile has grown beyond small organizations

Yes, this simple fact still comes as a surprise for people outside agile circles. However one must remember that originally Agile methodologies (mainly XP and Scrum) were created for such teams. A fact that some Agilists tend to forget. What is important that current methodologies, as used today, have grown, changed and adopted to all kind of projects and they are still growing. For example the trend in which more engineering practices are picked by organization doing Scrum might soon force the powers to be to finally include some of them in the “book of Scrum”. Yes who knows what the future of Scrum might be.

Software development as a cooperative game

A great metaphor the full details can be found here. In short, when looking at development as such a game we can say that:

1. Writing code can be viewed as a finite cooperative game with set targets, goals and an end.
2. Developing a product can be viewed as an infinite game in which the only true goal is to actually play the game hopefully as long as possible.
3. The process that we choose is the actual “Strategy” by which we choose to play the game.

so where that leaves us?

With two (actually more) important observations. First, like any other complex game you don’t find yourself in the same state twice,and a single winning strategy does not exists. In fact, when talking about strategies, the terms right or wrong does not apply, strategies are either weak or strong. What’s more important is that one can and should pick different strategies for different situation. A process which works for a startup company probably wont work as well for a big team. Second, the different in nature between writing code and developing a product might explain a very basic developing dilemma. On one end we want to ‘win’ the game of writing code, which has specific goals and a known end date. On the other side we must remember that from a product POV the game is infinite (hopefully) and we always want to be prepared fro the next “round’. Meaning that its not enough to write working software satisfying current needs. The quality of the written code must be kept good enough to support future development. And those two needs sometimes pull us in different directions

Developing Software is a Craft

its not the first time i hear this, there’s an ongoing growing movement of developers calling all to start treating writing software as a “profession”. Alistair however summed it up quite well

“A developer must relearn how to program every few years”

and indeed software development techniques are continuously changing. When I started out my first programming job involved writing code in C/functional C++ for an embedded system. A couple of years later I had to relearn how to program when i switched to develop using object oriented C++. A few year passed and I was introduce to Agile, which came with practices like TDD, pair programming. So again I had to relearn the skills of writing software, and last a couple of years ago, I started to developing under .NET which again made me relearn much of my skills. Bottom line I feel all these relearning is the only way to keep up with the profession of writing software.

Decisions as unit of inventory

The last part of the session discussed the idea that actually software development is mostly about making decisions, and that the speed by which we transfer those ideas between minds is what actually dictates the productivity of a development team. The best way to speed up development is by locating and removing all barriers which slows down this flow of ideas. For example the reason why distributed team are less efficient than collocated teams are that they communicate using inferior channels which of course reduce the efficiency in which we can transfer ideas.

The nice thing about using this analogy, is that the entire development cycle can now be reduced to a manufacturing line and all the appropriate theoretical knowledge can now be drawn upon. Specifically by using decisions as unit of inventory we can now map the stations along the development “line” and try to locate bottlenecks by recognizing the places in which decision are being delayed.

Summary

There was much more going in the session, in fact I’m sure that in order to grock it all ill need to listen to it at least a few more times. I do hope however that I managed to convey at least some of that knowledge.

Next post ScrumBan (how to use Kanban in Scrum)

Posted in: Events,Scrum. Random Thoughts