At DesignMap we’ve worked with many companies creating products using agile development methods to speed up time-to-market.
Of late, we’ve experienced another iteration of this process called dual-track agile, or sometimes dual-track scrum, which further cuts back on development and design time. The two tracks of dual-track are Discovery and Delivery that work in parallel cycles. Each Discovery cycle focuses on understanding and questioning product requirements and each Delivery phase iterates on small pieces of code. When working in a dual-track agile environment, the Discovery team, including a product manager, user experience designer and engineer, works ahead of the Delivery, or development, team to understand and test user requirements, iterate designs and integrate customer feedback.
The phrase dual-track agile was coined by Jeff Patton and popularized through his speaking engagements around the world. Marty Cagan, also a proponent of this method in combination with Lean UX, has extensively documented his experience with dual-track agile. Many software teams that use dual-track agile modify its paths and deliverables to fit their own needs. For example, we worked with a company that added a third parallel prototyping track, and another that skipped Cycle 0 (not a good idea – we’ll explain why later). In this blog, we propose a few additions and modifications to help designers succeed when working on UX in a dual-track agile environment.
Discovery Track
The Cycles of the Discovery phase are all about talking to your users to reveal real use cases and goals and then translating those into product requirements. Elements that we use in these Cycles include user research, building user scenarios through story mapping and developing personas based user interviews.
User Research
The first step, or Cycle 0, involves reaching out to our users or, if you have none (yet!), your competitors’ users. Best practice is to conduct your research in-person and in your customers’ own environments using contextual inquiries, ethnographic studies, or other research methodologies. A great resource for learning how to make the most of our user research is “Interviewing Users: How to Uncover Compelling Insights” by Steve Portigal. In the book, Portigal discusses how to plan and conduct an interview and most importantly how to make an impact with your research.
Be sure to involve stakeholders during this phase to build consensus and establish a common understanding of your users, which will help prioritize features later on. It can be difficult to consistently test every feature during development so it’s particularly crucial to spend a good amount of time talking with users during your first Discovery Cycle. Armed with a clear sense of your users, you’ll feel OK about moving ahead on some features without user testing.
During Cycle 0, it’s tempting to ask your customers questions such as, “Do you want this new feature?” or “How much would you pay for this feature?” because these types of questions are top of mind at this point of development. Questions of this type, however, elicit responses that reflect a user’s attitudes and as such are not a good predictors of behavior.
Instead, conduct a deeper discussion about how customers currently use the product or accomplish their daily tasks. Ask them to walk through a typical task and talk with them about the areas where they run into problems. Watching users perform tasks and asking questions afterwards can lead to great insight about issues that may not be part of the original scope of inquiry. We have discovered many low hanging fruit-type fixes, changes and additions to a product’s UX by not following a strict script and giving users the freedom describe their own experiences with the product.
Story Mapping
After talking to your users, you’ll need to structure your results into a format suitable for product release planning. Story mapping is a great way to prioritize, or “map,” your user research. Prioritizing features is key to success when using dual-track agile. Understanding what’s most important to the user experience will provide clear answers when facing design decision points such as, “Do we really need five different ways to view a chart in your first release? Can we get by with just one and add more as needed in the next release?”
Each story map row provides a visual representation of a release, starting with Minimum Viable Product features at the top and then moving through future release feature sets as you move down. Anyone on the project can glance at the story map and differentiate quickly between the various release options. Jeff Patton‘s original article about the story mapping process and later this article, are both great resources for story mapping and all things agile. We’ve also worked with clients that use the web tool Feature Map to create story maps, but generally its nice to do this exercise with post-its and paper and have a wall to leave the results hanging so everyone can see them.
One really great trick that we’ve used during story mapping process is to add insights from the user interviews from Cycle 0 to the story map using either colored sticky or virtual notes. These notes remind both the Discovery and Delivery teams why the user story exists and helps keep customers in mind while discussing feature sets.
Personas
Ideally, prior to the Discovery phase you will have researched and developed your product persona. If not, the Discovery phase is a great time to use information culled from talking to your customers to develop usable personas. Hold a persona workshop with your partners and agree on a primary or secondary persona. Personas are particularly useful for identifying which user stories, as delineated in your story map, are most important and should be developed first. Alan Coopers’ seminal book, “The Inmates are Running the Asylum,” not only provides the basis for how personas should be created and used, but has also had a profound effect on DesignMap partner Audrey Crane’s experiences working with developers. Read her story and watch her talk about the book and personas at Enterprise UX 2015.
Delivery Track
After finishing all your research and user story prioritization, you are probably ready to go full steam ahead on designing and delivering products. “Come on, let’s just get this done”, right? But wait! Before you start designing, it’s important to discuss and agree on what you are delivering, how you will deliver it and whether it will work for the development team. We’ve learned over the course of many projects that building a quick prototype with Invision or other prototyping tool provides a great deliverable to developers. Instead of detailed wireframes, we provide a clickable prototype which directly communicates the UX behavior we intend for the application.
Creating prototypes in Invision or other tools during the Delivery track also provide tools for quick user testing during each cycle. Having a well established pattern library, as well as visual design standards and guidelines, reduces the time it takes for you and your development team to build basic controls.
Iterative Testing during Delivery
After agreeing on deliverables with the development team, you’ll still need to get feedback from your users. While in comparison to the traditional waterfall method dual-track agile can significantly reduce design and development time, it can also allow features that are not well thought out or important to your users to sneak into the product. That is why it’s critical to involve your users and get feedback during the Delivery phase to prevent features that “seem like a good idea at the time” from getting built.
Instead of developing designs and then immediately implementing them, we suggest creating prototypes and then testing them using the Rapid Iterative Testing and Evaluation (RITE) method. RITE can be done quickly with users on the phone, via conference call or in person when possible. User testing throughout Delivery Cycles is also a great opportunity to involve product managers and development partners in the customer feedback process. Quick training and do’s/don’t’s guides for conducting user-testing sessions can be found online.
One of the pain points of setting up user research is recruiting. In a recent talk, the former Experience Lead for Google Glass, Tom Chi suggested a really useful quick and dirty method for recruiting and rapidly iterating on prototypes. Chi and his team to go to a local mall or shopping center to do their iterative testing. User testing in such locations offers access to the many different user segments and demographics that frequent them. For example, you’ll find teenagers at stores like Pac Sun or Abercrombie or sports enthusiasts at Champs Sports.
After narrowing their focus on a particular user type or demographic, Chi’s team took their laptop to the relevant store and asked passersby to test their prototype in exchange for a gift certificate (following all usual protocols, signing and NDA, etc., we assume). Stakeholders listened via a microphone attached unobtrusively to the facilitator, and changes were made on the fly by developers and other observers. This quick and dirty method reminds me of a college prototyping course which instructed students to test prototypes at local libraries or coffee shops, which made sense since people sitting at a coffee shop usually have spare time.
UI Polish
Dual-track agile’s “fast” development cycles don’t negate the need for UI polish and proper QA verification. As designers, our jobs don’t end with design, or prototype, delivery. Spend some time during Delivery cycles getting involved in the QA process and providing feedback on any areas that don’t match your original designs.
POTENTIAL DUAL-TRACK AGILE PITFALLS
Skipping user research prior to or during Cycle 0.
It’s tempting and easier to start product development by writing a list of product requirements and the jumping ahead to planning for Cycle 1. There are certainly a lot of startups in Silicon Valley that have never spoken to a user before beginning product development. We hear a lot of excuses for not conducting user research including: “I am the user,” “I eat my own dogfood,” and “If Steve Jobs can do it, then so can I.” Sorry to tell you folks, but none of you are Steve Jobs and “You are not the User.” Talk to some real people!
Getting and staying far enough ahead of the development team.
In practice, we’ve found that working a cycle ahead of the Delivery track on more difficult, larger features gives us the leeway to fine tune product requirements with the product manager, sketch a few ideas, refine goals and generally just think through the design a bit prior to prototyping. Often, by the time the prototyping phase arrives, we’ve ruled out a few potential design ideas and, through testing, narrowed down our options to a few ideas for exploration. Being organized, planning and sometimes working ahead is particularly useful for features that may need a little extra attention. Simple, more straightforward features may not require as much preparation. In general, for designers, dual-track agile is an exercise in planning and communication, as much as it is a method for working quickly, iterating and getting user feedback.
If you are new to dual-track agile, try to be as diligent as you can and work as far ahead as you are able. As you can imagine, the cycles may not perfectly match up to Sprints (focused sessions of coding to move a product to the next phase) or whichever your development cycle the team is on. It may take several Sprints to implement one feature in your prototype, so you’ll need to work closely with your development team to plan properly. One Discovery cycle may actually represent two or three Sprints depending on how your the Delivery team has scheduled them. One of our biggest learnings with dual-track agile is to be flexible!
Differing goals and expectations.
Getting stakeholder buy-in prior to implementing RITE and user research in general for dual-track agile is critical. RITE user testing can be quite time-consuming and labor intensive. Stakeholders should be present at every session; if for some reason they can’t be there make sure they stay informed about why updates were made or name representative that can make decisions in their stead.
Keeping everyone up to date and informed avoids miscommunication or disagreement about decisions made during iterations. Read more about these types of pitfalls here.
The TL;DR
When working with dual-track agile development, designers are typically asked to deliver designs in a short amount of time and ahead of the development team. Up-front user research and careful planning can save you a lot of time and headaches. Don’t be afraid to discuss your reasons for devoting time in the beginning to user interviews and the benefits of iterative testing throughout the entire process with your team members. The more aligned you are with the goals of the Scrum and the more open and communicative you are with other team members, the better prepared you’ll be to handle any challenges that may come your way.
