Ask almost any technical team nowadays, and they’ll claim they’re using some flavor of Agile practices instead of the debunked Waterfall method.
Teams using Scrum may engage in story point poker-playing, a method of estimating the level of effort of stories. Or they may relinquish their chairs for daily standup meetings. The corniness of Scrum aside, there’s no arguing that the Agile Manifesto is rock solid.
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 pain points.
A breakdown in the Agile process most often occurs at the point of handoff. In this case, the handoff from Product Management to the Development Team, especially as teams grow, 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 Product Management 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 sprint duration. Product Management is available throughout the sprint to answer questions as they arise.
What happens if Product Management doesn’t have all the answers? “That’s simple,” cite the Agile aficionados, “a sprint mustn’t begin until Product Management gains clarity about the project.”
The pressure to deliver software is sometimes so great that sprints begin without adequate understanding, scoping, or risk assessment. The premature commencement of sprints is a byproduct of rapidly growing companies and is the primary reason 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 Managers. Furthermore, there’s a significant ramp-up time before newly hired Product Managers can learn the business and customers well enough to gain the 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 Management role should comprise an entire team and not just any run-of-the-mill team. It’s a small and mighty Discovery team comprising top performers in a few disciplines.
The role of a Discovery team is to fully consider the work, e.g., roughly determining 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.
Without an up-front discovery, the Development team will spend valuable sprint time digging for answers and be unable to produce working software. 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 deeply understands 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 engaging a senior-level technical employee on a Discovery team may seem wasteful, it’s quite the contrary. Invariably, a developer with 10x capabilities will propose a technically feasible solution that minimizes risk.
- Design — If the solution requires a 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 fits 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 work methodically to uncover the necessary information to craft a reasonable solution. Unfortunately, the discovery process is seldom a fast endeavor, yet the conversation between the Engineering and Discovery teams should not occur until the discovery finishes.
As Engineering teams grow, the inability to appropriately staff Discovery teams represents a bottleneck in 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 invariably miss some or all of the qualifications required for successful discovery and must be trained and seasoned before becoming effective Discovery team participants.
The dirtiest secret of Agile is twofold:
- A significant upfront discovery effort requires a small team of senior people.
- 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 non-negotiable part of the Product budget.
Does this intrigue you? Are you interested in learning more? If so, it’s your lucky day. My new book expounds upon this modified excerpt. Buy The Agile Enterprise: Applying Agile Principles to Drive Organizational Success in digital or print format to better understand applying the principles of Agile Programming across the board in a company.
