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.
No comments:
Post a Comment