This is one of the first questions that is asked by any enterprise that wants to implent agile. The reason it’s usually asked is because of the agile tenet of “Working software over comprehensive documentation” and the assumption by most people that this means ‘no’ documentation. But putting the documentation issue aside (I’ll get to that in another FAQ), the real issue is that most waterfall projects equate ‘governance’ with ‘governance process’, which in waterfall can be extremely laborious, time-consuming and inhibiting to continuous deployment.

Governance tries to ask the question: “have we thought of everything? Have we catered for all the scenarios we know about?” Of course, there will always be scenarios that we didn’t know about that couldn’t have anticipated. The reality is that governance in general is tricky. Software development teams are equally capable of falling prey to optimism bias, building features that cater for the best case scenario and forgetting that an iceberg of danger can lurk under these features. Agile tries to shine on these blind spots by building in practices and ceremonies that point a spotlight on these dark areas.

One of the key practises is the writing of user stories to encapsulate the needs of the users. But herein lies a subtlety that is often overlooked. The Story shouldn’t simply describe the needs of the user. It should also describe the possible different scenarios that could play out during the interaction. This would mean both the positive and negative scenarios, i.e. things that can go wrong with the planned interaction. It should also describe all the non-functional requirements that may lurk around the feature. This would include performance, security, legal, compliance, etc. These elements are often overlooked by the BAs when they first start writing User Stories. But this is where other practices in agile come into play to help.

The Story Review is the ceremony where gaps in the User Story should be picked up. This is where the entire team interrogates the story and brings their respective expertise to the table to ensure that they understand as clearly as possible what needs to be built. If there is the proper representation in this ceremony, most gaps should be identified and fixed. In a large enterprise where legal, compliance, risk, infrastructure, etc are separate business areas not part of the core team, it’s often necessary to have a separate review of the stories planned for the next sprint with these areas so they can give input where needed.

These stories should be documented in an electronic tool that everyone has access to to make the sharing and reviewing as frictionless as possible.

It’s likely that there will still be elements that are missed in the story – we’re all human after all. When this happens, the retrospective is there to catch the overlooked elements. A well-structured retro ensures that the team reviews all aspects of their sprint and records their action plan to improve the next sprint. For a new team some actions that typically come out of the first few retros relate to the detail required in their user stories and what was left out. This is all good, as agile about learning and improving, not about getting everything right from the beginning!

When it comes to the technical governance of the code and standards that need to be adhered to, agile tries to automate this as much as possible. Test-driven-development (TDD) ensures that quality is built in by facilitating test-first development. Pair programming further helps the quality of the code by forcing another set of eyes over the code before it’s released. Code reviews are usually integrated with the code check-in practices, which further helps the teams keep to top quality standards.

To help with the coordination and governance of standards across teams, Practice Chapters are established where pertinent information for each skillset can be discussed and debated. It’s important to note that these chapters are driven from the team members themselves and not by management. The teams decide amongst themselves what the best solutions are to the problems they’re encountering, which support and potential guidance from chapter leads.

All these practices, ceremonies and groupings help to make sure that the teams take accountability for proper governance by baking it into development process, relieving the need for a massively onerous ‘cover your ass’ governance process at the end of the project.