Trust the Process: What to do when the standards don’t fit

Trust the Process: What to do when the standards don’t fit

Frank Lee

Director of Technology

"“Process” has developed an unfair reputation in certain agency quarters. This is largely a problem of perception. Processes that work well often go unnoticed and unremarked upon, while those that fall short earn our ire.""

“Process” has developed an unfair reputation in certain agency quarters. This is largely a problem of perception. Processes that work well often go unnoticed and unremarked upon, while those that fall short earn our ire.

We suffer for this blanket dismissal. When a process your team or organization relies upon becomes outmoded, it can be frustrating – especially for managers. It’s feels like self-inflicted wound. But while the impulse to abandon process in general is understandable, it isn’t the solution. The sounder course is to carefully evaluate what isn’t working, consider it against what is, and evolve.

This is essential. In my experience, no organization can simply implement a process once and never change it. Whether you use pure Waterfall, pure Agile, or pure “silver bullet development process of tomorrow,” you can’t expect it to work flawlessly ad infinitum. Each organization has unique business needs – and clients with their own unique needs – and these needs change, sometimes rapidly, over time. You need a process – and a meta-process for evaluating your processes – that can keep pace.

Don’t Go Chasing Waterfalls

At Archer, we were once a pure Waterfall agency, though we didn’t explicitly acknowledge this. Our design team would complete their work and get full client approval, then our front-end development team would complete their work, then the back-end team, then on to quality assurance (QA). Everything was sequential, with hand-off meetings and internal approvals when a team completed their portion of the assignment. This worked well on smaller projects, but proved to be challenging on larger ones. One of the biggest problems was communicative. While we would have every team represented during a project’s kickoff, the teams that do their work later in the pipeline would not always be involved in – or even aware of – the twists and turns many projects naturally take.

This wasn’t any single person or team’s fault – projects change. Clients adjust requirements, marketplaces shift, technologies rise and fall. To clean up an old expression, “stuff happens.” But although we recognized this potential disconnect, it was logistically untenable to get every stakeholder in a room for every small change. While we could get away with this on smaller assignments, on larger projects the changes could compound, presenting problems.

On top of all this, once design was complete, our clients often didn’t see the full picture of their project again until QA had finished and we were ready to move into User Acceptance Testing (UAT). This posed its own set of problems.

Long story short: Waterfall wasn’t working. We needed a better way to plan our development work.

Why not Agile?

Agile presents itself as the corrective to Waterfall’s shortcomings, and in some cases this holds. The Agile methodology, at its core, is about flexibility. It purports to help development teams working on a project react to changing scopes, changing requirements, and changing technologies without throwing the project into disarray. Perfect, right? But this flexibility creates its own set of challenges.

Agile is interpreted differently by different practitioners, but just about every implementation uses:

  • Fixed, two-week development Sprints rather than larger blocks of time

  • User Stories instead of fixed requirements

These grant flexibility, and shorter development periods are conducive to incremental progress. At the conclusion of every “sprint” interval, there should be something ready for review, which truncates the feedback loop and allows for change before development has gone too far.

The lack of concrete documentation, however, can obscure the end state of your product, and the time it will take to get there. You miss the forest for the trees. As an agency, we need to be able to say, definitively, that we will build what our clients want, when they want it, and within their budget. These goals aren’t entirely compatible with the Agile methodology.

Ultimately, we determined that we needed the documentation of Waterfall but with the responsiveness and collaboration of Agile. Such a process didn’t exist. So we created it.

Archer’s Methodology

Our model combines a Waterfall approach to requirements gathering and documentation with an Agile-inspired approach to development. The steps outlined below pick up after we have completed our strategy, UX, and design work: the point at which we know what we’re actually building.

  1. Update requirements and documentation

    Often, to this point, we have documentation around what we are going to build, but we may not have specific requirements written. This documentation is very granular, and is what our QA team uses to develop their test cases.

  2. Re-estimate the project at the individual requirement level

    This is important – it’s a gut check on how long we thought it would take to complete a project vs. the project as it stands now. If we’re off from the initial estimate, we know that we may have to add developers to a project to make sure we complete it on time. This part of the process also helps us root out the “unknown unknowns” of a project. The developers who will be working on the project are the ones giving these new estimates and need to be sure they understand exactly what is being built so their estimates are accurate.

  3. Organize the requirements into major deliverables, and plan “development cycles” around the estimated hours

    Our QA cycles are offset from development by one, so we are always testing the previous deliverable while we are building the next one. This lets us find larger, systemic issues before we get too far into development. This is similar to Agile’s Sprints, but they aren’t necessarily the same length. We do what makes sense for the project instead of sticking to an arbitrary timeframe.

  4. Get to work!

We’ve found success with this model. It ensures requirements are written and approved before we start development, so everyone agrees on what we are delivering has the flexibility to make changes if necessary. Pleased as we are with this model, we admit it might not be right for your organization. It might not be right for Archer either in a few years, and that’s ok!

We recognize that we need to constantly refine and evolve our process to meet our and our clients’ needs. At Archer, our process is always a work in progress.