There is a subtle, yet significant dilemma when operating Agile at Scale in the public sector.
On one side, there is the ‘collective ownership’ principle in Agile ways of working which states that the ‘Team‘ succeeds and learns collectively. On the other side, public sector administration requires a ‘statutory accountability’ – which is a definite need for clear & accountable lines of responsibility concerning budget, timeline, and results.
While these two approaches may coexist without conflict, they do require a certain degree of calibration.
Often, in many established Agile at scale models we notice the emergence of gray areas, where well-intentioned Agile teams feel responsible for taking ownership of the effort, but the organization (read Leadership) struggles to pinpoint the accountability for the outcome.
To mature our operating models in public sector IT organizations, we must develop a view that allows Agile teams to operate autonomously, while meeting the stringent requirements of public governance.
Below are three ideas to be considered for successfully bridging this gap of accountability and autonomy effectively, to maximize performance.
1. Elevate ‘Definition of Done’ to ‘Definition of Evidence’
Traditional governance measures in the public sector often relies on progress reports (for example, “We are 85% complete..”). However, in a complex environment, percentage-based estimates may often be subjective and at times, overly optimistic.
In order to better support our Agile teams, we can transition from an activity-based to evidence-based governance. This is consistent with the Agile tenet of ‘empiricism’.
As a leader – Instead of asking, “How is the work progressing?”, we can structure our stage gates to ask, “What observable artifact was created? And does that meet the acceptance criteria“.
Example:
- Subjective response provided : “The testing is underway.“
- Objective response expected : “The test summary report is generated and submitted.“
By establishing a definition of done that requires tangible artifacts as output, we provide the Agile team with protection against uncertainty. In-effect we are removing the inadvertent pressure of making them create a compelling story about their work, and replacing it with the confidence that comes from enabling them to show their work.
2. Differentiating between ‘Delivery’ and ‘Orchestration’
One of the challenges in any Agile at scale model is the inter-dependencies between various departments/ agencies, vendors, and legacy systems. These relationships (or their outcomes) are not always predictable.
When an Agile team is unable to move forward (blocked) due to an external factor, accountability becomes fuzzy. To help alleviate this, we can make a distinction between who is responsible for quality of the delivery (work) and who is accountable for the orchestration of flow of the work, in terms of stewardship.
In this approach:
- The Agile team should retain the ownership of delivery quality (the features, code, testing etc.).
- Various integration roles (Like for example: Portfolio Orchestrator/ STEs [Solution Train Engineers], Product Orchestrator/RTEs [Release Train Engineers] and Scrum Masters; other applicable roles that may exist like System Architects) retain ownership of orchestration flow (agency-to-agency dependencies, risks, procurement etc.).
This is not about assigning fault; it is about providing adequate level of support. If and when a dependency fails to deliver on-time, it should not fall on the developer to resolve the issue. The developer in Agile team should ideally be able to continue delivering value without being worried about dependencies. This is an orchestration challenge that requires senior leadership support. By intentionally making this differentiation, we are empowering the Agile teams to focus on what they do best: build value.
3. Transitioning from ‘Escalations’ to ‘Systemic Signals’
In many organizational cultures, escalating an issue feels confrontational — as if the Agile team is admitting that they could not resolve the issue. This often creates a resistance to reporting issues early on.
We can redefine this by using the lean concept of ‘Flow signalling’.
Rather than counting on an individual to raise a red flag when an issue strikes, we can define systemic signals leading to automatic actions. For example, if a dependency exceeds (ages beyond) a certain time frame, it would trigger an automatic review by the portfolio tier.
This approach takes the personal aspect out of the issue. There is no way to say that the team is complaining; it is simply the system functioning exactly as designed to bring additional focused resources to the bottleneck. This shifts the entire dynamic from ‘reporting a problem’ to ‘requesting/inviting a solution’.
The Road ahead
Enforcing accountability in an Agile at scale environment (especially in public sector) is not about implementing tighter controls or more rigidity. It is about providing greater transparency / increased visibility.
By implementing an objective evidence based decision making process, clarifying stewardship roles and systematizing how roadblocks are addressed, we can honor the spirit of Agile while also supporting the reliability required in public sector.
It is definitely possible to achieve both autonomy and reliability in agile at scale models in public sector; they just require us to define them intentionally.