How to Escape Hidden Pitfalls with Agile Discovery
When working with a developer agency or even just a freelance developer, it’s important to understand the purpose of a Discovery Workshop.
The purpose of the workshop is not simply about:
delivering an estimate, or
defining the requirements for a project, or
educating the development team about the value of the features for the customer.
The purpose of a discovery workshop is to narrow the cone of uncertainty around delivering a product that is both on budget and delivers value to your business.
A discovery workshop is an exercise in measuring uncertainties.
Let’s take a step back.
Discovery Workshops are a Waterfall Step
For those of you who are used to agile workflows?, discovery falls outside the realm of a truly agile team. So if you’re used to managing a development team in-house, the practice of a discovery workshop may seem incongruous with the agile or scrum best practices you have adopted.
The truth of the matter is that a discovery workshop is meant to benefit the agency or development team as a form of reassurance before the project starts. For those who work with internal stakeholders, a discovery workshop is meant to demonstrate the value of planned features to both developers and align stakeholder input before development starts.
Essentially, this step is a sanity check, the agency is saying:
Can we feasibly execute this? Do we have the skillset?
Do we have the same understanding of the website/product/application as the client or stakeholder?
Will we meet the client's/stakeholder’s expectations in terms of quality and cost?
What kind of risk are we taking on with this stakeholder/client in terms of their temperament or expectations?
For these reasons, the discovery workshop is a waterfall step—a client onboarding process if you will—and that’s great! If not because you can gain more confidence in the delivery, then because the discovery process is used to establish the business value of the project.
Discovery Workshops align the Development team with Product Business Values
For the businesses or stakeholders, this is a critical first step towards realizing the vision of their website, product or application. Prior to the discovery, product owners, stakeholders—or even product champions—all may have their own ideas of what this product will look like when finished; but the discovery workshop is used to make sure that each stakeholder shares their vision with a solutions architect and/or technical architect.
Pretty much every client or stakeholder can come to the table with a list of requirements, and point to some other website’s that they like for inspiration—but shared documentation ≠ shared understanding.
A solutions architect, or requirements engineer, needs to hear the reasons why a stakeholder wants a solution. When in discussions with stakeholders, solutions architects take special care to extract the specific defining characteristics of a solution, even when stakeholders present a half-formed solution. Without this critical answer to “Why?”, the development team will not have a shared vision with the business stakeholders, and there is an increased chance that the solution delivered will somehow be askew from the original envisioned solution which would have delivered the most business value.
Discovery is just the First step
Once a solutions architect has taken that critical first step towards a unified product roadmap or vision, then the real work can begin when the development team takes up agile practices or scrum.
Discovery doesn’t end here.
In order to continually deliver value to the business, the product owner for your project must:
appropriately groom the backlog with stories and acceptance criteria
update the development team with any major shifts in business needs or goals as the project is ongoing
continually iterate on features, development practices, and methods to ensure that each sprint release delivers on value for the business
As a solutions architect, I like to call this Value Driven Development. I’m sure there are many other names you can probably think of for it, but this is the terminology I think is most transparent to stakeholders. This is what, essentially, agile and scrum practices try to capture, and this is what, fundamentally, agencies do their best to deliver as well.
In order to deliver on this promise of value to clients, businesses, and stakeholders, we must continually revise our understanding of requirements for each project.
If we don’t, then the project will surely fail—and the magnitude of such failure is determined by the transformation of values, market factors, and technology over the duration of the project while requirements aren’t being actively groomed.
(I know, I said that Discovery is Not Agile, but bear with me.)
In order for both agencies and clients to truly gain the benefits of agile, we must rethink the way we approach backlog grooming. Truly, agile as an iterative development process is well executed, and so we must take some of these principles and apply them to the requirements engineering or product roadmapping process.
In order to maximize agile development, agile discovery must be taken up in tandem.
Here are some rough steps on how to properly execute this:
Use a requirements management tool.
Requirements change over the course of a project. Keeping track of these changes is imperative to developers and stakeholders understanding how the direction of a potential feature has changed, and why. Without a tool to track why changes were made, it’s more difficult to explain to stakeholders why more time is needed to properly implement a feature.
Track the implementation of features in vertical slices or feature trees.
The process of user story mapping lends itself well to vertical slicing. As a development team, it’s much more cohesive to develop a complete shippable feature of the same parent Epic or Theme. Agile says to iterate with shippable products, but a product backlog doesn’t lend itself to easily tracking grouped vertical slices—using a feature tree as a simple notation tool will help you visually select branches of features to ship out.
Treat each sprint as a timebox to prepare the next branch of the feature tree.
The act of time-boxing your requirements gathering process will help you to get stakeholder’s input on planned features in a timely manner. Additionally, if you don’t get stakeholder input—then that’s a sign the feature isn’t ready for grooming, and should be postponed to a later sprint.
More on Value Driven Development
Want to learn more about Value Driven Development? If you’ll be at DrupalCon Asia this year, you can check out the presentation I’m giving with Prabhat Sinha and Vishnu Vijayan from Axelerant on Continuous Discovery and Value Driven Development.
I hope to see you there!
Jordan Ryan (@jordan_ryan) is President and Solutions Architect-for-hire at Facet Interactive (@FacetLA). When Jordan isn't hustling through his most recent discovery engagement, you can find him enjoying the finer grinds of fresh ground coffee in Santa Monica or fiending for a foodie fix wherever Yelp may take him. Follow him on Instagram if you like to feast with your eyes.