Accountability on Agile Software Development Projects in the Presence of Governance

One of the principles of Agile development is?self-organizing teams.?Self-organizing is a powerful process. But Self-Directed is different from Self-Organizing. On all but de-minimis projects, some external organization defines what Done looks like in Measures of Effectiveness and Measures of Performance to deliver the business capabilities needed to accomplish the Mission or fulfill the Strategy. In Scrum, this is the Product Owner (PO), taking inputs from the Stakeholders.

The Product Owner 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

With a set of principles, it's easier to converse 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 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 sit 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 a Release Plan. Just code; 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, others are Accountable for the delivery of working software. Need to design and develop the software. But those with a business role in using 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 - and 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 ensuring the work of the developers adheres to the 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, in the DOD, DODAF, or some other domain's industry architectures. IEEE 1553 for real-time embedded system.

In these examples, there is usually some overarching governance process. If you have no governance process, then this accountability discussion is not applicable - do what you want. No 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) defines 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; 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 could be more snappy. RACI provides the means to?flow down?responsibility from Accountability. There cannot be multiple people Accountable, but there can be multiple people Responsible. With a single point of integrative responsibility, it's clear who gets to say what about spending other people's money. Again, if you have no governance process, spend as you wish, do as you wish, and no one cares. But if there is governance, one place for developers to look 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.?

Project Governance Using the Program Management Office

Lynda Bourne has a post on?Project Governance . She suggests some processes for good governance and references some papers on the topic. Governance is one of the roles of the Program Management Office. Here are the 4 paradigms for the PMO, the details of the 4 paradigms, and the value proposition of the PMO.

The Microeconomics of a Project-Driven Organization, Again Traditional or Agile

The notion that we can ignore - many times willfully - the microeconomics of decision-making is common in some development domains. Any?project-driven?paradigm has many elements, each interacting with each in random ways, in nonlinear ways, in ways we may not be able to understand when the organization's maturity still needs to be developed to a level needed to?manage in the presence of uncertainty.

So When We Say Project - Traditional or Agile Project, What Do We Mean?

The term project has an official meaning in many domains. Work that has a finite duration is a good start. But then, what is finite? Work that makes a change to an external condition. But what does the change mean, and what is external? In most definitions, operations and maintenance are only sometimes budgeted as projects. There are accounting rules that describe projects as well. Once we land on an operational definition of the project, here's a notional picture of the range of projects.

When we hear a suggestion about any process for project management, we need first to establish a domain and a context in that domain to test the idea.?

My favorite questionable conjecture is that we can make decisions about spending other people's money without estimating the outcomes of those decisions. Making decisions about an uncertain future is the basis of Microeconomics.

One framework for making decisions in the presence of uncertainty is Organizational Governance. Without establishing a governance framework, ranging from one like that below to No governance, DO IT, it's difficult to have a meaningful conversation about the applicability of any project management process.

So when we hear a new and counterintuitive suggestion, start by asking?In What Governance Model Do You Think This Idea Might Be?Applicable?

Connecting all the Moving Parts is Dependent on the Domain and Context

We need a domain and context before deciding how to apply the governance processes. A spectrum of domains and contexts exists for developing software with agile processes. So don't let anyone sell you a solution before you know what the problem is

Then, the process steps in that domain and context can be chosen. Here's an example on the right end of the spectrum in our domain of integrating Program Performance Management with Agile Software Development

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 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

Putting the Manifesto to Work in a Non-De Mimimus Domain Guided by Governance

The naivety of the Agile Manifesto starts in the absence of a Domain and Context. Here's how that Manifesto is applied in our domain of Software Intensive System of Systems on a program with a fixed launch date (you can only fly to Mars in the 3-week window every 27 months), a not-to-exceed budget, and mandatory capabilities to accomplish the mission

1. Individuals and Interactions over Processes and Tools

The first value in the Agile Manifesto is "Individuals and interactions over processes and tools."

Valuing people more highly than processes or tools is easy to understand because people respond to business needs and drive the development process.

If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs.

Communication is an example of the difference between valuing individuals versus process.

In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.

2. Working Products over Comprehensive Documentation

Historically, time is spent documenting the product for development and ultimate delivery.

Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals are required for each.

The list was extensive and was a cause for the long delays in development.

Agile does not eliminate documentation but streamlines it in a form that gives the developer what is needed to do the work without the minutiae until that information is required.

Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.

The Agile Manifesto values documentation, but it values working software more.

3. Customer Collaboration over Contract Negotiation

Negotiation is when the customer and the product manager work out the delivery details, with points where the details may be renegotiated.

Collaboration is a different creature entirely.

With the development of traditional models, customers negotiate the requirements for the product, often in detail, before any work starts.

This meant the customer was involved in the process of development before development began and after it was completed, but not during the process.

The Agile Manifesto describes an engaged customer who collaborates throughout the development process.

This makes it far easier for developers to meet the customer's needs.

Agile methods may include the customer at intervals for periodic demos. Still, a project could just as easily have an end-user as a daily part of the team and attend all meetings, ensuring the product meets the customer's business needs.

4. Responding to Change over Following a Plan

Traditional projects regard change as an expense that is to be avoided.

The intention was to develop detailed, elaborate plans with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of dependencies on delivering in a particular order so that the team can work on the next piece of the puzzle.

The Heart of Agile Projects in any Business or Technical Domain

• Collaborate ? with all participants.
• Deliver ? Value on periodic boundaries.
• Reflect ? on progress, processes, and activities in a closed-loop manner.
• Improve ? through corrective and preventive actions.

These four processes, repeatedly applied on fine-grained boundaries, are the foundation of not only Agile Development and its Project Management but all good project management Principles, Processes, and Practices in any domain.

These are the foundation for answering the question of any approach to developing a software-based solution:

How long we you willing to wait before you find out you are late?

While collaboration is vital to all project work, it is a critical success factor in Agile projects.

This is the case since there are rarely any formal Project Performance Management Process Directives (PPMPD) stating how, when, and why each process step should be applied to the project.

The four actions defined here are also found in good traditional projects

One test of any set of principles to confirm they are not just platitudes is to?invert?the statement.

• We don't want to not to encourage collaboration.
• We don't focus on delivering anything.
• We never reflect on what we did. We move on and hope nobody notices what a mess we left behind.
• We have no intention of improving anything. We like it the way it is.

Those would be nonsense. In one sense, these four manifesto statements are platitudes of any good project management process.

In another sense, they are reminders of what good management is.

And we all know how hard it is to perform good project management processes.

More Agile Content

• Paradigm pf Managing Agile Development Project
• Agile Project Management and Earned Value Management
• The 12 Principles of the Agile Manifesto and Their Inversion
• Thought for the Day - Manifesto of Agile Development in Federal Acquisition

[1] COBIT ISACA's 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