Project governance is a reality in many large software development organizations. Whether you like it or not, there are many valid reasons for software development needing to comply with governance covering a variety of topics, depending on the context in which the project is executed. Good governance covers and mitigates risks that projects may form for the wider organization without imposing too much of a cost on the project in terms of speed of delivery and budget. These risks can be related to legal, financial, security, reputational, operational and health and safety risks and this list does not pretend to be complete.
For instance there will be a slew of security and legal requirements that need to be fulfilled if you are developing a personal banking site for a financial institution. A system to manage and consult medical information will be subject to privacy laws. In an industrial setting there will be environmental and safety requirements that may have an impact on IT systems. So how to deal with governance requirements in an Agile project, where you just want to be as productive as you can without being hindered by apparently unnecessary rules that just seem to complicate things and slow you down?
Well, first of all, too much of a good thing is not a good thing, and too much governance, like too much government, tends to have a range of unintended consequences. So when deciding on the specifics of governance that your projects need to comply with, it is important that for each of the rules and standards you intend to implement it is perfectly clear which problem you are trying to solve or which risk you are intending to mitigate. Too often you hear statements like ‘All our projects need to comply with rules so and so because that is just what we decided to do many projects ago based on our experience with these projects and it is since then the way we do things around here’.
Aha, is that so? Well, I’ve got a few questions then:
- The projects you refer to, what kind of projects were they?
- Do you still do the same kind of projects technology wise, functionally, organizationally, scale wise, budget wise?
- Are the risks and issues you identified back then still relevant today?
- Are the mitigation options still valid?
- What about new technology since then, does this not allow for addressing some of these risks to be handled differently?
- Are the people still the same, or have most if not all in the meantime been replaced?
- For external customer facing projects, are the market expectations still the same, particularly in terms of quality and speed to market?
- Is your market position still the same
- Have new regulations come into effect, or existing ones changed or abandoned?
Once you have a pragmatic and reasonable set of rules for your governance framework, it must be made sure it is in fact adhered to. The best way to do this is to explicitly include it in your definition of done, and if some rules do apply to certain user stories only, then they need to be reflected in the individual acceptance criteria for these user stories. It is of course important that the Product Owner puts sufficient emphasis on this when accepting new functionality as Done. It is an area where it can be very tempting to skip a few rules in order to be quicker in the market, but this is a risky strategy. In the type of organizations where governance becomes necessary, there will be steering committees and program boards and release management and it is up to them to make sure that team members, the Product Owner and Scrum Master are aware of the need for this, while at the same time avoiding to become just an administrative hurdle to take on the way to production. The latter will occur when the motivation for certain rules is unclear, this will lead to rubberstamping of certain aspects of governance compliance.