Agile Product Development

In our last post, we reviewed how Human Centered Design (HCD) applies data and an iterative process to keep your product focused on building the best solutions for your customers’ problems.

Today, we’ll discuss how agile product development works hand-in-hand with HCD to establish flexible processes that readily adjust to your company’s changing needs without massive amounts of wasted time and sunk costs.

Agile product development actually contains several sub-methodologies including but not limited to Extreme Programming, Kanban, and Scrum. The details between each is worth learning. But for now, we just need to keep in mind that agile methodologies are effective in both mature and startup environments because they emphasize incremental iterative progress that allows for constant change.

Agile development utilizes a tool called “user stories” which describe a particular software feature from the user’s perspective. User stories tend to be structured like this:

As a [user], I would like to [do something], so that I can [benefit somehow].

Here’s an example: As a resident who owns a dog, I would like to schedule dog walking services between 9AM and 5PM so my dog can be cared for while I’m at work.

By describing features from the user’s perspective, we guarantee that everything we build has value to the user. If we can’t explain why a user would benefit from it, then we have to reconsider building that feature. Developers often object to this because abstract programmatic components can’t always be easily described in user-specific terms. How you resolve this issue depends, in-part, on your team’s existing development processes. In the past, I’ve found it useful to use tools that directly sync with Github or Bitbucket. This allows developers to automatically link specific programming issues to a user story’s related acceptance criteria.

Outside of just keeping updates user focused, user stories minimize damage when they’re subject to change because they are completely independent of each other. In agile lingo, this is called a “releasable.” Once done, the company should have the technical ability to release that particular story to its users at any time. For example, the user story above describes a scheduling component within the dog walking service. Although you may not want to release this component on its own, once “done,” you should be able to. On the flip side, if the story has to be scrapped for any reason, it should have minimal impact on other stories being worked on in unison. This gives you enormous flexibility that is critical in a fast-paced environment.

So how do you know when a story is “done?”

Each user story should contain “acceptance criteria” that define the user’s experiences within the story. Here’s an example based for the story above:

• If a resident is logged into the resident portal, they can access the dog walking component
• When a logged in resident accesses the dog walking component, they can enter:
  1. how many dogs they have (required),
  2. each dog’s age (required), and
  3. each dog’s unique needs (optional), and
  4. each dogs’ unique medical conditions (optional).
• If the resident does NOT enter the required values above, they cannot schedule a dog walker.
• After the resident defines the required values above, they can choose a date and time for the dog walker to walk their dog(s).
• If a desired date and/or time is not available, the resident cannot select it.
• After the resident selects a desired date and time, they can complete the scheduling process.
• When the resident completes the scheduling process, they are sent a confirmation email.
• When the resident completes the scheduling process, they are also provided an on-screen confirmation.
• If an error occurs at any time, the resident is provided a clear and concise on-screen notification.

Notice that the acceptance criteria do not define design. Rather, they define functionality which the designer can then use as the framework for their final deliverable. After the designer completes a user story in accordance with the acceptance criteria, they ship it to the development team to execute. Once executed, it is sent to a quality assurance tester (or the product manager) who reviews the acceptance criteria and determines whether the story is “done.”

Quality Assurance

As you would expect, this process is called Quality Assurance Testing (QAT for short). If it’s not done, it gets sent back to design or development, whichever group is responsible for the incomplete portion. The process repeats until the user story is, in fact, done.

The beauty of agile processes is that it allows everyone at the company to work on entirely independent stories at varying stages of completion at any given time. While the product manager is drafting new stories, the QA team is testing whether others are done. For Scrum teams, each member is working within a “sprint.” A sprint is a given period of time, typically one or two weeks, in which each member aims to complete their portion of specific user stories. The flexibility of this approach means that if at any point in time there’s a priority change, related user stories can be tabled with little to no substantial impact on other user stories still in motion. For some teams, even this is too restrictive. Kanban provides even more flexibility by doing away with sprint cycles and instead employing a fluid, on-going cycle in which team members can add, complete, and release stories at any given time.

In the real world, perfectly executing an agile methodology is hard. But even a hybrid approach can have enormous upside. In particular, when paired with human centered design principles, you’re assured to:

1. prioritize features that reflect user needs,
2. develop features more effectively,
3. mitigate the time and cost of mistakes, and
4. adapt more readily to unknown variables or surprise changes.

To recap, human centered design identifies appropriate solutions to given problems while agile development defines how each solution should function and splits them into self-contained executables. The end goal is to establish a user-centered machine that can correct course effectively and build products that users love and derive value from.

When implemented in a way that fits naturally into a product team’s existing workflow, these methodologies nurture the stability and flexibility necessary to work productively.