After an appearance at last year’s UX Week, Cameron Gray, Vice President of Engineering at online training experts Mindflash will return to our stage at this year’s MX Conference with a talk about Agile and UX.

As a design process freak, I jumped at the chance to interview Cameron and ask him about the way he is integrating UX in Mindflash’s Agile development methodology.

[Peter Boersma] You (re)joined Mindflash almost 4 years ago, after a 4-year stint at another company, and run the development team. What have you changed to the way that team is managed? What do you want to change next? What are your top priorities at the moment?

[Cameron Gray] When I rejoined Mindflash the development team was only handful of people. They had little to no process nor did they really require any for the volume of work that they were doing. When I looked at what it would take to build a new product I knew we would need to hire a significant number of new developers and create a process for product development. After analyzing the business environment I decided that building an Agile process using Scrum made the most amount of sense. In the first 2 years I tripled the size of the team and we created a very efficient Scrum process made up of three teams working in 4-week sprints.

As for the future, our process is fairly mature at this point so I am really not looking to make any radical changes. Because our team is about two thirds remote we are always working on ways to improve our communication. We are also spending a fair amount of time working on further integrating the Product and QA teams into our process. I would say currently my top priority is to maintain the current velocity of the team while still providing an environment where people can grow their skills and learn from each other.

[PB] How do you feel about the explicit need for expertise on Agile teams; it seems there is no room for junior Agile team members; everyone is expected to know a little bit about most, if not all, aspects of developing the solution. Is that how your development team is built-up?

[CG] One of the significant challenges with Agile is that the teams are effectively self managing. This can present an issue when you have a significant number of junior team members. At Mindflash.com we do not have layers of management within the development organization so everyone is responsible for ensuring that they are writing code up to the standards of the organization. For the more junior folks, this means they have to ramp up their skills very quickly and work closely with the more senior members of the team. We are definitely heavily weighted on the senior side of things but I think that is generally appropriate for any team as small as ours. The important thing to remember is that Agile is a prescription for product development not for people management. As a manager you still have to do all the normal things to foster skill and career development within your teams. At Mindflash.com we do a lot of mentoring between team members as well as providing tools for things like code and design reviews. We also do a fair amount of pair programming, particular when working on more challenging problems.

Agile is a prescription for product development. As a manager you still have to do all the normal things to foster skill and career development…

[PB] In your opinion, does Agile work better for new or established products? The experts seem to disagree: Some say it’s best for established, or operational projects: Agile web development - how do you get there (3rd comment), others say it’s made for new products: Deciding what kind of projects are most suited for Agile (“a high degree of novelty”). Does Mindflash work on new products the same way as it does on maintaining its existing product(s)?

[CG] At Mindflash we have used Agile for both new and existing products. We have built our entire team around using an Agile process so it would be very difficult for us to switch to another process on a per project basis. We have found some challenges in building new projects using an Agile process. The main issue is that Agile is about delivering incremental product improvements. When you are first starting on a new project there isn’t much to improve upon. We found it was critical to create a feedback cycle very early in the development process when working on a new product. When we first started on our current product we would do usability testing and user research using a combination of wireframes and the latest code at the end of every sprint. While this was a somewhat cumbersome process it did allow us to validate our early work in the context of a more complete user experience.

[PB] What is “Good Enough” for UX? (See: Defining good enough for an exploration of what is “good enough”.) To adhere to Agile principles (like “working software is the primary measure of progress”) does UX work need to be shared and implemented in software in an ‘unfinished’ state?

We involve everyone in the entire company in user research and findings distillation.

[CG] At Mindflash the bar is definitely higher then working software being the primary measure of progress. User Experience is the responsibility of everyone on the team, not just the product owner or design team. We involve everyone in the entire company in user research and findings distillation. This gives the entire team the tools they need to evaluate the work they are doing with a UX perspective. We also do a great deal of what Joel Spolsky refers to as “Hallway Usability Testing”.

Hallways (for short) are when a developer grabs a handful of people from product, design, QA, and anywhere else in the company, to walk them through an in-progress user story. This is a point where the evolving user experience can be evaluated before it is too late to change course or make improvements. We view user experience the same way we view quality assurance, if it does not pass it does not ship.

In Agile, while you cannot lengthen a sprint you can always push a story out of a sprint. On several occasions, we have pushed a story out of sprint and taken the hit on our sprint velocity because we could not deliver an acceptable user experience. It is always preferable to us to not release a user story than it is to release an inferior experience.

[PB] In your experience, how much up-front design is required? The danger of diving right in is that “you can end up with a product broken into lots of little stories, each of which have small designs, but you have no coherent vision.” (a quote from Experiments and experience from the UX/Agile divide)

Does the design need to be good enough at a local level and then ‘refactored’ at a higher level when enough bottom-up design is done, or is BDUF (Big Design Up Front) an option for Mindflash?

[CG] At Mindflash we are fortunate that because of our small size we are able to simultaneously have a coherent long term vision and deliver several small stories. The product team does a great job of maintaining the long term vision and roadmap while still delivering digestible user stories. We typically find the place where “BDUF” is required is when there is a good deal of stakeholder contention. In these cases a more complete design, that may span several user stories, is required in order to evaluate whether or not we should take the product in a certain direction. We typically do just enough up front design that a user story can be estimated by the development team and evaluated, for relative priority, by the stakeholders. I have found that letting design evolve simultaneously with code being written is extremely useful because the two exercises give each other context. This can present challenges for sure, especially because our development resource vastly outnumber our design resources.

[PB] Last year, at UX Week, you and Adaptive Path’s Paula Wellings presented the 5 critical moves to change the company from a developer-driven organization to the UX company (here’s the video of that presentation), the last one being “you still need pros on board”. By that time, you had hired at least one UX practitioner who took part in the daily stand-ups. What is the situation now?

Our in-house UX designer personally evaluates every user story for the less tangible awesomeness factor…

[CG] Our in house user experience designer, interaction designer, user researcher, and part time visual designer (he likes to remind us that he is not a visual designer), IX (yes that is his name) is still with us and still an active member of the scrum teams. We do joke that in the later half of the sprints his scrum report is always “I have nothing to report”, but he plays a key role in shepherding the user stories to completion and ensuring they meet our standards for delivering a quality user experience. He also personally evaluates every finished user story for the less tangible awesomeness factor which is critical. We have also brought in Leonard Tancuan (formally of eBay and Shutterfly) as our VP of Product as well as Aaron Forth (Mint.com) as a member of our advisory board. We are also actively looking for a permanent visual designer so IX will stop his complaining.

If you want to hear Cameron speak (or any of our fabulous presenters), make sure to register for MX 2011 (use the code BLOG for 10% off).