- Accountability in SCRUM Blog

---

One of the essential concepts of SCRUM is the delegation of autonomy and decisiveness to the development team. In the case of SCRUM, specifically, as one example of agile methodology, all the development related operational and, executive decisions are transferred from the management team to the development team. Interestingly this transfer of autonomy does not transfer accountability the same way. I do not know any development team that, with the acquisition of collective decision-making, also took collectively took responsibility for the consequences of potential failures related to the management, implementation and maintenance of IT projects.

No responsibility can be imposed, as it can only be taken. Still, I don't know of a company where any team member has consciously signed up for personal or financial responsibility for the effects or consequences of the development work. In SCRUM all responsibility in front of customers, management and most importantly - finance department - remains one of the functions attributed to a product owner, i.e. a specific leader, manager, manager or director within IT department. Yet all decision making remains with the collective body of the development team who is not accountable for making mistakes or even misdirecting the development by creating the technical debt or gold plating solutions beyond the financial reason.

At the same time, the very concept of SCRUM assumes that none of the software developers is personally responsible for the software development outcomes in front of clients and the management board. Instead, management board takes responsibility for any results of the development team's work, even if it remains impossible for managers to justify choices made by developers. Collective autonomy and no real accountability means developers are responsible for making critical decisions regarding ongoing software development and managers are just accountable for development outcomes actions, without a say in making decisions, simply because they are not part of the development team. Therefore, SCRUM assumes full responsibility left on the management's role, without anyone being responsible for executing the process itself.

In its, essence SCRUM quickly turns into a process of transferring all benefits to the development team with no transfer of the balance of power or any related business risks. In a broader sense, SCRUM may be understood as only an illusory facade of the management system where in fact, it's just a development methodology with no concept of management attached. Implementation of bare SCRUM process without management controls quickly turns into loss of management control over the developers and the product. As a famous saying goes: any autonomy without accountability always leads to anarchy. In practice, it is common to invent roles of programme or project managers, technical leaders or chief technology officers - only to have a person accountable when things go wrong, even though they never have a say in what is being developed and how it is being developed in the first place.

SCRUM as a methodology with no management controls, only smears responsibility among the mythical concept of "a team" and therefore, it requires healthy management controls to avoid chaos. No real business operates by members of departments organising themselves in steering committees and voting on how to progress with work and evaluating their progress internally. Effectively, companies cannot accept that no individual takes accountability and, ultimately, no one takes responsibility for the development team's actions and results. The methodology that mimics government practices even creates "steering committees" to estimate and retrospect development work - effectively shielding the development teams from any business pressures on getting things done quickly and making the team the only body to evaluate their work. Again different political systems taught us everything about organisations that only internally plan and assess themselves. We should not recreate political systems within companies as we already know well that it ultimately leads to stalemate and frustration.

For the SCRUM or any other software development methodology to work, the company needs to have a full commitment from all stakeholders. The full commitment needs to mean business. It has to have bounding value, as much as any other agreement. Any binding agreement from the development team is like a promise to deliver sprint results no matter what - because promises should never change under changing circumstances. The very reason a company or individual enters a binding contract is to shield themselves from the risks of changing circumstances. The exact reason for the sprints to be implemented in some period of time is to allow the development team to apply all the necessary measures to self-correct if the development goes wrong (or slow) before the end of each sprint. The contract should state that at the end, the result may not be perfect, but it always must be delivered.