One of the principles of agile development is self-organizing teams. Self-Organizing is a powerful process. But Self-Directed is not the same as Self-Organizing. On all but de-minimis projects, there is some external organization that is defining what Done looks like at the business capabilities level. In Scrum, this is the Product Owner, who is a member of the team. The PO is defined as:
The keeper of the requirements. The Product Owner provides the “single source of truth” for the Team regarding requirements and their planned order of implementation. In practice, the Product Owner is the interface between the business, the customers, and their product related needs on one side, and the Team on the other. The Product Owner buffers the Team from feature requests that come from many sources, and is the single point of contact for all questions about product. The PO maintains the Product Backlog, sets the schedule for releasing completed work to customers, and makes the final call as to whether implementations have the features and quality required for release.
But First a Statement of Principles
Without a set of principles, it's difficult to have a conversation about seeking a shared understanding of the problem and possible solutions for almost any topic. So for projects that spend other people's money in the presence of uncertainty - Governance is a means to establish those shared principles.
Governance is about Decision Rights. Specifying the decision rights and accoutability framework to encourage desirable behaviours in the developemnt and use of information technology and its supporting services. - IT Governance: How Top Performers Manage IT Decision Risght for Superier Results, Weill and Ross, Harvard Business School Proess.
In this Role (like all members of Agile teams, the PO is a role, not a position) the business value stream is conveyed from the business to the development team through the Product Roadmap and Release Plan. With the Team's full contribution to these artifacts, the Product Owner is Accountable to the business for delivering that value from the Scrum Team's outcomes. This is paradigm is usually found at the Enterprise level of software development. If you're working on a self-contained team, where the customer, PO, development team, and all supporting roles are all sitting at the same table, with a low ceremony around cost, schedule, or deliverable - you can stop reading now. You don't need governance, a Product Roadmap, and Release Plan. Just code and the person paying you will tell you what to do next.
But if you're on a team that gets its funding outside the team, then there is likely a governance process in place for how to spend that money. In this case, there are others who are Accountable for delivery working software. Not designing and developing the software. But those that have a business role for the use of that software to make money or provide a mandated service.This is the Team itself as a collective, but there is a separation of concerns on any non-trivial project as well. The UX/UI designers are Accountable for developing human factors and compliance -
In this governance paradigm, the Team itself is still a collective, but there is a separation of concerns on any non-trivial project as well. The UX/UI designers are Accountable for developing human factors and compliance - 508 Compliance for example - as well as compliance with the current or future UX/UI processes. The Database performance lead on the team is accountable for assuring the code and web service maintain the needed database performance. The Cyber Security lead is Accountable for assure the work of the developers adheres with NIST Cyber Security Framework when the system is public facing with controlled content. The Architect is accountable for assuring the code developed by the Team is compliant with the established Architecture. For example TOGAF or in the DOD, DODAF, or in some other domain's industry architectures. IEEE 1553 for real-time embedded system.
In these examples, there is usually some overarching governance process. If yu have no governance process, then none of this accountability discussion is applicable - do what you want not one cares. But if someone does care, usually the customer and those paying, then the notion of Accountability is the basis of project success.
The Responsibility Assignment Matrix
First, there are many alternatives to RACI, so this post is about a Principle and in this case a Practice and Process. On projects where governance is in place, a Responsibility Assignment Matrix (RAM) is a means of defining who is participating in what Role on the project. The RAM defines the single points of accountability for the project Leadership Team. These assignments start by identifying who is accountable for which project roles before the project starts. As the project matures, a delegation of these responsibilities down to the project team members using the RACI tool.
In an enterprise project here's an example of the locations for Accountability at the enterprise.
For agile programs, replace the PM with the PO and the diagram above remains the same. From this business governance process, we can build a RAM.
The RACI paradigm should actually start with Accountability - but ARCI which isn't as snappy. RACI provides the means to flow down responsibility from the Accountability. There cannot be multiple people Accountable, but there can be multiple people Responsible. Without a single point of integrative responsibility, it's not clear who gets to say what about the spending of other people's money. Again if you have no governance process, spend as you wish, do as you wish, no one care. But if there is governance, one place for developers to looks as to WHY governance is needed (rather than saying it's a waste) is Essentials of Managerial Finance, Besley and Brigham. This book explains why and how to manage other people's money when producing products or services in exchange for that money.
In The End
If it's your money or maybe your parents money, no one carees how you spend it. But if it's not your money - investors, relatives, the firms money, the stockholders money, the owners money - then some form of governance is likely needed. With this governance paradigm in place, some structure around who gets to decide how to spend that money is likely needed. With that need in place RACI (or its relatives) is a way to have a conversation about who, what, when, and why descioons can be made.
The governance process is based on 3 pillars:
- Ensure Benefits Realization - this is where the value management comes from
- Optimize Resources - this is where he cost management comes from
- Optimize Risks - this is the of removing the impediments of cost, schedule, and technical performance
This is the basis of Governance - It's About Decision Rights.
No need for decision rights? Spend away
[1] COBIT 5 ISACA's new Framework for IT Governance, Risk, and Security Auditing: An Overview
[2] The Role of ITIL in IT Governance: Leveraging IT Governance around IT Service Management
