Over the years, I have been involved with very large enterprise digital engagements and more and more IT professionals have been embracing agile methods to make accelerated progress, in shorter amounts of time, to maximize diminishing resources.

It seems as if the term “agile” is permeating more and more content. Usually the term implies “fast” and “simple” without further definition. Many companies think they are agile, when in reality the term becomes a euphemism for repackaging the waterfall status-quo.

Agile has an admirable goal: to break down complex systems to more digestible parts and maximize communications and outputs with a limited set of people. This increases accountability and closes broken communication loops. However, agile methods are driven by IT (developers) and user experience / design resources are unevenly integrated or design is considered outside agile activities.

Design by its very nature is an iterative process and most designers will state that revisions are part and parcel of refining a design concept. I do not think this is only unique to design, as a number of disciplines learn by both trial-and-error as well as learning more about a concept and through that learning, refine and strengthen a desired result.

What is Agile?
The Agile Alliance developed the Agile Manifesto:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

While design is a series of conversations over time, the rigor of agile is a series of daily rituals: of check-ins and check-outs; of tasks and milestones; and clarity of who will do what – when. Core to agile culture:

• the daily 15 minute SCRUM meetings that are
• set within 30 day sprints

SCRUM derives from the sport of rugby, where a scrum is the mechanism for getting the ball moving after it has gone out of play. As one can imagine when developing software systems it can be very easy to deviate and stall a project if there is not constant communication between teams. The facilitator is called the scrum master who continually defines what is “done” and “not done.”

The failure to have and adhere to a definition of “done” destroys transparency, and with it the trust between the stake holders and the developers. Scrum teams that are unable to master the concept and use of “done” will not succeed.
Ken Schwaber

The cycle of agile focuses on:

• inputs from stakeholders
• coordination with a product owner
• facilitated by a scrum master
• daily 15 minute SCRUM updates
• scrum master tracks daily activities in relation to a sprint through a “burndown” chart
• anything that is not completed goes into a sprint product backlog that has task breakouts and who is responsible
• at the end of the sprint there is a team retrospective

Anything not completed in a sprint, is either rolled into the next sprint, or a new sprint is added at the end to focus on any tasks that have not been completed to deliver a fully functional digital system.

To many who may have not experienced a SCRUM or a sprint may think that the conversations are mechanical and predictable. While agile does focus on efficiency of means and clear communications, there is a rich amount of information that is shared by team interactions and facilitated by the scrum master. There is a built in tension between tempo and objectivity and conversation and adaptation and change.

Where Design meets Agile
Both agile and design are iterative. What is defined as “iterative” is where agile and design has to connect. The goal of agile is to constantly communicate, reduce ambiguity and accelerate delivery through a check-in and check-out process. Simplicity, unity, transparency and adaptability are attributes of agile. “Epics”, which are large narratives of what software does are segmented into “stories” that have use-cases. Agile accepts that requirements are likely to change the more things get defined, but the scrum master has to facilitate these issues and clarify and prioritize them.

In experience design and user experience (XD or UX), agile is an accepted methodology as the creation of digital experiences need technical architects and developers to build digital systems. It is precisely the focus on systems and systems design that agile becomes familiar. However, based on my experience, even user experience groups are not included in SCRUMs as it is a ritual for development teams to do, after design has happened. Some user experience groups usually do not like to be pulled out on a daily basis for SCRUMs and their focus on to-do’s.

Cennydd Bowles commented in Getting Real About Agile Design

Agile iterations are planned to create a steady development velocity, but designers don’t always benefit from the same uniformity of workload. . . Designers must let go of perfection to produce rapid, iterative work: “90% right” solutions are par for the course for Agile. This can be counterintuitive, but for better or worse, agile prioritizes the timeline over virtuosity.

In the new millennium, everyone is having to do more with less and try to increase the quality of investment of skills, resources and time. Agile is a reflection of this reality and breaking down complexity into manageable parts and reducing externalities. This is how “done” is defined and has a clear sense of completion. Otherwise there would be no sense of a meeting a milestone.

Development teams have, from experience, a more unified culture based on shared mental models of systems, development and workflows than UX teams.
There have been historical challenges in other skills integrating into agile processes with the emphasis on iterations, and incorporating continuous feedback to sharpen a solution.

The diversity of skills and life experiences of UX teams, while a strength, can also be a weakness when it comes to focusing on agile methodologies. UX teams rely on various tools to create site maps/taxonomies, wire frames and user interfaces. Use of Vizio, Illustrator, iRise, Fireworks, HotGloo, Photoshop and other software tools and suites either emulate, or create digital assets. Unfortunately, since teams are not creating in the final digital environment, they are essentially are brittle simulations, continually obsolete where version control becomes a large problem, especially when it comes to UX documentation.

However, with the continual push forward to rich internet applications (RIA) where software like Silverlight from Microsoft has demonstrated that there is a shared workspace for all teams to create site maps, page types and a reliance on pattern libraries to inform detailed user interface and interaction design. These shared workspaces and tools are bringing business analysts, designers and developers together to create in real time – together.

Possibilities of Agile and Wider Design Disciplines
To many in wider design disciplines, agile terms may come across as mechanical, predictable and boring. Design communities have not really explored or embraced agile methodologies. Many design disciplines are focused on problem seeking and at first glance would not be ready to commit to the daly rituals of a SCRUM.

However, if we revisit the tenants of the Agile Manifesto, a focus on individuals and interactions, customer collaboration and responding to change are very relevant to non-digital design disciplines.  Aspects of agile may be embraced by project managers whose responsibility is to manage time, quality and cost within design organizations and facilitate communications on project status.

The value of design is it’s focus on exploration, discovery and making connections to create new value. Once the exploration moves into specifications/requirements, then a case could be made that the design of systems and agile could connect in a meaningful way.

Hugh Dubberly commented that:

Frameworks suggested by systems design are especially useful in modeling interaction and conversation. They are also useful in modeling the design process itself.

Design does create models and then does a form of modeling. It is this modeling that can be broken down into constituent parts and then prototypes can begin developing systems to satisfy specified requirements of the user.
Since there are many ways to practice design, so many design disciples and hybrid practitioners, it is difficult to imagine a relevant agile wellspring approach any more than there is a unified wellspring of design methods or design thinking.

However, I do believe that design disciplines can move from a purely intuitive, iterative approach to a more disciplined approach integrating certain aspects of agile methodology:

• use a creative or project brief and break a problem response down into smaller parts and develop a daily process for the team to communicate, share and set daily goals
• have a facilitator whose only interest is in the successful completion of a project
• granulize milestones into repeatable daily rituals that increase communication and sharing between teams
• segment “what is known” with what individual team members would like things to be – if things were different”
• segment specifications for completion from identifying opportunities for further value