Tag: practices

In the past, I have proposed that an agile transformation should follow “three pillars of success – Structure, Practices and Governance.” This was a concept I decided to borrow from something I read in the past. It made sense at the time that to successfully transform we need to change structure (build good teams, etc.) and adopt new practices both at the framework/process level (ie Scrum) and for software development (ie TDD, Continuous Integration). It was the concept of governance that, while it seemed to make sense, gave me some pause.

It didn’t take me long before I began to understand why I was uncomfortable with “governance” – primarily because governance seemed too top-down and heavy-handed. It seemed a holdover from the very school of thinking our transformation was trying to change. Perhaps it bothered more so because governance was something easier to implement via the PMO (and something that people were too comfortable with).

It wasn’t that governance isn’t needed – even the games we play need rules. It would be chaos indeed if the length of a football field, number of downs or number of players changed from game to game. However, elevating governance seemed to embolden attempts by people in the organization to dictate even the smallest minutia. It was as if governance gave implicit authority to make every team run a west coast offense instead of concentrating on eleven players on each side.

Once governance lost its cache, the question remained as what to replace it with. It made sense to pick a word with a more appropriate servant-leader feel. “Guidance” became a much more palatable alternative. This was better, but it didn’t provide everything needed because there were some rules that would need to be followed. After a brief flirtation with the concept “Governance and Guidance”, in the end, we settled on “Guidance and Tools” as a replacement to the original concept of “Government.” The reason for this was that most of the “rules” revolved around reporting and the tools support necessary to some basic reporting.

Once we settled on the concept of guidance, a definition of guidance was needed. Over time, a working definition emerged that was referred to as:

Patterns, Anti-Patterns and Pilots

Not only does this option have alliterative qualities, but it also allows for a much greater environment for teams to self-organize and experiment. The process is simple. There are certain things that we know to generally work well for teams. One example is Behavior Driven Development (BDD). This would be considered a pattern. It would be a practice that is not only highly recommended, but would be fully supported by the organization from a training perspective for teams that wanted to try it. The key is that this practice would not be mandated. Each team has the option to choose and would be supported in their decision, but not every team would choose to (or have the maturity to successfully) implement. I often tell my teams, while I think driving is great there is a reason I don’t hand my car keys to my nine year old.

The second category would be anti-patterns, which are defined as those things that teams have tried but there is consensus that these have not worked. In other words, something becomes an anti-pattern when multiple teams have tried something unsuccessfully. In addition, there are things our experience as agile coaches and scrum masters have shown to not be effective which are added to the list. One example would be splitting stories between offshore and onshore for the same team. In practice, the anti-patterns begin to look a lot like a “scrum but” list.

The final category, pilots, is where the power resides. This category that allows teams to freely experiment with different ways of doing business without a great deal of pressure. The approach is empirical like the Agile Manifesto. Try something and see what works. There is no failure – only data.

The team identifies these experiments during retrospectives and is free to experiment on anything that is neither a pattern nor anti-pattern. These experiments follow the scientific method in that they have an identifiable hypothesis. The outcome from this experiment (usually lasting a single iteration) is either that the experiment has proven successful in which case it can be elevated to a pattern, the pilot did not achieve the desired outcome or the experiment needs to gather more data.

In the end, after changing from “Governance” to “Guidance and Tools” and outlining an approach to using Patterns, Anti-Patterns and Pilots, I found myself much more comfortable with the underlying “three pillars” approach of our agile transformation. I believe the new approach was better aligned to the underlying Values and Principles outlined in the Agile Manifesto. And, more importantly, I noticed that organization itself seemed more comfortable with the agile transformation and the teams were much more empowered to self-organize.