Agile Team Composition: Generalists versus Specialists

Estimating levels of effort for a set of tasks by a group of individuals well qualified to complete those tasks can efficiently and reliable be determined with a collaborative estimation process like planning poker. Such teams have a good measure of skill overlap. In the context of the problem set, each of the team members are generalist in the sense  it’s possible for any one team member to work on a variety of cross functional tasks during a sprint. Differences in preferred coding language among team members, for example, is less an issue when everyone understands advanced coding practices and the underlying architecture for the solution.

With a set of complimentary technical skills it’s is easier agree on work estimates. There are other benefits that flow from well-matched teams. A stable sprint velocity emerges much sooner. There is greater cross functional participation. And re-balancing the work load when “disruptors” occur – like vacations, illness, uncommon feature requests, etc. – is easier to coordinate.

Once the set of tasks starts to include items that fall outside the expertise of the group and the group begins to include cross functional team members, a process like planning poker becomes increasingly less reliable. The issue is the mismatch between relative scales of expertise. A content editor is likely to have very little insight into the effort required to modify a production database schema. Their estimation may be little more than a guess based on what they think it “should” be. Similarly for a coder faced with estimating the effort needed to translate 5,000 words of text from English to Latvian. Unless, of course, you have an English speaking coder on your team who speaks fluent Latvian.

These distinctions are easy to spot in project work. When knowledge and solution domains have a great deal of overlap, generalization allows for a lot of high quality collaboration. However, when an Agile team is formed to solve problems that do not have a purely technical solution, specialization rather than generalization has a greater influence on overall success. The risk is that with very little overlap specialized team expertise can result in either shallow solutions or wasteful speculation – waste that isn’t discovered until much later. Moreover, re-balancing the team becomes problematic and most often results in delays and missed commitments due to the limited ability for cross functional participation among team mates.

The challenge for teams where knowledge and solution domains have minimal overlap is to manage the specialized expertise domains in a way that is optimally useful, That is, reliable, predictable, and actionable. Success becomes increasingly dependent on how good an organization is at estimating levels of effort when the team is composed of specialists.

One approach I experimented with was to add a second dimension to the estimation: a weight factor to the estimator’s level of expertise relative to the nature of the card being considered. The idea is that with a weighted expertise factor calibrated to the problem and solution contexts, a more reliable velocity emerges over time. In practice, was difficult to implement. Teams spent valuable time challenging what the weighted factor should be and less experienced team members felt their opinion had been, quite literally, discounted.

The approach I’ve had the most success with on teams with diverse expertise is to have story cards sized by the individual assigned to complete the work. This still happens in a collaborative refinement or planning session so that other team members can contribute information that is often outside the perspective of the work assignee. Dependencies, past experience with similar work on other projects, missing acceptance criteria, or a refinement to the story card’s minimum viable product (MVP) definition are all examples of the kind of information team members have contributed. This invariably results in an adjustment to the overall level of effort estimate on the story card. It also has made details about the story card more explicit to the team in a way that a conversation focused on story point values doesn’t seem to achieve. The conversation shifts from “What are the points?” to “What’s the work needed to complete this story card?”

I’ve also observed that by focusing ownership of the estimate on the work assignee, accountability and transparency tend to increase. Potential blockers are surfaced sooner and team members communicate issues and dependencies more freely with each other. Of course, this isn’t always the case and in a future post I’ll explore aspects of team composition and dynamics that facilitate or prevent quality collaboration.


Image by Gerd Altmann from Pixabay

Improving The Odds of Success For Any Goal With A Definition of Done

In 1626 the King of Sweden, Gustavus Adolphus, began work on what he envisioned would be the most powerful battleship ever to set sail – the Vasa. By all accounts, Gustavus was a brilliant military commander. Over the next two years the King repeatedly alter specifications such that massive amounts of rework were required. The mid-project inclusion of non-essential work – such as adding close to 500 elaborately decorated sculptures – added to the delay. The array of canon on the ship grew both in size and number. The result was an untested design that proved unstable when the ship was launched with great fanfare from the shipyard in Stockholm. Before King and country, the Vasa hadn’t made it out of the harbor before a strong breeze tipped the ship so far that water began entering the canon portals and sank the ship.

The lessons from this historical event about meddling managers embedded in a hierarchical system of status and nobility are obvious. This practice is still very much endemic in legacy corporations and MBA programs continue to crank out a plethora of future executives equipped to carry on the tradition. Thousands of executive and Agile coaches make a well deserved living working to remediate the problem.

A lesser but more actionable lesson has to do with Gustavus’ approach to project management. As brilliant as he was on the battlefield, this skill did not translate to the material production field where events move toward completion over months and years rather than hours and days.

There is a reason Agile project management leverages frameworks rather than highly structured protocols for getting work done. It recognizes that the world can be a messy place. Particularly when it requires human beings to complete work. With so many variables in play – emotions, physical health, competing priorities around family, pandemics, etc. – it’s amazing we get as much done as we do. Frameworks give us the flexibility to adjust and adapt to the situation.

There is a paradox embedded within Agile frameworks. Flexibility and adaptability are important, but there are also elements of the frameworks that are important to get right. The most important is to have a healthy product backlog that is vigorously maintained and defended by the product owner. If this isn’t in place, everything else become a major battle to implement. Stories bounce across multiple sprints, errors and rework grow exponentially and stakeholders readily jump to uncomfortable conclusions about progress.

Another important element is what’s typically called the “definition of done.” If the product owner or Agile team member can’t clearly and concisely describe what “done” looks like, you end up with some version of this conversation.

Product Owner: “What do you mean you’re still working on that story. I closed it last sprint because you said it was ‘done!'”

Agile Team Member: “Well, uh, yeah. It was done. But it wasn’t done done. There were still a couple of things I wanted to finish.”

If your definition of done is some version of “I’ll know it when I see it,” there is a good chance you’re about to attempt the launch your very own Vasa.

If you’d rather not do that, here are a few things to do instead:

  • If you are involved during the design phase of the project, repeatedly run a thought experiment where you begin with the end in mind. It’s that vision statement thingy.
  • Work to establish a clear understanding of what “good enough for now” means. And when you’ve done that, keep checking in with your team to evaluate if anything has changed to cloud that understanding.
  • Use minimum viable product definitions. Add to this the idea of minimum viable actions. As important as it is to know, as best you can, what done looks like, you need a sequence of actions that will get you there. What are those? In what order can they most effectively be sequenced? How jis what you’re learning along the way changing the path to “done?”
  • Finally, keep your product backlog healthy and strong. Without exception, continuously refine the backlog with stakeholders and the development team so that it is an accurate reflection of progress and future work.

Photo by Jamie Morrison on Unsplash

Baseballs and Hockey Pucks

“Keep your eye on the ball!” I was always coached when learning how to play baseball. Seemed like reasonable advice while standing at the plate, facing down the pitcher for the opposing team. Certainly wouldn’t want to be daydreaming or casting my gaze to the horizon. It didn’t seem to help, though. I excelled at striking out.

Later…much later…I came across Wayne Gretzky’s quote: “Skate to where the puck is going, not where it has been.” I wonder if I had learned to figure out where the baseball was going to be and made sure my bat was there to meet it if I might have spent more time on bases. Keeping my eye on the ball didn’t tell me much about when to start my swing.

No regrets. I still love the game (as it was, not as it currently is.)

I think of this Gretzky quote when I watch product owners struggle with organizing their backlog. (I also think how tragic it is that the business world has beat this quote into an intolerable pulpy platitude.)

Ask a product owner what their team is working on today, they should be able to give a succinct answer. Ask them what their team is going to be working on in three months and watch the clock. The longer they can go on about what their team is going to be working on, the healthier their backlog is likely to be. Struggling product owners scramble to keep their teams busy sprint-to-sprint. Good product owners can see where their teams are going to be in several months. Great product owners see to the end of the game.


Photo by Chris Chow on Unsplash

Teaching Product Owners How To Fish

Product owners are responsible for defining WHAT the Agile team needs to create. The team is responsible for deciding HOW to build WHAT the product owner needs.

I don’t think any Agilist would fundamentally disagree with that statement. Where there is inevitably a great deal of discussion and disagreement is describing the boundary between “WHAT” and “HOW.” Is it thin or thick? How much overlap is there? Does this depend on the nature of the work or is there a fixed standard? Does it have to be determined for every story? These are often not easy questions to answer.

While reading some neuroscience material yesterday regarding how our brains construct “concepts,” the topic lead into the notion of “goal-based concepts.” Since I’m not a neuroscientist but an Agilist looking for ways neuroscience can be applied to the implementation of Agile principles and practices, the material had me thinking about how product owners might learn from the idea of “goal-based concepts.” How can I teach them about the “WHAT” such that they better understand the type and amount of detail the team needs in order to figure out the “HOW?”

I came up with a series of short dialogs:

Product Owner (to team): I need a fish.

Team: OK.

(Team goes off to work on “fish” and returns the next day with a catfish.)

PO: That’s not what I wanted! I need a fish!

(Team goes off to work on “fish” and returns the next day with a nurse shark.)

PO: That’s not what I wanted either!

What if the PO had been more clear about not just WHAT she wanted, but the goal for that WHAT. That is, a description of the problem that the WHAT was intended to solve.

PO: I’m opening a fish store. I need a fish.

(Team goes off to work on “fish for fish store” and returns the next day with a goldfish.)

PO: That’s good. But it’s not enough. I need more fish. Different kinds of fish.

(The team goes off to work on “variety of fish for fish store” and returns the next day with guppies, mollies, swordtails, and angelfish.)

PO: Cool!

Or version two:

PO: I’m opening a restaurant. I need a fish.

(Team goes off to work on “fish for restaurant” and returns the next day with Poached Salmon in Dill Sauce.)

PO: That’s good. But it’s not enough. I need more fish. Different kinds of fish.

(The team goes off to work on “variety of fish for restaurant” and returns the next day with Miso-Glazed Chilean Sea Bass, Mediterranean Stuffed Swordfish, and Pan Seared Lemon Tilapia.)

PO: Yum!

Providing a little of the “WHY” for the “WHAT” has helped the team do a better job of delivering WHAT the product owner wanted.

Of course, these are simplified examples. There are many additional details the product owner could have supplied that would have helped the team dial in on exactly WHAT she needed. In the first dialog, the team had to make guesses about what the product owner meant by the rather broad concept of “fish.” This unending loop is an expensive game of whack-a-mole. Except with fish. In the subsequent dialogs, the team at least had the benefit of the context that was of interest to the product owner. In these cases, the team had a better understanding of the goal the product owner had in mind.

In Agile-speak, this context or goal information would be provided in the “As a…” and “…so that…” part of the story. “As a restaurant owner I want fish so that patrons can enjoy a variety of menu options.”

The less clear the product owner is on these elements, the longer it’s going to take for the team to guess what she really wants.


Photo by Ben Wilkins on Unsplash

Parkinson’s Law of Triviality and Story Sizing

From  Wikipedia: Parkinson’s law of triviality

Law of triviality is C. Northcote Parkinson’s 1957 argument that people within an organization commonly or typically give disproportionate weight to trivial issues. Parkinson provides the example of a fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bike shed, while neglecting the proposed design of the plant itself, which is far more important and a far more difficult and complex task.

I see this phenomenon in play during team story sizing exercises in the following scenarios.

  1. In the context of the story being sized, the relative expertise of each of the team members is close to equal in terms of experience and depth of knowledge. The assumption is that if everyone on the team is equally qualified to estimate the effort and complexity of a particular story then the estimation process should move along quickly. With a skilled team, this does, indeed, occur. If it is a newly formed team or if the team is new to agile principles and practices, Parkinson’s Law of Triviality can come into play as the effort quickly gets lost in the weeds.
  2. In the context of the story being sized, the relative expertise of the team members is not near parity and yet each of the individual team members has a great deal of expertise in the context of their respective functional areas. What I’ve observed happening is that the team members least qualified to evaluate the particular story feel the need to assert their expertise and express an opinion. I recall an instance where a software developer estimated it would take 8 hours of coding work to place a “Print This” button on a particular screen. The credentialed learning strategist (who asked for the print button and has no coding experience) seemed incredulous that such an effort would require so much time. A lengthy and unproductive argument ensued.

To prevent this I focus my coaching efforts primarily on the product owner as they will be interacting with the team on this effort during product backlog refinement session more frequently than I. They need to watch for:

  1. Strong emotional response by team members when a size or time estimate is proposed.
  2. Conversations that drop further and further into design details.
  3. Conversations that begin to explore multiple “what if” scenarios.

The point isn’t to prevent each of these behaviors from occurring. Rather manage them. If there is a strong emotional response, quickly get to the “why” behind that response. Does the team member have a legitimate objection or does their response lack foundation?

Every team meeting is an opportunity to clarify the bigger picture for the team so a little bit of conversation around design and risks is a good thing. It’s important to time box those conversations and agree to take the conversation off-line from the backlog refinement session.

When coaching the team, I focus primarily on the skills needed to effectively size an effort. Within this context I can also address the issue of relative expertise and how to leverage and value the opinions expressed by team member who may not entirely understand the skill needed to complete a particular story.

(John Cook cites another interesting example of Parkinson’s Law of Triviality (a.k.a. the bike shed principle) from Michael Beirut’s book “How to” involving the design of several logos.)

 

Image by Arek Socha from Pixabay

That Isn’t What I Expected

Adverse surprises during a team driven project are about as welcome as whooping cough at a glassblowers convention. Minimizing the opportunity for surprises comes down to how well expectations are defined at the very beginning and how well they are managed during the course of the project. Unidentified expectations are like landmines in the project path. When they explode, it’s bad and the course of the project WILL change. Product owners can’t elucidate all the expectations a stakeholder may have, but with experience they can define the major ones. With practice and attention, experienced product owners can tease out all but the minor expectations that are often dependant on discovery within the project’s sprints.

Key to this skill is knowing the questions to ask at the beginning. In my experience, stakeholders rarely deliberately hold back their expectations. They just don’t know what they don’t know and it is the product owner’s responsibility to establish clarity around expectations. Intuitively obvious expectations rarely play out as such.

A few questions for stakeholders that I’ve found helpful:

  • What business problems do you intend to solve with this project?
  • What do you need to see to know the project is progressing?
  • What will you see when the project is done?
  • What is your availability commitment for the duration of the project?
  • How often to you expect to meet to review progress?
  • How long do YOU think it will take to complete the project?
  • To what extent are your functional groups integrated?
  • Describe your process from design to development to implementation?
  • Are there other stakeholders we need to know about and include?
  • What factors have helped and hurt success with past projects?

This is by no means an exhaustive list of questions. And they may even seem obvious. The answers, however, are almost never obvious.

I also find it effective to challenge stakeholders with scenarios.

  • What happens if we discover this project will take two months longer than expected?
  • What happens if we discover a desired solution is technically unfeasible?
  • How will you support us if we encounter significant delays from client deliverables?

Product owners need to keep pursuing clarity around expectations until they are satisfied they have a good understanding of how the people side of the project will unfold. This will go a long way to helping the development team handle the technical side of the project.

While stakeholders answer these questions, product owners need to pay attention not just the words stakeholders use, but how they answer as well. They need to be scanning for underlying assumptions that drive the answers. These often reflect relevant cultural drivers which can signal significant expectations seemingly unrelated to the project at hand.

For example, perhaps the product owner has established the expectation of a three business day turnaround for feedback from the stakeholder when asked to review periodic project deliverables. “We can complete our reviews within three business days and work to get them to you as fast as possible,” says the stakeholder somewhat hesitantly as he looks off into the distance. Where the pain begins is when the inattentive product owner discovers that, while the feedback may be ready, the client organization has a thick layer of compliance and the feedback is hung up in legal for an additional one to two weeks…every time. If the stakeholder’s responses reflect something less than 100% commitment, keep asking questions designed to surface underlying assumptions.

As each sprint concludes, and eventually the project as well, the savvy product owner knows their work with expectations isn’t complete. Retrospectives for each sprint, each release, and the project conclusion should make note of the expectations that were missed and consider questions that could have been asked that would have helped surface the surprise expectations sooner.

This is also an excellent time to consider if any of the existing expectations have changed or if it appears there may be new expectations emerging. Internal forces, such as changes in team composition, and external forces, such as shifting market demands, can significantly impact the set of expectations a product owner is tasked with managing.

If  you expected to read these kinds of things about surfacing stakeholder expectations, then you’re probably an experienced product owner.

 

Image by S K from Pixabay

Drive for Teams

I recently re-read Daniel Pink’s book, “Drive: The Surprising Truth About What Motivates Us.” I read it when it was first published and I was still managing technical teams. Super brief summary: The central idea of the book is that people are mostly driven by intrinsic motivation based on three aspects:

  • Autonomy — The desire to be self directed.
  • Mastery — The urge to improve skills.
  • Purpose — The desire to engage with work that has meaning and purpose.

I find this holds true for individuals. However, when applied to teams optimizing for these three aspects can be problematic. If an individual on a team seeks to maximize autonomy, they are likely to come into conflict with the objectives of the team. For example, a software team that is tasked with developing a component that is expected to interact with several other components developed by other teams. If a single developer, in the interests of maximizing their individual autonomy, has decided to develop the component according to standards, design principles, and tools that are different from those of teammates and other teams (essentially, a local optimization,) then the result is likely to be sub-optimal overall.

Some individual autonomy must necessarily be sacrificed in the interests of effective collaboration. It’s possible, even desirable, that individual pursuits of mastery and purpose can be maintained. However, it may be necessary for an individual to focus on mundane tasks and the objectives of the team for periods of time. Finding ways to maintain a healthy balance between the intrinsic motivators and the purpose of the team is no small task and, when found, requires constant attention to maintain.

Perhaps it is possible to attach the team’s or organization’s purpose to the interests of the individual. Or sort for hiring people who have a personal purpose that is in-line with the organization’s purpose.

Image by M. Maggs from Pixabay