The Teardrop Model

Hands holding a paper water drop

Avoid Crying About Accountability with Our Teardrop Model

As wonderful as agile is in creating empowered teams, it can also create confusion or uncertainty about who is leading a team, an initiative, or what the “right” product looks like. It can lead to awkward situations like what do you do when the team doesn’t agree and there is no one to tiebreak? 

What happens when everyone has an opinion, but some team members are more knowledgeable in a specific area than others? 

What happens when everyone is contributing to an increment, but no one owns the whole thing? 

How do you ensure you are delivering value versus a pile of user stories?!

You Need a Leader.

Let’s start by thinking of the team as a body of water. Fluid, capable, cross-functional, and “agile.” Each person has a role, every role is equally important, and everyone is working toward the same goal. But, when a new initiative comes up, the body of water changes to a droplet shape with someone rising up to take the lead and breaking the infinite circle. 

Drops of water with team member name in it

Disclaimer: This model isn’t always easy to put into practice.  With fluidity comes ambiguity. However, if you stir in a dash of trust and intent, your team will be set up for greatness.

Here’s the thing: the leadership position is fluid; it will change with each initiative or body of work. The person at the tip of the droplet will vary based on the timing, content, and context of the problem being solved. It may not even be clear who should be in the role at the get-go. Sometimes it’s the developer, or the designer, or someone else on the team.

Who Leads?

So, how does the team “decide” who leads an initiative? It needs to ask itself these two questions:

  1. Who has the expertise and the capability to lead this particular initiative?
    1. Expertise and capability don’t always mean having the right diploma or certification.  When you’re highly educated or experienced, you are often looked to for leadership and decision-making roles even when it is not a discipline you have depth in. But expertise and capability, in this case, means you have the right experiences, learning lineage, approach biases, or relationships to solve the right problem, make the right decisions, and align to the larger mission. It also means you thoroughly understand the product and customer that’s being delivered.
  2. Who wants to be the team’s leader and voice on this initiative?
    1. Being a leader means being the steward of team collaboration, accountability, and follow-through. Basically, you’re taking responsibility for challenging the team, facilitating hard conversations, and driving to done.  This takes people smarts. You should be able to read the dynamics of the group, leverage people’s strengths, and help address challenges. This is called “showing the system to itself.”
    2. In addition to wanting to be the leader, you have time to be the leader.If you’re swamped, you won’t have time to dedicate yourself to leading the team.

Team Awareness

I should mention here that choosing the leader takes “awareness” on everyone’s part. Sometimes it is an intentional action, sometimes it is as fluid as the conversation. Each team member needs to be self-aware of what they are an expert at, what they are qualified to lead, and if they have the time to do the leading. 

Then, they need to be team-aware. Which team member has the expertise for this initiative and can also make the tough decisions to move the initiative forward, even if this is person hasn’t led in the past? This awareness will make the leadership question easier (but not easy), especially if it’s someone who hasn’t historically filled this role.

Don’t get stuck always turning to the most senior person. Using this model, everyone gets to flex their leadership skills. There’s nothing more powerful and high-performing than watching a highly intelligent person (the smartest person in the room) pass the leadership baton off to a capable team member and then align themselves to a supporting role. That’s is where humans can truly live into their own potential and that of the larger group.

Agile Pain Point: Product Debt

A scribble with the word Product Debt

What's Product Debt?

Product Debt is the culmination of competing business needs, functionality requests, hastily made design decisions, quick fixes, wonky workarounds, and then some –  that has led to a feature-crowded, possibly clunky, and oftentimes not very usable product.

You’ve heard it before, agile product delivery is a balancing act between building the right thingbuilding the thing right, and building the thing fast. Product Debt mainly happens while you’re trying to build the right thing.  How do you choose which features and feedback to incorporate with constant feedback and input from your stakeholders and customers? How do you prioritize requests? Or how do you make one person happy while knowing someone else won’t be?

Design with the end in mind.

Become a product and service-focused “machine.” Understand the problem (or need) you’re trying to solve and have a strong vision for your product solution strategy, both internal and external. This is how you do it:

 The business articulates its needs

• Stakeholders prioritize those needs through support and funding

• Product Owners create and drive the product vision and ensure alignment of delivery

• Business needs and product strategy are visualized and communicated through the roadmap, and

• The Product backlog visualizes the decomposition of the roadmap into traceable, digestible pieces of work.

Through the balance of customer collaboration, rolling wave planning, and transparent delivery practices, your product direction, prioritization, and delivery strategy will be to the benefit of everyone because everyone was a part of the process. And everyone will be on the same page and know where they’re headed.

SIDE NOTE: To build the roadmap, you absolutely must have input from business experts, technical experts, process experts, and the people doing the work. You won’t have an accurate projection of what is possible if any representative is missing . You might aim high but not have the tech foundation to back it up. Or, you may set out to build a high-tech product, but it’s not what your customer wants or needs. Every one of those voices working together to represent and balance their interests is vital when deciding on the ultimate goal. It takes a village – and an agile coach!

Intentional Problem Solving

With a strong vision and product solution strategy, you can make decisions with intent.  The Product Owner will make sure teams are building the right thing. Not at the mercy of fire drills and random requests. Responsiveness to the business and technology is needed but should not always be the driving force.

here will always be a constant tension between building the right thingbuilding the thing right, and building the thing fast. Releasing the tension in any of the three areas will be a decision you’ll have to pay for later. Robbing Peter to pay Paul, so to speak, leads to possible product debt. Or tech debt, or time debt, but that’s another blog. Maybe you’re short on funding or time and need something fast. Building a quick and dirty prototype is perfectly acceptable.  It’s another story if you’re building an enterprise solution.  Each decision is a tradeoff that needs to be made with intent and with a complete understanding of the consequences. This brings me back to the beginning….

Decide what’s important to your customer, execute on your strategy, and build with the end in mind.

You don’t have to go it alone! Let us help!