At Company Z, a major agricultural lender, we were simultaneously brought in to improve both their technical and product practices. The project was very, very late (three years into a six-month rewrite) and the hope was that our coaching would help that project get back on track.
Their technical team was outsourced and very low skilled; so low-skilled that many leaders at Company Z blamed them for the lateness of the project and questioned whether or not they could produce anything at all.
Their product management team was staffed with people who mostly had a project-management background and whose interests were in the same vein. They were not accustomed to deep analysis or holistic thinking and wanted to focus primarily on tasks. The engineering side of the organization, of course, believed that it was an insufficient quantity of requirements that was causing the project’s extreme lateness.
There were few surviving documents recording the initial requirements of the legacy system being rewritten. Those that did exist were too high-level, and many too stale, to be useful. Most of the available knowledge about how the system was supposed to work was stored in the heads of various banking experts throughout the company – stakeholders on the finance side who really weren’t involved in the software side of the organization at all. Finding the right stakeholders, and all the right ones, was onerous and time consuming, and often introduced lengthy delays due to their limited availability. Furthermore, their information was very siloed and sometimes even conflicted with that from other stakeholders.
A large portion of the remaining knowledge was codified into, of all things, the design of the database for the legacy system. This meant that it was often necessary to send one of the top engineers in the organization (one of the actual employees, not a member of the outsourced team) “database spelunking” in order to reverse-engineer requirements. Those reverse-engineered requirements took a long time from a very expensive and overtaxed resource to produce low quality answers that were only guaranteed to tell you how something works, not how it should work.
Worst of all, however, the bulk of the knowledge required to build the system was just gone. It wasn’t a matter of finding the right person. There was no fragmented documentation to find. It manifested nowhere in the database design. It was simply nowhere to be found. These requirements had to be completely reconstructed through a labor-intensive process of interviewing a variety of experts.
The people who once knew how the old system worked and why took that knowledge with them when they left, as they virtually all did over many years for a variety of reasons. The ones who remained, frequently would not understand why some limitations were placed on the legacy system because those limitations were no longer business limitations, and in some cases had never been.
Several attempts had been made to revamp the requirements but it was always done from a tasking perspective. One person used one way to divide up the tasks, another used another. Nobody worked on – or even considered – dividing up and defining the product.
The teams implementing these requirements rarely understood what they were told to do. They had fallen into the bad habit of – and we say this without even a hint of hyperbole – just writing some random thing that had nothing at all to do with a requirement and then saying they were done and closing a story.
Over the course of about a year, we gradually changed how the product organization and the engineering teams functioned. We started by defining a product knowledgebase and putting the requirements in it. Many of the people in product management roles had to transition to roles more appropriate for their skills and interests and were replaced by staff with a true product focus.
A mechanism was put in place to ensure that requirements received adequate analysis prior to being introduced to the teams. This same mechanism created visibility about where a requirement was in the definition or reconstruction process, helping leaders understand what was happening. We followed this up by adding a process to ensure that the teams truly understood the requirements.
That was no small task as there were at least three barriers involved: a language barrier, a pride barrier, and a skill-level barrier. To overcome these difficulties we brought in per-work-item, purpose-built Definition of Ready (DoR) and Definition of Done (DoD). We used a strict handoff and responsibility model to enforce the DoD and the DoR and made sure that the teams were using analysis stories to allocate adequate time for ensuring that the requirements were truly ready and understood by engineering.
The results where shocking. Participation throughout the team in the requirements maturation process skyrocketed. Consequently, the teams – teams whose efficacy were called into question by so many, that had formed the very bad habit of just writing something and then claiming they’d fulfilled a requirement, that were three years late on their rewrite – suddenly started producing.
In fact, they started performing at a level nobody would have guessed possible.
Whereas it would typically take three sprints or more to get a single small feature change made as requested, the teams began delivering the requested changes as specified correctly on their very first try. Before the change, the teams would often have large numbers of stories “almost done” at the end of the sprint, inevitably carrying them over to the next sprint. After the change, the teams ended sprints with few or no stories left to complete. They began finishing stories early, even to the point where they began reaching out to Product Owners to get stories closed in the middle of the sprint!
Moreover, the state of the product knowledgebase was meaningful to everyone. The state of the project could be expressed in terms of requirements met and requirements yet to meet, rather than tasks done and tasks not yet done. When a requirement was marked as implemented, everybody understood the specification and everyone had complete trust that it was really implemented as specified. If something that was marked as implemented was broken, it was clear that it was a bug. If someone proposed a “bug” that wasn’t specified in the PKB, anywhere, it was clear that it was actually a new requirement.
Perhaps the biggest impact, though, was that their late project finally started to show visible progress toward completion. Finally, after a delay that had lasted over three years, the project became unstuck and was moving. Ultimately, they managed to ship their product with a high degree of confidence in its ability to move properly.
