Diving deeper into the first item on the list of Misadventures of Agile Discovery (MAD), let’s look into the problem of having a separate discovery team. Let me start with a couple of stories.

Outsourcing the work

Before I started working with a client, the mobile division hired an outside vendor for user research. After I spent a few weeks coaching the team, the vendor came in to the office and presented the results from several weeks of research. The vendor spoke to about six people in that time. Yet the team talked to that many people in the first week, changed the approach based on feedback, continued talking to users frequently and went through multiple iterations in a shorter time frame. The vendor’s results were stale- a few iterations and several dozen users behind the team- taking several weeks longer.

The core discovery team detaches

U.S. Army Corps of Engineers photo by George Jumara

Another client that created core product discovery teams inside their Scrum teams made an analog to a house for the team structure. The roof of the house is the core product team. At the peak is the Product Owner and on the eaves are the senior software developer and User Experience person. The body of the house consists of the rest of the Scrum team. We were called back in because the roof had detached from the body of the house.

Some of the consequences included the discovery team working to polish a prototype before handing it over to development, without much user involvement. The MVP was becoming bloated with features and assumptions as well.

Why this happens

There are more stories I wish I could go into. Instead I’ll list reasons that I’ve heard. I’m sure there are more.

• People perceive a lack of expertise on the development team.
• The development team needs to stay “heads-down” and not worry about picking up new skills.
• Research, design and user experience disciplines want to work together for site consistency.
• Different functions reside in different locations.
• The discovery work is “fed in” to the development team when it’s ready.

The root of the problem

In every instance including the stores I did bother to describe, the separation thwarts shared understanding. No matter the reason, having a select group work the discovery process in isolation of the delivery team slows down progress, increases errors and creates animosity with an us/them relationship between groups. Let’s look at how to turn this around.

Create a mentor program

In the first example, the results were used to change the vendor relationship. The vendor qualifies people and lets the pilot teams use their labs one day a week. In this way, the vendor became a mentor to the team that was less reliant on the expertise of the vendor. Working together, the team and the vendor both changed their approach to user research. The team leveled up research skills, and the vendor has a happy client that extended the contract from fixed-bid into an ongoing partnership.

When the team is lacking some skill, or a role is limited supply, do what you can to level up the team. Continuing to rely on personnel outside the team is a local optimization. When deciding to vend work out to an outside firm or another department, when dealing with a limited role like one UX person for three teams- create a mentorship program so the team becomes self-sufficient.

The mentor program goes beyond a transfer of knowledge or a brown bag lunch series. The mentor works alongside the team and together they decide wen the team is capable enough to no longer rely on the mentor. To make it work best, there needs to be room in the plan to accommodate for the mentor, and reserve team capacity for learning.

Establishing office hours, like a professor, can also help. In this manner, the mentor agrees to work with the team for specific blocks of time like every Thursday from 1-3pm. During this time, the mentor sits with the team and if the team has work for the mentor, they do it. And if not, they sit there and do their own work and if anything comes up on the team for the mentor during that time, it becomes their highest priority work.

Give everyone the option to contribute

In the second example, we came back in and facilitated training in collaborative Agile product discovery. The training highlighted for the organization the value in keeping a story map visible for everyone’s contribution. The rows on the map give line of sight to the outcome desired and keeps the MVP truly minimal. Everyone’s contribution flushed out assumptions to test with the right fidelity of prototype.

Some of the best user research sessions I’ve seen happen when everyone on the team who wants to be involved, goes out together. I hear developers state that seeing the users in action changes their job from a todo list of code to write to figuring out what will help the user reach their goals. I’ve heard people say that they can’t get the mental image of the user, struggling with the application, out of their minds. This level of compassion increases the effectiveness of their contribution and overall engagement in their work.

Schedule functional meetings

When a functional area like design/UX wants to be a separate team for site consistency, this is similar to any functional area wanting to separate from the Scrum team (or create their own team) for the sake of consistency. Have periodic functional meetings on a periodic basis to keep the consistency. It might be an hour meeting every other week, or on demand, and doesn’t deter from the team’s ability to get work done. This is similar to a community of practice, a special interest group, and the guild concept at Spotify.

Run together

In The New New Product Development Game written in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka states,

Anniversary Games, Olympic Park, London, July 2013

“Under the old approach, a product development process moved like a relay race, with one group of functional specialists passing the baton to the next group. (…) Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.”

While it is undoubtedly better for a team to work together, sometimes it’s tough to avoid all hand-offs. To draw on the analogy when this happens- ensure both sides are running together and ensure the baton isn’t dropped.

Instead of only handing a backlog of new stories over to someone else to develop, do you also embed portions of the wireframe in the stories? Do you have a prototype the team can play with? Can you shoot a two minute video walking through a story map? Or a video of a “chalk-talk” in front of a whiteboard? When sitting down for a story writing or refinement session, do the developers write the details of the stories and acceptance criteria? Can you sit with the team for some time, or have a couple of them sit with you for awhile?

In conclusion

Whatever your approach, remember to evaluate process on qualities, rather than compliance. For me, it’s important that the team is engaged, has a sense of purpose of what to build and feels that they can contribute to the discovery process if desired. It should help maximize outcomes while minimizing output and help the team agree together of what not to build.