Company Y, a major satellite TV provider, initially engaged us for technical coaching. Like so many leaders, their VP of Engineering, our initial point of contact wanted to boost the throughput of his engineers by upgrading their skills.
While we delivered on this, we quickly realized that the real constraint was their requirements lifecycle.
This was an organization that used SAFe®, at the time and the advice most SAFe consultants give on requirements is to do minimal analysis and documentation until you reach the team level and begin implementing a work item.
The Product Owners operating at that very team level were deprived of both context and time, so they spent most of their energy on writing their requirements in the common user story format (“as a …, I want …, so that …”). There was nothing that stored product knowledge anywhere, which is already a problem but was doubly so for Company Y because they often needed to implement the same functionality on several different platforms (e.g., iOS, Android, and web). This problem was compounded by the need for a single API that delivered consistent functionality for all front ends. On top of it all, they needed to capture usage metrics with consistent meanings throughout all these different platforms.
When we began engaging product, we quickly started helping them set up a PKB. Being sure to include the Product Owners and Managers, we worked directly on their product knowledgebase, showing them how it should be structured and formatted with their real requirements. This effort allowed us to build a “seed” PKB for the organization that would support its adoption of using the product knowledgebase as their single source of truth for all things requirements (and, in fact, all business knowledge relevant to their product).
The organization had an appetite for an adoption of Behavior-Driven Development (BDD) and our experience is that, without a product knowledgebase, these efforts have limited success at best. However, because we had put in place a product knowledgebase, we had an opportunity to help them make this shift in practices. While we helped the teams define and analyze requirements using the Gherkin syntax and BDD analysis techniques, the technical coaches assisted the teams in consuming these requirements as turning them into tests.
The result of this effort was that the organization began to capture requirements (and all related business knowledge) in a single, persistent repository. This repository was something that they were able to tend to and refine over time. The requirements it contained became consistently more precise and better understood.
Product Owners no longer had to start from scratch and redefine an entire requirement every time they wanted to make a change. This allowed them to write requirements faster but, at least as importantly, it prevented them from missing critical details, which allowed the engineering teams to implement requirements updates far more smoothly.
The power of these centralized, persistent requirements was amplified when applied to the features that had to be consistent across all platforms.
Suddenly, there was a single place to define the requirements for those features and Product Owners only needed to link to them from separate work items to ensure their teams were able to do their part.
On top of it all, we were able to bring advanced analysis and design techniques to bear with real effectiveness. In practical terms, this meant that Product Owners could define certain things once and only once and then just point them everywhere they needed to use them. This reduced the amount of effort required by Product Owners to articulate complex requirements and also provided hints to engineers about where they could make design decisions to improve the quality of their code.
