Ask just about any technical team nowadays and they’ll claim they’re using some flavor of Agile practices in lieu of the debunked Waterfall method. For all the corniness of poker playing and daily standups where people actually stand up, it’s hard to argue against the eminently sensible Agile Manifesto. Still, the technical landscape is dotted with software releases that don’t cut the mustard, from quality problems to software that fails to effectively address customers’ most significant points of pain.
A breakdown in the Agile process most often occurs at the point of handoff. In this case, the handoff from the Product Owner to the Development Team, especially as teams grow in size, is fraught with difficulty. Those versed in Agile will correctly object that there shouldn’t be a handoff. Instead, it’s supposed to be a more collaborative process. There’s a conversation (remember, Agile is about discussion, not documentation) between the Product Owner and Development Team that occurs before the start of a Sprint that should provide the team with most of what they need to work heads-down for the duration of the Sprint. The Product Owner is available throughout the Sprint to answer questions as they arise.
What happens if the Product Owner doesn’t have all the answers? “That’s simple,” cite the Agile officinados, “a Sprint mustn’t begin until the Product Owner gains a level of clarity about the project.” The pressure to deliver software is sometimes so great that Sprints begin without adequate understanding, scoping, or assessment of risk. The premature commencement of Sprints is a byproduct of rapidly growing companies and is the primary reason why quality suffers and released software neglects to address customers’ true pain.
Imagine the scenario where a startup receives a large cash infusion that propels it into a growth stage. At this point, hiring often focuses on rapid Engineering team growth. Sure, there is a trickle down effect and Engineering growth necessitates hiring for other teams. However, speedy hiring is almost always lopsided and often results in a larger ratio of Engineers to Product Owners. Furthermore, there’s a significant ramp up time before newly hired Product Owners are able to learn the business and customers well enough to gain the level of omniscience required by the Sprint teams.
Does this mean that chaos descends for a time until new employees gain their footing? Not necessarily, although growth often does usher in a period of dysfunction. The dirtiest secret of Agile is that the Product Owner role should actually comprise an entire team and not just any run-of-the-mill team. It’s a small and mighty Discovery team that consists of top performers in a few disciplines. The role of a Discovery team is to fully consider the work, e.g., roughly determine what is to be done and not done, the basic contours of how it will be done, the risks inherent in the approach, and the technical feasibility of the work. Anything less and the Development team will spend valuable Sprint time digging for answers and will be unable to produce working software at the end of the Sprint. This requires more than just a Product Manager. A typical Discovery team is made up of the following:
- Product – The Product representative is typically a Product Manager who has a deep understanding of industry trends and the customer base. This person is a key problem solver who leads the charge in fitting a solution to a problem.
- Technical – Although it may seem wasteful to engage a senior-level technical employee on a Discovery team, it’s quite the contrary. Invariably, a developer who has the 10x capabilities (see the blog series that beginning with an explanation of the principles of 10x performance) will propose a technically feasible solution that minimizes risk.
- Design – If the solution requires user interface, a designer should provide a rough idea of an approach and a workflow.
The Discovery team explores the problem deeply, proposes a solution that will fit into the established time constraints, and sells it. Note that it’s a good solution but not a perfect one. Furthermore, the Discovery team isn’t providing a complete solution – they are merely shaping an approach so that the Development team begins with a firm foundation they can build upon. Also, the Discovery team isn’t sprinting. They are working methodically to uncover the information they need to craft a reasonable solution. Unfortunately, the discovery process is seldom a fast endeavor yet the conversation between the Sprint team and the Discovery team should not occur until discovery finishes.
As Engineering teams grow, the inability to appropriately staff Discovery teams represents a bottleneck on the throughput of high quality software delivery. This requires some shuffling of senior-level, experienced employees onto Discovery teams and acts as a governor to Engineering hiring. New hires are invariably missing some or all of the qualifications required for successful discovery and must be trained and seasoned before they can become effective Discovery team participants.
The dirtiest secret of Agile is really twofold: 1) there is a significant upfront discovery effort that requires a small team of senior people, and 2) the product suffers if this team isn’t scaled commensurately with growing development teams. None of this is a knock against Agile methodologies – they work just fine provided the Discovery team is considered a nonnegotiable part of the Product budget.
