Spirited Thought

Mark Detweiler from SAP has an exciting article – Managing UCD within Agile Projects – in the May / June issue of interactions. Last year I used SCRUM to manage a small development team on a high-profile project and one of the lessons we learned was that agile development does not work well with disciplines that are not also agile. The development is managed and completed in a series of sprints (we worked three, 30 day sprints) and the application was twitching before any formal UCD work had completed. This challenge applies to more than just User Centered Design (UCD); accelerating development is only so valuable. Detweiler’s UCD centric view offers a series of tips on making a better go at it, but the truth is this problem needs a more radical conception.

Detweiler offers three iterative UCD phases, Understanding Users, Defining Interaction and Designing the user interface. One observation is that UCD teams need to focus their energy on work that influences the current development sprint. Every profession has more they want to do. Delivering it apart form the product development positions their brilliance it to be ignored.

Understanding users is important, but it is not going to hold up development, so what is the minimal amount of work that needs to occur in order to have the development team be more considerate of the user context. Since we are iterating, maybe each sprint has a refinement of the user definition. One thing for sure, the developers will create a user persona if one is not provided.

Defining user interaction has to happen in a more collaborative manner with the development team. It is often just as easy to code the application, as it is to write the use case documentation. This does not mean use cases are a waste of time, but we need to ask what about the document is going to influence development. The time may be better spent with the UCD professional in the initial task breakdown meetings to help define interactions in detail. Having access to a UCD professional as the development occurs helps accelerate decision-making, but the goal is not to have the solution be perfect – it is to have a thoughtful solution, where lessons learned inform the next sprint’s interaction design. The UCD professional needs to own their role representing their stakeholders, but not constantly checking in to see if they are meeting expectations – there is simply no time for checking in and reporting back at every turn.

Designing the user interface as part of an agile development project is difficult. Short of starting this work prior to development, we need to find the opportunity in having the user interface be quick and dirty. An existing design system can address the developer’s need to assemble the application without having to worry about the overall application style. Assuming that a custom user interface is required, the designers need to be in the boat of iterative design. Save the Mona Lisa for a few iterations from now. If you want to influence this sprint’s user interface, worry less about the pixels and more about the styles. Design elements that telegraph where the design will be going. Development is iterative – it is assumed things will change so influence at each point, but save the masterful work for a time when it is not needed yesterday. Great work often takes time; why pretend it can be done in less?

All of this feels a little sloppy and this is why I think what we need is to revisit UCD and maybe the larger thought of user experience and how it is most affective in an agile development environment. This issue is exacerbated in innovation teams where often prototypes catch like wildfire and suddenly a solution with little to no formal UCD thought is at Version 1.0, causing pause to the value and role of UCD. We need to do more than apply more resource or slow down development to accommodate external dependencies. We need to do more than just the same thing in a slightly modified way. To be successful, we need to reinvent UCD or stop being agile.

On the first of February, I accepted a new assignment managing an IBM innovation team – WebAhead. This new opportunity came as part of a reorganization where the Technology Adoption Program (TAP) and WebAhead came under the same manager. My previous work, conceiving and co-founding TAP, is still with me and has become invaluable in understanding the challenges of inventing and innovating and having those outcomes impact the company broadly. Managing technology adoption or as some like to refer to it as technology diffusion is a key part of the mix – both are part of managing innovation, but a smaller part. In my case, I am managing the software development side of an innovation team – a group of developers that sit alongside systems administrators on a raised floor lab with an impressive amount of infrastructure and connectivity. What we work on, how we work on it, which people we collaborate with and when & how we deliver a given technology all determines the gait of innovation and our ability to transform the company – not just through new technology, but through leadership and cultural change. The creative outlook for this team is critical in its evolutionary output and certainly fundamental to its ability to invent completely new systems. Both the managing and creation of innovation is art.

As part of my drink from the information fire hose, I reviewed an article by Lars Erik Holmquist, “Inventing the future.” He presents the notion of predicting the future by inventing it (Alan Kay) and that one way might be to use user-driven innovation, where unlikely (extreme) users are engaged with new technology. (e.g. Find a group of fire fighters and show them a miniature wireless video camera intended for bank ATM monitoring) It is an interesting idea, a brainstorming technique that focuses on a group of like minded people that might think differently about a given technology. The seductive part is that it is an outside perspective that is irrefutably valid, because while they are engaged around the technology they are users of their ideas. Now, of course, this gave me some interesting thoughts around how we might approach some of our resources as define what we work on and how we innovate.

One of the key aspects of the Technology Adoption Program is helping identify, understand and interact with early-adopters, the users of early work. They tend to be a engaged and vocal group, willing to contribute in exchange for access to the latest stuff. Early data analysis confirms our ability to herd cats (early-adopters) and I wonder, what we might find if we repeated Holmquist’s user-driven innovation technique with segments of our early adopter community? This raises the flags of all the usability professionals, “do you even really know what kind of people make up your community?” The answer is sort of, but yes, I agree, we would need to do a deep dive on this. The second thought was, could we build a process and set of measurements around this technique to help articulate the value this method brings? Could we end up being able to compare its relative value to other methods of focused invention and innovation and then correlate when which technique provides the best output?

On any given day the lab is buzzing with the team understanding what it is we are building and the architecture and development that paves the way to get there. I am a believer in the idea that managing innovation is largely an art and in that way excited by the notion that we might create, discover and integrate other “paintbrushes.” While the brush does not make the painter, it can inspire and participate the creation of the painting and the development of the painter.