We interview Everett Zufelt, Associate Director of Technology, and Katie McCoy, Practice Lead, Product Management to find out when, how and why you should iterate.
Over the last year or so, the software industry has hit a tipping point: Agile has become the norm.
Surveys show that the majority of software organizations describe themselves as “pure agile” or “leaning towards agile” in their methodologies. Some studies estimate penetration nearing the 90% mark. Over 50% of projects are managed with the agile model and companies are frequently reporting that as a result of the shift, they “…have definitely seen measurable improvements in time to market, product quality and customer satisfaction.” — VersionOne, Agile Made Easy, 2014
It’s great progress that is in part based on the heart of agile methodologies: the concept of “iteration”. Instead of assuming up front the possession of all the knowledge of what users will adopt and find effective, key functional elements are released in smaller chunks with the intention of not blind repetition, but careful measurement and rapid, ongoing optimization.
Not only do you get to market faster, but you get better overall results.
“We need to approach design and development from an analytic perspective,”
says Everett. “It’s most wasteful when people are trying to achieve an outcome that’s not measured. It’s not just ‘do things better’; the process has to be framed and followed up as an experiment. An ongoing experiment.”
Embedding into a product development process an expectation of (and requirement for) analysis and optimization certainly has its merits. Instead of traditional models of isolated decision-making and set-and-forget rollout tendencies, actionable feedback is gathered in a quicker, more efficient manner; ideas evolve naturally with a flexible approach to more peripheral features; focus on adequately solving key use cases is easily achieved; regular stakeholder engagement is a natural byproduct, and so on.
There are, however, dangers to getting caught up in the allure of iteration. At both the conceptual and practical levels, we must be careful not to push iteration too far only to see productivity and credibility double back on us. As we praise the merits of granular, intelligent improvement, it is critical for us to also acknowledge the potential drawbacks and what it means when the practice is left without active reflection and moderation.
Your Hypothesis Should be Based on Past Experience
According to Everett, “One of the misconceptions in the world of web application development is that you’re hiring or working with an expert who ‘has all the answers’. And nobody does. If someone tells you that they know all the answers, you should immediately question their credibility.”
That could not be more true. It is also true that if someone tells you that they know none of the answers and must test everything to make any type of judgement, you should have equal cause for concern — especially if they are, despite any exaggerated sense of humility, supposed to be experts in the space.
It’s important to appreciate that being iterative does not preclude the possession of a significant level of knowledge and understanding about what should and likely will work before a line of code is ever written. This knowledge is gained from experience, external research, an understanding of the business goals, and of course, from thorough, direct feedback from users.
Any good hypothesis is based upon an extensive foundation of observation, and any good test is based upon a stable foundation of planning.
As Everett says, “You should seek a partner/vendor who can tell you about a strong hypothesis, how to validate that hypothesis, and help you get there with a system that allows for continual analysis, more hypothesis [testing], and fast deployment of iteration. This is done so that down the road you’re optimizing on real data, not just opinion.”
Find Balance Between Endless Iteration & Final Steps
It’s not hard to blow your budget. The temptation to build it once the “right way” and then be done with it is strong, especially for customers. As Everett will tell you, “Oftentimes, we find the customer is inclined to spend 100% of their budget on the first release — not saving anything for the next cycle.” But iteration takes time, and to get the final product right, you’ll want to go through a few cycles.
Photo Cred: TheNextWeb
Blowing the budget on a first release is generally poor strategy, but it’s not difficult to see how the opposite — total uncertainty of what constitutes “a final step” in the context of a carefully budgeted project — can be just as difficult to swallow.
While software abstractly lives on an infinite continuum of improvement, when bottom lines are at play — and they always are — things only happen if temporal and financial investments are assessed, acknowledged and approved. As Katie says, “At some point it has to ship. But when it does, you need to ensure you’ve embedded the proper mechanisms for measurement and learning. And for how long do you measure and learn before iterating? It differs for every product and depends on the success criteria.”
Everett echoes the sentiment. “One of the things we, as an industry, can work on is informing our customers up front, that the day we launch this new website [or application or MVP], that is step 1. Step 2 is measuring how it performs. And step 3 is re-defining our hypothesis based on that insight. Then we go step 4: re-launching updates.”
The flexibility inherent to iteration must always be balanced with the confidence inherent to executive consent.
Don’t Lose Sight of the Bigger Vision
Katie also understands the importance of keeping your eye on the prize.
“Anything you build must match the original vision, it should align with the overarching goals”
says Katie. “That way, if you need to pivot, you can reference the agreed-upon outcome and see if this addition will make an impact where you initially wanted.”
Breaking a product down to granular levels and iterating on narrow use cases is an almost fool-proof strategy for tactical execution. But that method always runs the risk of myopia and, as they say, “losing sight of the forest for the trees”.
Remember that iteration is an approach that facilitates creativity and success. What ensures success is the proximity of the “final” comprehensive experience (and of course the metrics it generates) to the overarching goals of the project.
“Perfection”: As Unrealistic as it is Noble
“I see a lot of iteration and cycling on concepts,” Katie says as she reflects on her experiences. “We can always improve on our work, and as creative types we’re never quite satisfied. But as a team we eventually need to stop and reflect on the goal we’re trying to achieve. If, to our knowledge, our work solves for that goal, we shift gears into validation mode and test those ideas rather than debating them. This triggers a new series of iterations closer to the real world.”
There will always be more you can do to progress forward (no artist ever thinks their work is “done”). But much like the agile philosophy surrounding documentation, while “perfect” would be nice, at some point you’re being counterproductive if you’re holding back a release for perfection’s sake. The key then, is to find and stick with a point of completion where you can say “this is good enough to launch — now let’s get it out there and get some feedback”.
Iteration Sounds Small, But It’s About the Big Picture
Successful iterative implementation comes down to a balance of the big and the small; keeping a line of sight between the scope of a development iteration and the purpose and vision of a project; endorsing agility while striving for certainty.
And while iteration can lead developers and designers down rabbit holes chasing perfection, (or clients through endless loops of testing), when managed correctly it’s an absolutely critical methodology that helps to gain insightful feedback from users and quickly progresses any product towards optimization.
Interested in working with us? We’re looking for great UX / UI designers and developers → Apply Here