Human Centered Design vs. Agile Development: Adaptive Balance

“Balancing” (CC BY-NC 2.0) by Pieter v Marion

Find agile government news, case studies, videos, training, and more atwww.agilegovleaders.org.

Across the information technology world there is a tension between Human Centered Design (HCD) and Agile methods. Both methodologies agree in their focus on the end-user and on consistent iteration. However, agile practitioners believe design and development begin at the same time and proceed concurrently, while HCD designers often believe in a dedicated Discovery phase which precedes the beginning of development. In the realm of civic programming or government contracting this tension can be heightened by rigid procurement regulations that require stricter accountability and resource planning than, for example, the world of start-ups.

Some teams attempt to create a separate design and development phase, where user research feeds into full-fidelity designs which are then presented to an Agile development team for implementation. But such a strong divide between design and development looks suspiciously similar to a Waterfall model. Waterfall methods, which emphasize clear separation of phases, are risky and lead to very low success rates. Agile methodologies seek to reduce or eliminate inefficiencies in the Waterfall model by increasing collaboration and keeping team members aligned throughout the product development cycle.

To better understand the ideal relationship between agile methods and Human Centered Design, let’s start with clear definitions.

What is Human Centered Design?

Although there are other explanations of HCD, the British Government Digital Service (GDS) clarifies it well:

The design process must start with identifying and thinking about real user needs. We should design around those — not around the way the ‘official process’ is at the moment. We must understand those needs thoroughly — interrogating data, not just making assumptions — and we should remember that what users ask for is not always what they need.

— Gov.UK Design Principles

What is Agile?

Agile is best expressed in the tenets of the Agile Manifesto:

We have come to value…

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Note that the word “customer” should be interpreted to include the end users, and a true agile process will involve real users throughout the development cycle. In terms of government contracting, the agency sponsors and administrators must also be considered real users, but administration is a necessary servant of the customer. Since the end user is usually not paying in a government contracting situation, it is all-too-easy to start building for the paying client and not the actual end user; this is a fundamental error.

What is the relationship of HCD to Agile?

The main difference between HCD and agile is how and when various staff roles are applied to a project. This is depicted in the diagrams below, which show possible staffing of designers and developers over the lifecycle of a project in each of the two approaches.

HCD suggests a discovery phase with limited or no developer involvement:

Whereas Agile specifically calls for a smooth, continuous process with developers and designers constantly collaborating:

The British GDS seems to work in a hybrid, intermediary way. It highlights these key points:

• A new way of doing things: “Building and testing in small chunks, working quickly to deliver improvements to a service. Teams will work out how to best meet the needs of users, releasing code regularly and working in an Agile way.
• Users are involved throughout design and development.
• Phased Development: Working with users from day one, establish key performance indicators (KPIs) in your discovery and alpha phases. Then move on to rapidly releasing updates and improvements into the development environment, and measuring the impact of your changes.

This hybrid model is depicted below:

What are the implications of these approaches?

Agile processes are widely considered more successful than Waterfall approaches. Considering Agile from the viewpoint of Human Centered Design raises some subtle questions:

• How do we create working software without first having a design?
• Does an iterative process imply that the design is changing equally in the first and last iteration?
• Does the balance of talent change through the product development cycle?
• If you are always changing what you are doing, doesn’t that waste a lot of time?

We assert the following practices allow HCD and Agile to work together effectively:

• Ruthless iteration that places no value on previous coding prevents early coding from twisting a project away from user needs.
• User research is always required — and the more innovative your project, the higher should be the percentage of labor dedicated to user research.
• An ideal team has a balanced set of skills.
• Agile methods support and complement Human Centered Design, so long as there is mutual respect and sufficient common understanding between the engineers and designers.
• Teams should work smoothly and flexibly.
• Each team member must be flexible in supporting the changing demands on the team as a whole as the project evolves.
• Measure productivity by value, not volume.The team as a whole must be prepared to learn that a shift away from a current implementation in response to something that has been discovered is a change for the better.

Now let’s examine each of these ideas in order to understand them better.

Iterative Process

An iterative process allows code to be developed hand-in-hand with the design process, especially if the early prototypes are considered disposable throw-away sketches. Design sessions will ideally include developers, the people who will use the services, and designers who are expert at engaging users and interpreting qualitative feedback. As the software is developed, designers review changes regularly and the whole team participates in validating the service with real users.

The more innovative your project, the higher should be the percentage of labor dedicated to user research.

Some challenges, such as making a high-demand software component perform faster, require little user experience design, yet can deliver high impact results. The ultimate user experience can be directly improved in such a case, primarily through coding and very little design. However, much more commonly, problems require careful research into what the user’s true needs are. This is especially true when building an innovative or disruptive new service. There is therefore a spectrum that runs from highly disruptive projects with unexplored user needs to problems in which the user interaction is well-understood. User-centered research can discover needs in unexplored territory. The more radically innovative a project is, the higher the percentage of our overall energy must be spent on learning and validating our assumptions.

A balanced team should have about the same number of user-facing people as software engineers.

In modern agile practice one is tempted to say that everyone on the team is user-facing. However, agile pioneer Kent Beck has expressed that the number of “customer-facing” people — meaning product managers, quality assurance engineers, and user experience designers — should be approximately equal to the number of developing software engineers.

In commercial industry, there is often a tendency to have too many programmers, perhaps because there is a sense in which it is easier to measure and believe in what programmers do. However, more lines of code do not directly translate into a product that better meets user needs and business goals. The only measure of productivity that matters is user satisfaction. Creating products that effectively meet the needs of customers is more important than doing the wrong thing energetically.

The British GDS says there is no hard rule on team composition, but implies that the skill set must be balanced:

“There is no hard and fast rule on the roles or team structure needed to fulfill these functions, but a core team will probably consist of:

• a service manager (the ‘product owner’)
• probably supported by a product manager
• supported by one or more digital performance analysts
• a delivery manager
• a tech lead
• one or more designers
• one or more user researchers
• one or more developers
• one or more content designers
• the support of a technical architect
• the support of some web ops expertise

On some smaller teams, which may include some people wearing many hats, the programmer may also be doing user-centered design. The point is to balance the energy spent in activities more than to balance an absolute headcount, which is often controlled by executives who do not have the freedom to move people as fluidly as would be optimal.

Agile methods support and complement Human Centered Design, so long as there is mutual respect between the engineers and UX designers.

Mutual respect requires a shared vocabulary and an understanding of the training, working methods, and motivation of each team member.

For engineers to respect the customer-facing people means that they diligently and creatively write code so that the designers can test hypotheses and try out ideas as early in the project as possible. They must consider not only final goal, but how to produce something testable that the designers can evaluate and use as early in the project as possible.

In the past, there was a tendency to allow code to dominate the project direction once it was written, because code is so hard to change. Developers, however, must be willing to throw away code and prototypes for the sake of evolving the project in the direction that brings value to users. They must submerge their egos and not slavishly follow initial ideas even if embodied in code and seemingly very valuable.

User facing people must respect engineers by creatively compromising about the fact that the product available in the first and early sprints is clearly going to be limited. They should apply the creativity to find implementable solutions that can be usefully tested with users early in the process.

Teams should work smoothly and flexibly

Managers should respect the natural ebb and flow of various types of labor at different stages of the project, reducing turbulence and inefficiency by providing natural ramp-up and ramp-down of talent.

In an ideal agile world, software is produced continuously and smoothly. There are no death marches, no dramatic release points, and no deadlines.Each project cycle, whether a simple 2-week iteration or a huge multi-year project, is gently ramped-up and ramped-down so that it flows smoothly into the next.

But this ideal is rarely achieved, particularly in government, because the acquisition process tends to drive acquisitions into chunks. The Federal Acquisitions Regulation (FAR) prioritizes fairness over convenience. It aims to promote unbiased competition, which necessarily entails a certain amount of formal process, compelling the program manager into blocking work into large “chunks”.

Nonetheless, it is the team’s responsibility — and in particular, the executive’s — to strive for a smooth ramp-up and ramp-down of resources.

As the project evolves, team members must be flexible in supporting the changing demands on the team.

In a perfect world, a manager is able to smoothly reorganize team composition to align with changing needs. Government contracting rarely gives program managers this ability. The team can assist in obtaining an ideally smooth project by shifting roles slightly. In a well-run, continually evolving project that might mean growing its user base or contemplating new feature sets. Sometimes, there is just as much user-centered design work happening in the latter sprints as in the early ones, or as much programming in the early sprints as in the latter. But if this ideal is not obtained, the team can still adjust as much as possible by assisting each other around the needs of the moment, having each member participate in functions which are not their typical role, if necessary.

Measure productivity by value, not volume.

Because productivity is measured by the quality of the user experience, designers need testable functionality and developers need to find a way to deliver that functionality so it can be experienced and validated by real users as early as possible in the project. Designers must test and validate assumptions before complete functionality is delivered.

A number of pitfalls can lead to a poorly-run HCD/Agile project. For example, developers sometimes do not produce testable functionality early in the project — either because they are giving technical problems and architecture higher priority, or simply can’t conceive of how to produce early testable functionality. This problem is represented by the red line in the graph below. It is a fundamental mistake because it gives the designers nothing to test with the users. It prevents iterating the design. It is the responsibility of the developers to use all of their creativity to produce the green line instead. This provides a high value of testable functionality to users as soon as possible.

The magenta line represents Waterfall development. No user feedback is obtained until the end of the project. The magenta line might not quite reach the “releasable product” point, because many Waterfall projects fail to release anything at all. Then, when it is too late, knowledge of user’s real needs becomes drastically more apparent, much as a student’s understanding of physics shoots up drastically in the 20 minutes after a final exam.

The team as a whole must be prepared to learn that a shift may be required away from the original intent and toward something that has been discovered to be even better.

The diagram above makes it look like testable functionality and wisdom increase smoothly hand in hand over time. In general this is true, but the team must be prepared to execute on drastic problems or unexpected opportunities. For example, the team may learn halfway through the project that a vastly more awesome opportunity exists. It can take courage to recognize and validate such an occurrence, which we call a “transformational pivot”. It requires you to admit that much of the work you have done so far is only valuable in teaching you your current path needs correction. Nonetheless, the only effective thing is to immediately begin working in the best interest of the user.

By following the suggestions above and keeping users first, agile teams can work together — even in difficult government projects — to successfully meld the tenets of agile methods and Human Centered Design.

About AGL:

Agile Government Leadership is a group of agile professionals bringing government experience and perspective from federal, local, state, and industry. You can visit our website for free resources, news, training, case studies, and more: www.agilegovleaders.org