A Different Way to Think About Process

When I interviewed at Viget three years ago, I asked a lot of questions about the company’s project “process.” I had previously worked at a startup whose process was largely “make it up as we go along,” and I had read several books and articles on agile development before the interview. So I assumed the startup was clueless, and that surely Viget had a concrete, repeatable, nameable process.

I can’t remember what they told me in the interview. Probably a variation of what we tell clients: “modified agile”; one- or two-week sprints; daily (or thrice-weekly) standups; pair programming when appropriate. Whatever they said, it kind of made sense.

Once hired, I learned about Viget’s process in more detail. I learned how we use Unfuddle, a project management tool; how we run kickoff and iteration planning meetings; how to follow project management checklists. For two-plus years, it kind of made sense.

And then I realized: it kind of didn’t.

It’s not that Viget doesn’t have process. It’s that my mental model of what process is and what it’s for was misguided. I knew nothing.

So I want to share what I have since learned about process — what it is and what it isn’t; what it can and can’t do.

A Flawed Mental Model

In retrospect, my mental model of the web design/development process was something like:

A set of defined and prescribed rituals, tools, roles, and artifacts that in and of themselves result in a functioning website.

I imagined the web development process as an assembly line. The rituals, tools, etc. (sprints, standups, ticketing app, testing spreadsheet, Scrum master) are machines or people along the conveyor belts that produce the artifacts and assemble them into a finished application. I thought that as long as you have the right process components in the right places — as long as you have declared e.g. “two-week sprints!” — the artifact creation and assemblage ... just happens. Magic.

That mental model is flawed because it views process and process components as ends unto themselves.

Focus on Questions, Not on Process

But when used responsibly, process components — the rituals and tools — are not ends. They are the means by which we ask (and answer) important questions and convey important information.

For example, we might ask these definitional questions during a project:

• What user problems are we trying to solve?
• What business problems are we trying to solve?
• What are possible solutions to those problems?
• What are the most effective ways to implement the agreed-upon solutions?

And we might ask these logistical questions:

• Who will devise those solutions?
• How will the solution definition be shared?
• How will we communicate the work each person needs to do to implement the solutions, and the work’s status?

The flawed mental model treats process components as blunt proxies for these questions. The assumptions are (1) adopting a given process component automatically conveys that information, and (2) this component is the most effective way to convey that info. For example:

• The “iteration planning meeting” process component might be a proxy for “Communicate the work each person needs to do.”
• The “kickoff meeting” process component is often a proxy for many questions: Who am I working with for the next four months? How can we get to know each other better? What are the business and design goals? What problems are we trying to solve? Can we revisit a major scope question the SOW glossed over? How do we navigate a client’s internal politics? What are the problems, goals, assumptions, and expectations for this one feature that we need to start defining tomorrow?
• The “project management tool” process component is usually a proxy for “Communicate the work each person needs to do, and the work’s status.”

The problem is that treating process components as proxies for the questions or information makes it easy to stop (or never start) thinking about the questions themselves. This can make the process components ineffective and annoying.

When you think first about the questions — rather than the process — you might realize:

• Wait a tick — the iteration planning meeting and project management tool are asking the same question! Maybe we should jettison one of those process components, or use it to convey different information.
• A single kickoff meeting with a zillion people is not the most appropriate context for asking all those questions.
• The project management tool is so specific to certain team members (e.g. developers) that it’s inefficient or confusing for conveying information to/from other team members (e.g. UX and visual designers).

When someone expresses frustration about overbearing “process,” there's a good chance process components have been implemented by rote — because they’re standard “parts of our process” — rather than because they are the best ways of answering certain questions or communicating certain information in that particular context.

Of course we don’t want to start from scratch on every project; having a toolbox of recommended process components provides a useful default starting point. But recommended is different from prescribed. The most important thing is to understand and articulate the questions that need to be asked, and choose the process components that best help answer those questions.