By Ian Steyaert, Program Management Director at argo
Agile process has evolved into a cliché in product development nowadays, though few companies do much more than pay lip service to the concepts. To truly embrace Agile Product Design it’s important to follow four key tenets that will make any project better:
- Individuals and interactions over processes and tools
- Working product or software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
But why do these principles fail to take hold so often? It’s typically due to lack of leadership buy-in. The cultural shift required for leadership to trust a team of individuals and interactions to self-organize and work efficiently poses a real stumbling block for many organizations. Command-and-control culture still dictates following tried-and-true steps. And how can a VP confidently sign off on a budget for a product that doesn’t yet have comprehensive documentation and a thorough plan?
These questions drive the fear around adopting Agile, and frankly represent some legitimate concerns. Fear-driven behaviors undermine successful implementations and keep design teams from excelling, but if you spot the warning signs early in the process, you will have a greater opportunity of implementing a solution that gets everyone back on track.
[Related: 4 Web Technology Trends Designers Need to Focus on in 2017 | Creative Leaders—Ask Yourself These 4 Questions]
Mistake #1: Over-Controlling Your Design Team
The first product team I led ended in disaster. I felt it was my responsibility to manage people’s’ time, give them great ideas, and tell them the tasks needed to finish the job. My passion overwhelmed the project and, as a result, no one else felt ownership. While the result was a forward-looking concept that reflected hundreds of hours of work from dozens of individuals inside and outside of the company, we ultimately shelved the entire project. Only with years of hindsight can I now understand how my need to control the situation led the team to shut down and resist the success of the project.
The Solution: Give the Team Freedom to Self-Organize
Many companies espouse the practice of letting individuals self-organize (see Valve’s Employee Handbook). To some, this sounds like chaos, and it can be, particularly in young creative teams without experienced leadership. They may struggle without clear goals and role models, and no pattern to follow. Management’s knee-jerk reaction to avoid this fate often involves laying a grid on the team like misusing a Scrum process by insisting that members attend ceremonies, log tasks in JIRA, and fill out time cards. When introduced all at once, these constraints feel contrary to the instincts that make creatives talented in the first place.
What I learned: People don’t feel invested in ideas that are dictated to them. Moreover, they fail to get engaged in the project’s success.
When implementing Agile Design in your organization, fight the instinct to start off with specific processes in mind, telling team members how they must work. Instead, educate them on agile processes and gradually introduce ceremonies and processes that make sense for the team. I’ve found that once people have heard the concepts, they’re willing to give it a try.
A retrospective is often a good place to start—discussing what to “start, stop, or continue” helps every group align better. These retrospective ceremonies allow them to self-diagnose and correct team or work challenges. Let them know they’re trusted to develop solutions and processes on their own, and that there’s a support structure to help them should they want it. Praise your team’s successes, and give fact-based feedback where it’s needed. Frequent user testing and interviews can also give great input to improve the team. If you feel that this input still isn’t leading the team in the right direction, then you may have to resort to more pointed questions or even specific guidance on improving their performance.
When doing this, though, it’s important to make minimal corrections in order to get the project completed successfully. Exhaustive feedback and corrections risks making your team feel like they only did what you instructed.
Mistake #2: Under-Controlling Your Design Team
If over-controlling your team can be debilitating, than so can under-controlling as I found out. After I realized that I’d been an authoritarian manager, rather than a leader, I adjusted my style significantly. Rather than tell people what to do, I asked what they thought we should work on, and what their needs and goals were. When they said meetings were taking too much of their time, I encouraged sending email updates, or even working from home. Because our business partners were uncertain about the direction their company would take, this approach was temporarily effective: the team would explore for a while, get pushed in a strategic direction, then drift again as business priorities were reassessed. Self-motivated team members thrived, learning new skills and having a lot of fun.
But soon everyone tired of the situation. Many projects were never completed because the project lacked clear business mandates. The hard-working individuals got bored with the lack of meaningful work, and frustrated watching others doing minimal work. Several folks left to have successful careers at other companies. Under-performers weren’t motivated to improve so they had to be counseled to look for other opportunities. The laissez-faire approach wasn’t working.
The Solution: Give Designers the Structure They Need
I find that everyone craves order and predictability. Regular signposts provide the comfort needed to be creative. For students, that may mean lesson plans, worksheets, bells, and progress reports. For product design teams, Scrum practices recommend planning, review, and retrospective meetings, plus daily stand-ups. These are a great place to start, since they’re well-defined and time-tested. They provide everyone some level of predictability and organization so we’re all working from the same playbook.
Another layer of structure can come from tools, which at first glance seem like red tape—like JIRA for collaborative task management—but actually free the mind when used correctly. As David Allen’s Getting Things Done tells us: everyone gets burdened when they have too much to remember. Dumping that to-do list into an electronic tool (or notebook, whiteboard, sticky notes) gives creatives headspace to be innovative.
Using the tool you chose (and if you’re not sure which to elect, see this lively discussion on Reddit), make sure the team clearly documents what needs to be accomplished, why, and how each task or story ranks in priority. When working with an experienced team, there’s no need to tell them how the work needs to be done, or even who’s responsible—they will work that out once there’s clarity. Use daily check-ins to ensure that everyone communicates what they have or haven’t completed and understands what they’re working on next. Give them the responsibility for raising a flag if any part of the project is at risk - the entire team should be cognizant of sprint timelines. Additionally, you should allow for frequent check-ins and feedback. At argodesign we frequently review work more than once a day, and always once a week with the client or end user.
As an additional level of structure, we organize groups of design sprints into phases, since clients aren’t always prepared for a fully agile end-to-end process. We divide our timeline into a repeatable sequence of phases that allow for product design explorations and refinement, then detailed design documentation for both Engineering and Support teams, followed by ongoing implementation and support. This not only reassures stakeholders that we’ve thought through implementation and rollout thoroughly, but gives the Design team signposts throughout the project. It’s ok to explore innovative (and perhaps wacky) ideas during exploration, but during detailed design documentation, those ideas will likely be backlogged for a future product iteration.
Nearly everyone works better under constraints, including deadlines. For Agile to work for your team, you must set reasonable deadlines, parameters, and signposts, keeping limited time and resources in mind. The structure you implement should stimulate progress without becoming so restrictive that it inhibits good, creative work.
Mistake #3: Under-Communicating the Vision
When seeking necessary input from a client before fully diving into a project, it’s not uncommon to hear something like, “Isn’t that what you’re supposed to tell me? I’m paying you to design a logo, why do I have to tell you what it should look like?” To be sure, people shouldn’t tell designers what something should look like—they are there to solve that problem. But along with understanding constraints, everyone needs to deeply understand what the design should accomplish and why.
Make sure your client is clear on the company and project vision—the big picture objectives and measurables. What purpose will the product or website serve? How does it fit into overall corporate objectives? Who is the audience? What clear message should it send? If the goals or message are unclear, Design will take a long time, look muddled, or more likely both.
Too often I’ve seen clients define their design goals in such broad terms that it’s nearly impossible to derive a crisp solution: “We’re serving the needs of the enterprise, but need to appeal to consumers, too.” “We’re still working on our marketing message for this project, just lay out the pages and leave the copy for later.” Design can work with these parameters, but the results will lag, both in time and inspiration, and certainly won’t inspire users. Under these circumstances, designers often inflate timelines for what appear to be vague goals. And they’re right to do so.
The Solution: Provide Sufficient Vision and Empowerment
Clients with a strong, clear vision of their core mission, and who can articulate it concisely, are the easiest to work with. This includes not only clearly stating what Design should accomplish, but also why. The Design team should feel that they have enough inspirational guidance to make their own decisions about how to best accomplish the goal, what to prioritize, and what to set aside for later. This often brings with it an understanding of the audience — i.e. what type of users are we appealing to? What action do we want them to take, or how do we want them to feel after using this product? Designers can then use all of their skills to help accomplish these goals.
Remember to include history and context: what’s been tried before and didn’t work? Why didn’t it work? Are we willing to try again? What other departments are working on this issue and what approach are they taking? Can we collaborate with them?
Also critically important is allowing the team direct access to the end product users. Let people see the impact of their work—good and bad. Watching a consumer struggle with an engineer-design system can elicit some eye-opening revelations on how to simplify a work flow. Allow people to test what they’ve developed too, so they can make any final tweaks, and see improvements they’ve made in people’s lives. If at all possible, encourage folks to measure key objectives, or performance indicators, both before and after their work to allow for quantitative measures of progress.
Even the executive team benefits from agile milestones and a review of overall product goals. By reinforcing the objectives and progress, everyone feels a sense of accomplishment and validation of the project vision. The ceremonies present some pomp and circumstance with tangible and dependable celebrations.
In short, everyone on the team needs to know:
- Who’s going to use this product?
- What should they accomplish or feel about the product?
- How will we measure how well we’ve succeeded?
Succeed with Agile Product Design
Agile provides an excellent philosophy for teams of all types. Although designers have unique skills and a critical role in developing usable products, they react just as positively to clear goals, transparency regarding resources, and an environment that empowers them to excel.
So how you can succeed with Agile Design?
- Give teams the freedom needed to self-organize by practicing balanced leadership that effectively guides the team but allows each member to feel ownership.
- Give the team the structure they need by providing project management tools, meaningful ceremonies, and regular feedback that comfort rather than constrain.
- Provide the team with sufficient vision and empowerment by clearly conveying a strong core mission, results-based expectations, and the tools and access to measure success.
What are your experiences with Agile Design? Let me know in the comments below.
