Photo by Aron Visuals on Unsplash

A Minimalist Approach for Ephemeral Teams

Many organizations (Google being one well-known example) encourage their employees to experiment, not only with products they can potentially work on; they also encourage experimentation with processes and methods. In the context of this post, MVP² is shorthand for Minimum Viable Product (Definition) / Minimum Viable Process.

In the recent past, I’ve worked with multiple teams that have functioned in a rapid set-up/rapid tear-down type of context, where the teams were constituted to solve a single problem or produce a single deliverable. The teams generally wrapped up what they set out to do in anywhere from 2 to 6 weeks (or even over a long weekend, as is often the case for Hack-a-Thons). Because these teams have existed over such a short time horizon, I’m using the term “ephemeral team” to describe this type of team context.

Many Agile practitioners’ first instinct is to have ephemeral teams they work with as facilitators use Scrum. While recognizing that many teams get good results with Scrum, it’s also important to point out that there are many situations where Scrum is not the ideal choice (and in some cases, would be a poor choice).

Let’s walk through some examples of :

• Minimum Viable Product Definition
• Minimum Viable Process

Minimum Viable Product Definition

The term Minimum Viable Product (MVP) is well-established; and I will not be exploring the concept of what parameters to consider as part of a viable product, or strategies for releasing an MVP into the marketplace. Instead, for this first part of MVP², I’ll be focusing on techniques that can help us rapidly arrive at a minimalist definition for a product or some other deliverable, which will serve as the basis for creation of a product prototype or the deliverable in question. Each of the techniques that are included in this section are possible to facilitate in a short period of time, and can be used individually, or together.

For instance, if we’re participating in something like a Hack-a-Thon, there is a decent chance that any one of these techniques could be sufficient by itself to get a team started. In other cases, such as a team practicing for a single-day or multi-day “technical challenge,” two or more techniques in sequence might be a better choice.

• vision statement
• elevator pitch
• inception

Vision Statement

Roman Pichler’s advice on formulating a vision statement includes things like being sure to articulate:

• Who is the target audience?
• Which customer needs can the product/deliverable satisfy?
• Which product attributes determine the satisfaction of those needs?

Let’s consider a couple of ways to write a vision statement, by starting with one of these two templates:

1. A context where the [target customer] no longer has the [identified problem] because of [product] they [benefit]; or
2. To [benefit realized] by [product differentiator]

For example 1, as the authors of the book Product Roadmaps Relaunched point out, for example one, if we were writing a vision statement for a garden hose, we might say something like …

A world where American landscape enthusiasts [target customer] can have a more predictable and automatic [identified problem] watering system that can perfect their lawns [benefit] with an effective water delivery system [product]

And alternatively, for the same product, if we were following the format in example 2, we might say this …

To perfect American lawns by perfecting water delivery.

For additional examples, see Kirstin O’Donavan’s post titled 20 Inspiring Vision Statement Examples (2020 Updated).

Elevator Pitch

An elevator pitch is essentially a variation on a vision statement, using a particular format. Geoffrey Moore’s book Crossing the Chasm is where this format first surfaced:

For many situations, I prefer a shortened form of an elevator pitch, closer to something like this:

• For <target customer/user type>
• Who <statement of goal or need>
• The <product/deliverable>
• Is a <type of product/deliverable>
• That <statement of purpose/value proposition>

Let’s say I’m writing an elevator pitch for my lawn care business. I might say something like …

• For people who don’t have time to take care of their yard
• Who need a reliable lawn care provider
• The Green Machine
• Is a complete yard maintenance solution
• That makes it easy for people to request yard care online and leave the rest to the Green Machine

Note: An elevator pitch is also one of many activities that can be included in an inception session (see below).

Inception

As I’ve written about on this blog, Inception consists of a set of activities that help get clarity on vision, goals, and scope. For an ephemeral team, a small subset of these activities is likely sufficient, such as:

• Why are we here? (why work on this now?)
• What keeps us up at night? (what are the dependencies and risks?)
• NOT list (what are we not going to include?)
• Technical solutions (what technical approach do we think will best enable us to achieve the desired outcome?)

Minimum Viable Process

Returning to my earlier point about Scrum, for ephemeral teams (and many other teams), it’s preferable to start with the simplest possible set of guidelines that makes it possible for team members to work together effectively. In that context, even though Scrum might appear to be an appealing choice, it introduces more process overhead than there might appear to be at first glance.

To summarize, as articulated in the Scrum Guide, Scrum is based on a particular body of knowledge, including a set of values and principles. An easy way to articulate the day-to-day realities of practicing Scrum is by referring to it as the “Scrum 3–5–3–3,” where there are:

• 3 Roles (Scrum Master, Product Owner, Developer)
• 5 Events (the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective)
• 3 Artifacts (the Product Increment, the Product Backlog, and the Sprint Backlog)
• 3 Commitments (the Product Goal, the Sprint Goal, and the Definition of Done)

Note: What I’m referring to as the 3 Commitments were added to the Scrum Guide in 2020. Their existence may be less apparent, since they don’t surface at the heading level of the Guide like the Roles, Events, and Artifacts do. I feel it’s important to call the 3 Commitments out separately because they anchor the 3 Artifacts to a specific vision and specific outcome.

Given that we’re talking about ephemeral teams, the considerations that we need to keep in mind when it comes to a Minimum Viable Process include how long the team is likely to exist, and how specific the outcome is that the team wants to achieve.

For ephemeral teams that I’ve worked with, the most basic elements of the second half of MVP² (Minimum Viable Process) look something like:

• Working Agreement
• Definition of Done
• Task List
• Regular Check-ins

Working Agreement

A working agreement, also known as a “team working agreement,” is a basic set of guidelines that team members agree upon, which helps them work together effectively. It is important to emphasize that working agreements are co-created by the team members; they are not imposed on them by somebody outside of the team. It’s also important to recognize that the longer that a team works together, the higher the likelihood that they’ll need to revisit, and potentially revise, their working agreement.

Here are examples of topics that a working agreement might cover:

• How do we make decisions?
• How do we handle conflict?
• How do we run our meetings?
• How do we communicate?
• How do we manage our work?
• How do we have fun?
• How do we give each other feedback?
• How do we hold each other accountable?
• What is important information to us?
• How do we interact with individuals and groups who are external to the team?

Many factors inform how how many topics a working agreement might need to cover, or whether one is needed at all, including:

• How long the team will be working together
• Number of people on the team
• The complexity and/or specificity of the team’s primary deliverable

Note: For an additional perspective on working agreements, see the blog post The Transient Team Charter, by Dan Greenberg, which speaks to situations where teams might not quite fit the ephemeral team label I’m using here, but which might come into play in situations where frequent changes to team composition might occur.

Definition of Done

One of the Scrum concepts that is broadly applicable, whether a team is practicing Scrum or not, is a Definition of Done (DoD). In the absence of a DoD, team members might finish one task and more on to another without getting feedback from at least one other team member. As such, existence of at least a rudimentary DoD can reduce the potential that rework will be necessary.

Below are examples of basic elements of a DoD for a team with a software product/deliverable:

• All tests pass
• Peer code review completed
• Relevant documentation updated
• Code deployed to <target environment>
• Aligns with design/usability/availability guidance

Task List

In some situations, there is enough work to keep track of on an ephemeral team to justify creation and management of a Product Backlog. However, many ephemeral teams don’t require the level of rigor or process overhead inherent in a Product Backlog. For them, a list of tasks might suffice. It’s important to recognize that even for teams that need only a task list, many of the same things that are important in Product Backlogs tend to apply, such as:

• The relative priority/desired sequencing of the tasks
• The relative complexity of the tasks
• The desired outcome(s) from the tasks
• Who is going to work on the tasks

In terms of format for the tasks, something like this tends to work well for a variety of situations:

• Task header
• Who’s it for? (note that if all tasks are undertaken for the same customer/same user type, this is likely unnecessary)
• What’s the desired outcome?
• How do we know it’s done?

Using the format above, we might have a task that reads something like this if we were working on a course registration system:

• Task header: Build login page/component
• Who’s it for? A returning student
• What’s the desired outcome? Returning student can login
• How do we know it’s done? A person with valid credentials can login

Regular Check-ins

Another aspect of Scrum that we may want to apply in an ephemeral team context is something similar to the Daily Scrum. It does not necessarily have to be daily, and the format can potentially differ from one occurrence to the next. For instance, some teams might choose to do this:

• Virtual check-ins 3x per week (using a collaboration tool such as Slack or Microsoft Teams)
• Face-to-Face check-ins 2x per week (where Face-to-Face might mean in the same physical space, or it might mean using a video conferencing tool)

When it comes to what topics to cover during a check-in, simple prompts such as these often suffice:

• I’m working on <task>
• I need help with <task>
• I can help with <task>

Note: See also my blog post Daily Standup Patterns for ideas on how to facilitate a short meeting such as a check-in.

Conclusion

Ephemeral teams may find that employing only a subset of the practices described above is more than sufficient for their particular situation. Whatever the team members decide about how they choose to define the product/deliverable, and how they work together, it’s helpful to view their chosen approach as an ongoing experiment.

Last but not least, even long-standing teams may find that they can streamline the way in which they work together, possibly by mashing up techniques described here with others that work for them in their context. Happy experimenting!