When you peel back the covers on most agile software teams you’ll often find a collection of processes that are more accurately modeled by a waterfall. Comprehensive layouts (“comps”) created by design teams to often put a hard stop to any true agile process. Comprehensives look like an application. This is doubly true with modern mock-up tools that can simulate user flow. So when it comes time to evaluate the output of the engineering team, there is a natural inclination to compare the live application to the comp and determine success based on how closely they match. This is not agile.
A true agile process is built on user stories that describe the need the user has from the system. A user story is complete when the acceptance criteria has been met. Agile organizations utilize user stories in lieu of business requirement documents that seek do describe every facet of a feature in detail which forms the top of the waterfall in traditional organizations. Agile replaces pre-planning with iteration and constant evaluation of delivered, functional product which feeds into the next phase of creation.
When the success criteria of a project is how closely it matches the comps, the comps essentially become the requirement document the agile process sought to avoid. Everything else follows down stream. Engineers start breaking down stories based on the visuals and QA opens bugs when they don’t match. Acceptance criteria that is not represented visually drops off the radar and the user story as a whole runs the risk of being neglected. Agile was intended to facilitate quick iteration, but now every change or customer request has to start at the top and trickle down, thereby lengthening cycles.
While this happens often, it does not have to be this way and comps can be a valuable artifact in an agile process.
The most crucial element is to keep focus on the user story and the acceptance criteria, since really that’s the goal. What matters to the user is that the problem is solved in a way that doesn’t add more work for them. In that way comps are great communication tools, by aligning both the user and the engineers on how that looks and getting early feedback. If the feedback can be handled with a few notes and annotations there’s no reason for updated designs. Just build and get it into the hands of the customers for final validation.
The often ignored aspect of agile is that the process replaces upfront communication and defined contracts with constant communication and shifting interfaces. Like written requirements and, in many cases, the code, design comprehensives are another stage in the process. To treat them as an end does the whole team and ultimately, the customers, a disservice through wasted time and slower delivery.
Photo by Hal Gatewood on Unsplash
Did you like this content?
Related Posts:
On it becoming Day 2 and Leaving Amazon
Making the jump during a pandemic was daunting but there is just something about startups.
Maker's Space, Manager's Space
Manager vs Maker space is just as important as Manager vs Maker time
Fast, Cheap, and Good; How to get all three.
High-quality product can be created quickly and cheaply if the available resources are utilized wisely.
