Allaland

Posts Tagged ‘agile

Working in Agile

So now that you have a definition of agile and some of the underlying principles, how do you actually do the work?

First, it is important to understand that you are not trying to squeeze UX into an agile process, but rather attempting to make the UX process more agile. This will mean being flexible, innovative, and nimble with established UX techniques.

The role of UX

UX practitioners are most successful in the customer role on an agile team. Remember, that customers mean something different in agile, a customer is not someone who is external to the product team who purchases or uses the product. A customer is a role filled by one or more members of the product team, whose duties include acting as the voice of the end-use for the development team, and helping to prioritize and plan.

The customer defines the software, and determines what stakeholders find valuable. The recommended ratio is 2 customers per 3 developers, this means that there are 2 designers for every developer. Designers can be of any combination: UX, Usability, IA, Visual, IxD – whatever is needed to accomplish the project. The customers most important job is release planning which includes:

  • Evangelizing the product vision
  • Identifyng features and stories
  • Grouping features into small, frequent releases
  • Managing risk
  • Creating an achievable plan

In order to be able to achieve the above, I would recommend starting with:

  • Small, clear, and achievable goals
  • Letting go of control, and allowing your team help with some of the activities
  • Get “good enough” information, and continue to learn throughout the entire project, rather than trying to figure out everything up font
  • Be honest with yourself and work towards continual improvement

The Process

The process that has worked best for me was first described by Desiree Sy

The structure basically asks you to:

  • Gain initial insights through a short up-front discovery stage
  • Get just far enough ahead of development that you are not a bottleneck
  • Continually talk to users every iteration to get feedback and more in-depth insights
  • Start rough and refine as you go along. utilizing lightweight techniques like sketching
  • Establish a clear vision that you are working towards and iterate on the vision as you learn more information

It is important to understand that none of these activities are happening in a bubble, you as the designer are not going off to complete the work and then presenting a finalized design. Rather, you are sketching, concepting, and getting feedback from your entire team along the way. The feedback can be informal or a design critique.

Also, working in this rhythm or cadence will feel uncomfortable at first, and you might have the urge to resist, but stick with it and allow this rhythm to become the “new normal”.

Here are some common objections/questions that I often hear from designers and quick answers:

1) How many projects should a UX designer be on if the company adheres to an agile process?
Answer: ONE. Agile is specifically designed around the team dynamics, and its difficult or impossible to create the proper rapport if you are not sitting and working with the team.

2) Agile methods do not provide enough time for UX practitioners to conduct necessary research and discovery.
Answer: Agile methods do not provide enough time upfront to conduct research, the methodology assumes that you are doing the research and discovery on a continual basis, in every iteration. This not only helps keep the information fresh in your mind, but also allows you to dig deep into questions that arise once you start really trying to solve the problem (later in the project), rather than identifying the problem (as in the beginning of the project)

3) If I break up my design into pieces that can be fit into an iteration, it is difficult for me to picture the holistic system
Answer: Sketch your initial understanding of the holistic system using a storyboard, then begin to dive deep into the parts of the system that are prioritized for the upcoming sprint. Your understanding of the system will change over time, so utilize a low-fidelity medium to capture your current understanding and then update as it – and your understanding – changes.

4) Some designs are too complex to fit within one iteration
Answer: Break large designs into small, cycle-size pieces called design chunks that incrementally add elements to the overall design over several iterations. Whenever you design, you have to start somewhere, start in one iteration and incrementally add complexity / layers in subsequent iterations.

5) There is not enough time to conduct formative usability testing and then create a usability report.
Answer: Employ light-weight usability techniques, and progressively engage in defining test protocols and recruitment.

6) Working software over comprehensive documentation means no more wireframes or mockups
Answer: Use the tools that will help you and your team produce good work. There is no set “way” to do thing, figure out how best to communicate with your team, and which tools help you produce great work in an efficient way, then just do it!

Advertisements
Tags: ,

Defining Agile

Agile has recently become a hot topic, both organizationally and in the design world. Several articles have attempted to describe agile, and how to fit design or UCD into an agile development:

Bringing User Centered Design to the Agile Environment by Anthony Colfelt, published on Boxes and Arrows
How UCD and Agile Can Live Together by David Farkas, published in Johnny Holland

Although they provide a really good high-level overviews, they still seem to miss the mentioning the fundamental essence of agile – agile is philosophy or a mindset, not a set of methods or practices.

There is a lot of confusion between agile, scrum, and xp. Many times people refer to agile as the agile method. There is no such thing! Agile is a set of principles, and scrum or xp are defined practices that uphold agile principles.

So what are the agile principles?

In 2001, a group of developers came up with the agile manifesto, which outlines the four values of agile:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

In practice, these translate into the following

  1. Great products come from great teams
  2. Go to high function fidelity quickly, provide just enough documentation to produce great work
  3. Involve the end-users, decision makers, and stakeholders throughout the entire process
  4. Be ready for change, be it from the client, the market, or anywhere

As designers, constant communication, negotiation and feedback has always been part of our values and processes, but developers have been notoriously bad at such skills, which is why so many of the values center around communication. The most important value, and the core of agile, for both developers and designers is #4. Expect change, be ready for change, change is okay. Designers, like developers, do not deal well with change. Heck, human beings in general don’t do well with change, especially the last minute kind. However, if you go into a project with the mindset expecting change to occur, you will be much more prepared to be agile or nimble and handle it accordingly. In my opinion, that is the most valuable contribution of agile to both design and development.

Tune in to Part 2, Scrum in Plain English, coming soon!

Tags: , ,

Having recently worked at a few companies that are fully agile, meaning both design and development follow agile, versus just development. I have really come to understand the benefits of agile, and you might say, am definitely drinking the agile cool-aid.

One of the things that I like best about agile is the notion of pair programming. I have often watched a pair of developers work together on a bit of code, and was silently jealous because I wished I could have a partner for design! In all of the places that I have worked – even if there is a design department – only one designer gets assigned to a project (unless it is extremely large). So the designers rarely get to work in a team, and are often isolated within their individual projects.

I think perhaps that its time for the design industry to take a cue from agile development and consider pair design.

Let’s take a step back and look at why pair programming works? From Wikipedia, here is a list of benefits for pair programming:

  • Design quality: Shorter programs, better designs, fewer bugs.Program code must be readable to both partners, not just the driver, in order to be checked in. Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects very early.
  • Reduced cost of development: With bugs being a particularly expensive part of software development, especially if they’re caught late in the development process, the large reduction in defect rate due to pair programming can significantly reduce software development costs.
  • Learning and training: Knowledge passes easily between pair programmers: they share knowledge of the specifics of the system, and they pick up programming techniques from each other as they work.New hires quickly pick up the practices of the team through pairing.
  • Overcoming difficult problems: Pairs often find that seemingly “impossible” problems become easy or even quick, or at least possible, to solve when they work together.
  • Improved morale: Programmers report greater joy in their work and greater confidence that their work is correct.
  • Decreased management risk: Since knowledge of the system is shared among programmers, there is less risk to management if one programmer leaves the team.
  • Increased discipline and better time management: Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email,or other violations of discipline, when they are working with a pair partner. The pair partner “keeps them honest”.
  • Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, “What were we working on?” Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working.
  • Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
  • Decreased risk of RSI: The risk of repetitive stress injury is significantly reduced, since each programmer is using a keyboard and mouse approximately half the time they were before.

The list above can easily be viewed from a designers perspective:

  • Design quality: Pairs typically consider more design alternatives than designers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects or usability problems very early.
  • Reduced cost of redesign: With design flaws or usability problems being particularly expensive, especially if they’re caught late in the product development process, the large reduction in flaws can significantly reduce costs. Furthermore, having a pair of designers explain the reasoning behind a design is much more powerful and convincing, and may lead stakeholders to request less redesign.
  • Learning and training: Knowledge passes easily between pair designers: they share knowledge of the specifics of the system and domain, and they pick up design techniques from each other as they work.New hires quickly pick up the practices of the team through pairing.
  • Overcoming difficult problems: Pairs often find that seemingly “impossible” problems become easy or even quick, or at least possible, to solve when they work together.
  • Improved morale: Designers report greater joy in their work and greater confidence that their work is correct.
  • Decreased management risk: Since knowledge of the system is shared among designers, there is less risk to management if one designers leaves the team.
  • Increased discipline and better time management: Designers are less likely to spend time web-surfing, tweeting,or on personal email,or other violations of discipline, when they are working with a pair partner. The pair partner “keeps them honest”.
  • Resilient flow. Pairing leads to a different kind of flow than designing alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, “What were we working on?” Pairing flow is also more resilient to interruptions: one designer deals with the interruption while the other keeps working.
  • Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
  • Decreased risk of RSI: The risk of repetitive stress injury is significantly reduced, since each designer is using a keyboard and mouse approximately half the time they were before.

Pair design, think about it!

There has recently been a lot of discussion in the UX field about Agile and how we can integrate our work into the process.

Here are some interesting discussions:
Agile & UX on IxDA List
Leah Buley’s post on Burndowns and Flareups in Agile

In my experience working in an Agile environment at THE_GROOP, I feel like Agile can work, but it ultimately depends on your constraints – clients, time, and resources.

What Works:

  • Having a Sprint 0 for UX strategy/research before design and development. This is the time for ideation, sketching, and research. This strategy phase is vital to providing the ground work for the rest of the project.
  • Writing out the tasks that need to be completed per sprint, and including iteration as one of the tasks. This allows the designer to get both a broad view and detailed view of the project. It is incredibly helpful to lay out all the tasks that need to be done in a concrete way. By going through this activity (however painful and tedious), it forces you to see what you *don’t know* upfront and then plan accordingly. This is also a good time to talk to other stakeholders and figure out how much documentation is necessary. If the developers don’t want an annotated wireframe, then don’t build it into the schedule.
  • If you do the Sprint scheduling with other stakeholders like visual designers and developers, it is really easy to coordinate activities, find out where we can all work in parallel, and also surface the dependencies.
  • Burning down at the end of each day feels great (for UX as well!) You also quickly learn how long it actually takes you to do things, so that you can estimate better on the next sprint.

What Doesn’t Work:

  • Clients often want to see progress each day/week. Once they see initial design ideas, they have a difficult time letting go (no matter how rough the sketch). This makes it VERY difficult to iterate, or “throw away” designs.
  • Aside from clients, time constraints often also restrict design iteration. Unlike code, which could potentially be thrown away and written in any number of ways to do the same thing (with most clients non-the- wiser), design is much more “sticky” because it is so visual. Once you start on a path, you are pretty much forced to continue going down that road. It is almost impossible to completely throw out a design that “just didn’t work” and start from scratch. This is especially true since developers and designers are dependent on the UX work to move forward, so once the ball is rolling, its hard to stop.
  • There is practically no time for user research/testing after Sprint 0. You basically have to fit it in guerrilla style (after work or during lunch utilizing fellow co-workers), which doesn’t give you great results or confidence

In general, the visibility of UX work makes it very difficult to generate new ideas, conduct proper testing, and iterate on designs. However, it does force the designer to plan ahead, and get to know themselves a bit better. I do believe agile can work for UX, but perhaps a modified version that takes some of the problems into account.

I am still going to be thinking and developing my ideas about this topic as time goes on, but these are my initial impressions. Will be interesting to see how things change over time!

Tags: ,

Alla Zollers

I design products and services that just. make. sense.

When products make sense, customers are happy.

If customer are happy, they sign-up, stay on site, engage, share, and buy your product or service.

Happy customers allow companies to profit in both senses of the word.

I provide the following services:

• Heuristic Evaluations
• Discovery Research
• Strategy and Vision Development
• Information Architecture
• User Experience Design
• Usability Testing

You can find me on:
Twitter
LinkedIn

Twitter Updates

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Archives