Project Management

Sense & Respond

by ,
Jeff Gothelf and Josh Seiden, leading tech experts and founders of the global Lean UX movement, share their insights into how organizations can grow and thrive based on their ability to sense and respond instantly to customer and employee behaviors.

About this Blog

RSS

View Posts By:

Jeff Gothelf
Joshua Seiden

Recent Posts

Your next agile project: your career

Good Agile Teams Are Diverse Teams: How Diverse Teams Allow You To Solve Problems Early and Often

Moving from Project to Product: What Does “Product Thinking” Actually Mean?

Is Your Organization "Sort of" Agile?

Three Obstacles That Leaders of Cross-Functional Teams Face, and What To Do About Them

Good Agile Teams Are Diverse Teams: How Diverse Teams Allow You To Solve Problems Early and Often

Have you ever been asked to put lipstick on a pig? If you’ve ever worked as a designer, then you know it works something like this…

Your client will come to you with with a product that’s very close to being done, almost ready to ship, and ask you to “fix the design.” They can’t exactly tell you what they want, but they know that something is wrong. Very wrong. 

Maybe the product is ugly. It probably is, but that’s probably not the real problem. The real problem is probably deeper. The product is confusing. The product doesn’t do what customers want. Or maybe it’s just… missing something. They’ve come to you, hoping that design will fix it.

But we all know how this story ends. The designer shows up, sees the pig, and complains (usually under his or her breath), they just want me to put lipstick on this pig.

Before you go complaining that some pigs are beautiful, let’s just agree right now that no amount of lipstick is going to this little guy into a movie star. Photo by mali maeder from Pexels

Why does this happen? In the design world, we understand that this is a problem caused by bringing designers into the process too late. Early in the process, designers can help identify what customers and users want, and can help define the way the product works, the problems it solves - not just how it looks. In other words, the issues that show up late in the process can often be avoided if the right people are involved early in the process. 

Now this may sound like a commercial for design, but it's not. It happens to engineers too. Even though Engineering is often involved in projects close to the beginning, every engineer can tell you a story about the time he or she was handed a set of orders from "the business", and being told to "just build it." (This isn't exactly lipstick- on-the-pig. It's more like Frankenstein's monster.)

So, this this is actually a public service announcement: every discipline needs to be at the table early in the process so they can work on the project together - for the duration of the project.

Good Agile Teams are Diverse Teams

Good agile teams tend to be diverse teams. They are diverse across a range of dimensions. From culture to race to gender to skill to roles. They possess a mix of perspectives that allow them to identify critical issues early. They possess the decision-making capability to decide how to address the problems and opportunities that they find. They possess a mix of skills that allow them to fix these issues before they become unfixable. Business, design, engineering, etc, all working in collaboration.

Sounds great, right? Well, it doesn’t always feel great. That’s because the very thing that makes teams like this effective — their diversity — can also make for a lot of conflict. Studies show that diverse teams outperform non-diverse teams, but they also experience more conflict.

Build Collaborative Teams Intentionally

To handle this conflict, you want to get ahead of it. 

  • Anticipate problems by creating Team Working Agreements. Team working agreements allow teams to create a commitment to collaboration — and give teams tools to address conflict when it inevitably arrives. 

  •  Get good at interviewing your team-mates, your customers, your stakeholders. Listen not just for what they tell you, but also for what they might not be telling you.
  • Build empathy and understanding across your team by creating empathy maps. Take what you’ve learned from your listening work and model it in a structured way to gain insight about your co-workers.
  • Finally, take what you’ve learned and build better plans — plans that take advantage of everyone’s perspectives, skills, and abilities.

Sound intriguing? Want to learn more? Check out our new online course, coming soon on PMI.org.

Posted by Joshua Seiden on: November 18, 2019 10:13 AM | Permalink | Comments (8)

Three Obstacles That Leaders of Cross-Functional Teams Face, and What To Do About Them

I used to live in the suburbs next to a guy named Jim. Jim spent a LOT of time outside in his yard with loud, gasoline-powered equipment and tools. His favorite tool, and the loudest coincidentally, was his leaf-blower. And while he did have a stellar looking yard, the noise that emanated from said leaf-blower on a daily basis—multiple times a day—conflicted with my work-from-home conference call schedule. Often.
 

Any sane person would immediately assume that the level of attention Jim paid to his yard was excessive. And they’d be right. But I lived next to him for 10 years and over that time developed a different understanding of Jim’s perspective.
 

Jim had an angled driveway that connected directly to his garage and house. Rainwater and snow-melt would flow down the driveway towards the garage and into a grate. If that grate clogged with leaves, branches and twigs that fell from the big trees around our houses, Jim would get water in his basement. This was the main driver of his leaf-blower obsession.
 

Jim would regularly show me how much debris he’d cleared each day and note that once again his basement would stay dry. By experiencing this situation together with my neighbor I was able to learn, quickly, why he was behaving in this particular way. This experience formed the basis of our shared understanding. Because we had done something together, at the same time we had a clear understanding of what happened, who it happened to and what drove the action. The only thing we had left to decide was what to do about it. (Spoiler: better headphones for me did the trick.)
 

Shared Understanding And Cross-Functional Teams

To increase the agility of our organizations we also need to build a team structure that builds shared understanding. In the old linear world, waterfall processes worked well. One discipline did their work, handed it off to the next discipline in line and repeated the process. Efficiency was the goal and the time to production of the final product—well defined and well-understood—was the measure of success.
 

The model that replaces discipline-based silos in today’s uncertainty-filled contexts is the cross-functional team. These teams are made up of individuals with the skillsets necessary to deliver an entire product from beginning to end. They work together on the same project or initiative at the same time. They discuss their work together on a daily basis and adjust their approach based on input from everyone on the team.
 

Cross-functional teams reduce the cycle time of learning, so teams can better understand whether their product is truly delivering value. The faster a team learns, the more agility it exhibits. Working together in short cycles (called “sprints” in the Agile world) builds shared understanding. Shared understanding—like the kind Jim and I had because we were neighbors —is the currency of an agile team. When something happens,the team doesn’t have to waste time explaining to each other what happened. They were there. They experienced it first hand together. Instead, the team can move to a far more productive conversation: “What are we going to do about it?”
 

Leaders who can help teams build shared understanding save time, money and effort and lead to an improved quality of their product or service. But leading cross-functional teams to achieve as much shared understanding as possible has its own challenges. Here are three challenges to consider as you work towards managing and increasing the agility of your organization.
 

The team leader doesn’t have the same technical or domain expertise as the rest of the team

If you’re in charge of a cross-functional team odds are you rose to that role through a specific discipline. Maybe you were a software engineer or a business analyst. You were probably very good at that job but you’re certainly not an expert on how every other discipline should do their job. One of the things we teach in our courses is to set clear goals and guidelines for the team. Then get out of their way. Trust the team to do their best work. If you don’t understand how they do their work consider running a series of discovery interviews— something we also cover in our online and in-person courses. Ask them questions like, “How do you make decisions?”, “What constraints do you have on your work?” and let them explain their process and decisions.
 

Aligning the team to priorities and building consensus can prove difficult

If you were to ask a cross-functional team what the most important thing they needed to do next was, you would get as many answers as there were disciplines seated at the table. All of them are right but which one is the number one priority? In this frequent situation it’s your job as the team lead to determine which priorities are currently critical to the success of the initiative. You probably don’t know either. In high-uncertainty contexts, this is normal! So what should you do? We teach the teams we work with to frame their work as testable hypotheses. This allows the entire team to express which features they believe they should move forward and how they will know it was the right decision. Teams test their hypotheses to determine which thing, if we don’t do it right now, causes the biggest risk to the project. That’s the one the team should work on next.  It doesn’t mean the other ideas are wrong. It just means that you are going to defer work on those items until these higher risk issues are solved.
 

How do we keep everyone “busy” throughout the entire initiative?

Throughout a project’s lifecycle certain disciplines will be busier than others at various times. In the early stages design and product management do a lot of work while during the middle the engineers pick up the bulk of the work. What do the less-busy disciplines do during those times? Since we don’t want to break the team apart and move less busy people to other projects for fear of breaking the shared understanding the team has created we need to learn what other skills these folks bring to the table. Can they talk to customers? Can they do QA or UAT testing? Can they build a presentation to educate other departments about the upcoming changes the team is building? In addition, these same folks can likely continue doing their core work. Not everything fits into a sprint and so there is almost always something for designers, writers, business analysts and project managers to do. As Josh recently wrote on his blog, “Agile teams should be doing all of these things continuously, in every sprint. You want to be researching continuously. Designing continuously. Building continuously.”
 

Shared understanding is the key to agility

Agility is a goal all companies should strive to achieve. Your choice of how to staff and lead teams will impact this goal significantly. The more cross-functional your teams can be, the more shared understanding they will gain, the more agility the teams will exhibit. Nevertheless, this staffing model isn’t free. It has its own challenges that, as a strong team leader, you can overcome with some training, some improvisation, some humility, and some creativity.
 

We’re working closely with PMI to build offerings that teach shared understanding, collaboration and agility and we’d love to hear from you. What have you seen work well on cross-functional teams? What has been challenging in making them work? Who have you seen do this well? Reply in the comments and let’s build a list of best practices.

 

We're collaborating with PMI to create new online resources, webinars and in-person events to help you build, maintain and scale your Sense & Respond organization. To keep track of what we’re building together sign up here

Posted by Jeff Gothelf on: August 21, 2019 06:57 AM | Permalink | Comments (13)
ADVERTISEMENTS

"Man is the only animal that blushes. Or needs to."

- Mark Twain