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.
When the business keep piling on projects for the IT team, what generally happens is people are then split between multiple projects, with project managers generally being divided the most. The thinking is that a person can split themselves between multiple projects easily and that somehow they will manage to get all the projects done at the same time. The myth of multi-tasking has been dispelled many times so I’m not going to repeat that here except to say, don’t split people up between projects. Full stop. The biggest issue is lurking in this question is that fact that adequate portfolio-level prioritisation isn’t happening. The business needs to learn to prioritise properly. You can’t always just throw people at the problem, in fact, this often just makes things worse, as you end up with a bottleneck somewhere else, such as too many people working on the same code, or too many people trying to test in the same environment together.
IT and business need to work together to re-prioritise the projects so that the core team members can be fully allocated to a single project/product team. Once everyone is allocated, put all the other projects on hold until a team is freed up again. With the team focused on a single project, the throughput with increase and projects will start being delivered again.
In an enterprise you can have multiple project teams working at the same time, which is fine. However, you are generally constrained at some point because either all the teams may have to use the same environment to test or there may be some other infrastructural or process constraint. When this happens it doesn’t matter how many projects you’re running at the same time, your throughput will be limited by those constraints. Looking busy doing many projects isn’t solving your problem. Unblocking your constraint would be a much wiser investment.
Prioritisation is such a key part of agile. Work on one thing and get that thing finished.