Is your software development a linear conveyor belt of bottlenecks?
This post describes my experience mixing Agile + User Experience design while building out the mobile site for thoora.com. While this process worked for us, it won’t work for everyone/every project, however it allowed us to minimize blocked tickets and maximize the time of our small development team. Breaking the work into manageable stories, and parallelizing the work early and often is a great technique to maximize output and manage the traditionally serial and inherently blocking jobs and responsibilities when mixing UX and Agile methodologies.
What I love about Agile software development is the flexibility and uniqueness of the process to each adopting group. When people try to make sure they are following the Agile process to the book, to me, it misses the point. If it doesn’t work for you or your team, then change it and iterate on your process until it is perfect (how agile). A great topic of discussion is how Agile and User Experience design can blend. Many argue that it is impossible, many say that it blends well. Again, it is up to the team, environment and company. While at Thoora, my frontend team used a process which maximized output and minimized blocking tickets, and idle cycles. I’ll be focusing this post on the integration of traditional Agile concepts and aspects of UX design and development. The housekeeping tasks of Agile process are not discussed, but were used. Similarly, some of the preliminary requirements gathering, planning involved with a more holistic UX approach were used, but not discussed here.
The Participating Roles
-Product/Program Manager (me)
-Front-End Engineer (@kenstruys)
-Visual Designer (@PauloArtista)
The whole team was multi-disciplinary: I was officially the Program Manager, and took on many of the UX tasks, product planning and interaction with business stakeholders. The F2E took charge of all the technical considerations including development and deployment. The visual designer controlled the pixels that we were to push out, and what the customer eventually saw. Working on a 1 week iteration, the biggest fear I had was blocked tickets/idle cycles. In a traditional waterfall model, we would see a lot of upfront requirements, designing and specs before a line of code. If we really silo each role, this model leaves the developers waiting as long as 2-3 sprints before they can code. I HATE IDLE CYCLES FOR MY TEAM!
Planning Ahead
The primary business/user requirement was simple, provide a mobile experience for the existing core website. A list of basic functionality, sitemap, flow was created, and simple wireframes were drawn up. Team members reflected on these “plans” pointing out immediate problems, and ensured the primary objectives were being met. The overall preliminary ux artifacts and activities were owned by the Program Manager, but it was a team effort. This whole activity resulted in rough plans for the project, rough functionality and “look” (but not yet “feel”), enough to start breaking up the work.
Iterate often, do work in parallel, merge when possible
Getting the Train Moving
The documentation was far from complete, but good enough to get started. These plans gave the F2E enough info to prep an environment, fork the code base, make preliminary deployment considerations and perform any needed technical research given the scope of the audience and project: Where should we fork off the main code branch? How/Where are we going to detect the mobile browser? How are we going to test this? Which machines will this code sit in?. The flows, sitemaps and wireframes were enough to begin the first iterations of mockups, and interaction design considerations: What is this going to look like? What phones are we supporting? What is the primary interaction method? How big are my targets going to have to be? And lastly, these initial plans were enough to go back to the primary business owner to ensure all the goals/requirements were being captured.
Working in Parallel
The previous step only took a few days. Updated wireframes were now available, and the real fork of work was ready to happen. This is where I feel like we gained a lot, and maximized the use of the time of our small group. The wireframes + flows were sufficient “specifications” for the developers to implement a functional “shell”, which looked rugged, but was functionally complete. The same wireframes were the input to the visual designer who could now concentrate on the look and feel of this mobile user interface. Time boxing into 1 week, the plan was to see the results, and iterate on any changed requirements.
Pulling it Together
There were a few new business requirements, there were some discovered usability issues, so we iterated on the initial designs and moved forward. At this point we had a functional shell and nearly complete and up to date mockups. It was time to merge. The mocks were given to the frontend developer whose shell was up to date with the visual designer’s mocks, thanks to shared wires. The shell was coded very flexibly so the look and feel was really a matter of skinning the existing site. Collaboratively, all members were able to test the final output. In addition to the testing suite which was originally created at the start of the project, each member applied their own focused testing suite. The developer tested many devices and browsers, edge case and redirect rules, and webserver settings. The visual designer tested the pixel precision (with some threshold) of individual screens, and ensured the site reflected the overall company brand. The PM looked over the site ensure all the original requirements were matched, and that everything in the original wires and flows were implemented.
Some Final Thoughts
This process worked very well for us. With open communication, every participating member knew what was going on, and what they needed to get done. This project went on as all participants juggled other existing projects. A good schedule, and well chunked blocks of work was very important. The artifacts (sitemaps, wires, mocks etc) were as up to date and “alive” as long as they needed to be. While this may be more rigidly structured than some UX practitioners may like, this process was applied in an environment that wasn’t particularly UX focused, so it was a nice middle ground. We chose a process that worked best for us, and fit the project. We wanted to minimize the amount of blocked tickets, and it worked. By forking as early as possible, we rarely heard the dreaded “I’m waiting for the ___ from ____”. By splitting up the work load, working in parallel and merging when appropriate, the train was always moving.
Ian Chan's Blog 