#eavoices

I guess most readers of this blog know that Ireland went through a massive bust in 2008/9. The primary cause was a massive building bubble. And because the economy was dependent upon building related taxes, the crash was brutal. One of the side effects of the bubble was that building standards suffered. In one extreme case a block of apartments was constructed with no fire safety protection! There were many, many more prosaic examples. In my own case I had building works completed that had to be completely reworked within a couple of years! The reasons for the low quality were complete lack of governance. In the boom times many people set-up without adequate skills and many developers over-committed to deliver more work than they could manage competently. In Ireland, unlike say the UK, there was no independent building inspection regime. Architects merely had to give approval for work to proceed at the major stages. There was no independent oversight.

Today in the Agile project world the idea of self-governance is pervasive. But the parallels with the Irish governance regime in the noughties is too close for comfort. The Agile principles guide that projects should be built around motivated individuals, given the environment and support needed and trust them to get the job done. Further valuing working software over comprehensive documentation is effectively encouraging teams to dispense with transparency and traceability. While this may work in small scale environments, in a large enterprise the idea that all teams will be highly skilled, properly resourced and motivated contradicts general experience. So in many large organizations conventional governance is still a requirement that can be highly detrimental to the efficient Agile process.

In my last blog post I described a new Agile governance model that addresses the empowerment question with:
a) A defined Agile governance model
b) Defined principles and reference architecture that establish ways of working together with articulation of business value
c) Automation systems that progressively incorporate the principles and reference architecture into frameworks, tooling, design time platforms, deliverable profiles and knowledge management systems.
d) A Community of Interest (CoI) responsible for the governance system and communications
e) A communication system that ensures Agile projects are fully implementing the governance system, and providing at least retrospective feedback to the CoI that contributes to a common asset base as well as practice maturity.

And in this post I want to explore further the organizational issues. In the image I show there are three primary stakeholders in the Agile process. A Design Authority (DA), the Community of Interest (CoI) and everyone else; let’s call them the Crowd. And what’s really important is this is not a conventional hierarchy. The Crowd, developers, architects, product owners and business analysts are the drivers of the process, engaged on business improvement delivery projects. The CoI are also part of the Crowd insofar as they are also engaged on delivery projects, but they are individuals that have a further role of taking responsibility for coordinating consistency of the approach taken by delivery teams. As shown the CoI will be responsible for reference and enterprise/domain architecture and have an approving role for solution architecture and design, platform components and factory configuration. And the key point here is that all of these key deliverables start by being crowdsourced. The delivery teams are in the best position to establish solution architecture and design. The delivery team member with a CoI role is responsible for identifying and promoting candidate components of reference architecture, the design platform etc to the collective CoI.

The DA is different. It’s still not hierarchic, but it does approve demand shaping decisions, reference and domain architecture. This generally happens in response to delivery project concerns, for example when there are affordability or timescale issues with “doing the right thing”. You know the deal, if we don’t worry about technical debt, we can deliver on time and budget. But if we address the bigger architectural questions, and deliver solutions that will reduce complexity, reduce operating and maintenance costs etc, then the delivery date will be pushed out and additional resources required. Frankly this is the right time to address the value of architecture, because the questions are real.

So what I have described here, and in the last post, is an evolving governance model in which the definition of “self” is stretched a little to encompass the role. The Crowd has a major role in informing the requirements for policy and architecture as required for specific projects.  The CoI are responsible for synthesizing these requirements to meet some broader, longer running remit and the DA guides on bigger questions of architectural compliance from a strictly business value perspective. The Crowd and CoI are also responsible for automating policy wherever possible; selecting exemplar solution components for platform and factory implementation, so that the very best solution components become reusable as patterns, configuration items, coding standards, services etc.

Whether it’s in a building or software development context, simplistic self-governance doesn’t work in complex enterprise situations. However understand the roles and responsibilities, work bottom up with Crowd sourcing and you may just motivate a very large team by enabling them all to contribute to the greater good.

See Also: Agile Governance