Full disclosure: I have about 15 years of additional work experience than most of my Genius.com developer compatriots. For better or worse that gives me a wealth of exposure to many project management styles that all boil down to variants of the waterfall approach.
Overview of Genius.com Agile Adoption
I work as a visual and user interface designer with the Genius.com development team. As we began our transition from waterfall to agile, I immediately found aspects I really liked and some that, from a user interface/interaction perspective, seemed problematic.
The great: team collaboration, rapid development, flexible process, designing to reality vs. designing to the plan, constant customer interaction and feedback.
The problematic: not enough big picture view of user experience, not designing user workflow across the entire application, not enough time for research & testing, segmented development of features often left UI inconsistent across the application.
Improving Agile User Interface Design
Luckily the inherent collaborative nature of agile processes (at least as practiced at Genius.com) allowed these issues to surface in sprint planning and, although we have not solved all of them, we are continually developing practices to allow for better a UI.
Developing the UI and the logic coding for a user story in one sprint put pressure to do the simplest UI possible, not necessarily the best or most consistent. Often, in the narrowed focus on individual features, the workflow of the user though the product was not adequately considered. To allow for better consideration of consistency and broader implications, we developed our backlog “Meet and Greet” where user stories are presented at least a sprint (preferably more) before a story is considered for inclusion in a sprint. This preview of upcoming stories allows the team (including the UI group) to begin considering options and reviewing successful examples of similar functionality before we focus on the details required to implement an individual user story.
Having the UI group involved with creating user story acceptance criteria allows us to bring up UI dependancies and warn about the user interface and user experience ramifications of a given feature so that those design criteria become embedded in the user story that is eventually committed to and developed.
Agile User Interface Prototyping
Originally, prototyping was done in Adobe Photoshop with actual application UI elements imaged as single screen shots. This resulted in mock-ups that fostered a false sense of completeness and limited objective input. Now, for complex new features, we begin with wire-frame models and make interactive HTML models to envision the user workflow before working on the actual look/feel of the UI elements. This allows for initial feedback focused on functionality and interaction instead of aesthetics.
To get a better sense of the full user experience, at least while considering the UI impact of user stories, we link appropriate user stories together to consider the whole flow of a process while planning and sizing.
Has the conversion to agile processes been smooth at Genius.com?
Like most organizations, and any successful agile implementation of which I am aware, there certainly have been bumps in the road and detours taken and abandoned. Individuals have embraced the agile methodology at different levels and paces (more on that in another future post). We still occasionally wrestle with things like the big picture vs. the current sprint.
However, we have learned one thing: successful implementations of agile are non-dogmatic. At Genius.com, our agile implementation is collaborative and flexible enough that we can easily adapt guiding Agile principles to our organization. Whether ideas come from Lean, XP, Scrum or the big brain of a team member, we are not afraid to try something different. If it fails, we ditch it. If it succeeds, we embrace it. Either way, we constantly look to improve the way we work.