Values and beliefs

MÃ¥rten Gustafson, Stockholm 15th of June 2015


I don't believe software development should end. If software is in use, being sold or supported I believe there should be software development work taking place on that software. As a general principle I believe there should be little difference from the first day and all days until its decommissioning. The size of a software system as well as the team that owns and operates it will vary over time, as will the technologies used and the principles adhered to.

Holistic ownership

A team should be self-sufficient when it comes to the bare necessities of its work. A combination of being cross-functional, owning the operational aspects, being on-call as well as providing some notion of end-user support. Cross-functional is to cover the technical necessities of getting work done. Owning the operational aspect implies being responsible for operations, but not necessarily infrastructure, in which I include being on-call for the production system as well as providing end-user support in whatever fashion that makes sense for the given software.

Limit detailed planning

I believe much of the power and potential in software stems from the unknown. I think that all software should, at its core, be warranted by some differentiating factor. In the vortex of new and old technology coupled with our belief in a better way of solving a specific problem lies a lot of unknowns. To effectively address these unknowns and produce working software we need to be innovative and creative. Limiting detailed planning is a way of freeing up time and increasing ambiguity. Giving a team time and ambiguity provides them with an environment better tailored for creativity and innovation.

Externally influenced, high-level, roadmaps

A possible drawback of being self-sufficient and not having much detailed planning is that one can both get caught up in technical lily gilding as well as loose track of the bigger picture. To parry this a few team members need to have a knack for technical strategy, solution design and architecture in order to keep the mere technicalities together on a medium to long term basis. However I strongly believe there must also be a high-level direction, vision if you will, which is, to some degree, set from outside the team, preferably together with the team but not by the team alone. This works together with the limited detailed planning to nudge the team in the right direction while not being so detailed or dictating that it stifles creativity.