I hope I’m not the only reader who remembers the Highlander movie & television series. Duncan McLeod was an immortal amongst others who was fighting to be the last remaining immortal. In each episode, there was inevitably a decapitation or two as the immortal population was reduced to the final one.

I use the symbolism of the Highlander to remind myself of several aspects of agile project management. The first relates to focused teams and our earnest effort to reduce all levels of multi-tasking. The second reminder is the subject of what I want to explore in this article—the notion of investing in a single team to create a working model for your agile adoption efforts.

The team isn’t just any team. It’s your example team; a high performance agile machine that illustrates sound principles and delivers on the promises of agility. It’s a role model to other teams and proof that you can be agile in your specific organization and culture.

I have a bit of “mad scientist” in me, and this is the team you experiment with in trying out new and novel approaches for your domain. It’s the first team that moves from Scrum to Kanban. Or it’s the first team that tries out Cucumber as a BDD mechanism, while including the whole team in crafting acceptance test driven automation.

Let’s explore some of the characteristics of a singular example agile team.

Let’s first explore what the team isn’t

The team isn’t composed of special developers, the “best of the best”, or egos full of themselves. Yes, you might have some more seasoned folks on the team, but in ratios that are representative of your other teams and the overall population.

The team isn’t paid a premium wage or compensated in some special way. In many ways they represent a cross-section of your teams in experience levels and compensation structures. 

The team isn’t isolated from challenges such as interruptions, multi-tasking or dealing with unclean code.  They have an equal dose of the challenges facing every other team.

And finally, the team isn’t placed on a pedestal for everyone to see. Yes, it’s your example team and the one that illustrates the best properties and practices of your agile adoption and progress. However, they’re also just another team and equal to everyone else.

What the team is…

If you buy into creating a model team, it’s sort of hard to figure out what that might “look like” in the wild. While I don’t want to give you a prescriptive list like, do these five things and a magical event will occur creating a perfect model team, there are some hints I want to provide for behaviors and practices that you might want to model for.

I’ve categorized them into four areas: locale, smells, swarming, quality, and plan adjustments that we’ll explore in detail next.

Locale

The team is co-located and cross-functional. If at all possible, they sit together at one large table and work around and across from each other.  Their room has white boards and plenty of wall space for information radiators that are meaningful to the team

The team has some privacy, being located in a conference room or other walled-in area. They’re insulated from random noise and interruptions that might result from too open a space. I’ve often used the term “War Room” to describe the room dynamics.

The quarters are relatively tight in that everyone in the room is working closely together. Everyone can hear every conversation that is going on in the room. If someone is working remotely or on the phone, the room can hear the interactions.

I often get the question of whether you can leverage distributed or remote team members as part of your model team. I think the answer is normally yes. What you want to do, however, is allow budget for travel, training, and tooling that supports bringing your distributed team together as much as possible.

For example, when you’re initially forming your team, it’s a really good idea to bring everyone together for some initial introductions, training, and team-building. How else would you form a high-performing team?

Smells

An often used term with respect to agile teams is ‘smells’. These are patterns or trends that one observes when collaborating with the team.  Here are a few examples.

There’s a buzz in the room, it’s rarely the case where everyone is quietly working. Instead, team members may have headsets or earphones that allow for a sense of quiet if they need to “get away” for some private work.

Work is done primarily in pairs, but there are no restrictive rules which say you MUST pair at all times. Instead, it’s a more natural and organic level of pairing based on common sense, small groups, and the dynamics of the work. And everyone on the team pairs in one way or another!

There’s quite a lot of dynamic discussion going on in clusters. A lot of white board conversations. And every conversation ends up moving over to “working code” as the final arbiter of discussion and progress. So it’s about hovering around screens and talking about software design, behavior, adjustments, tests failing/passing, bugs, etc.

A final smell might be chaos. I like to describe agile methods as being an “uncomfortable” methodology. They are quite strict in practices and there’s an overwhelming feeling of “controlled chaos”, especially if you’re part of a well-performing agile team. The point is that it’s not totally scripted. Discoveries happen. Plans change. Adjustments need to be made. And everyone quickly adjusts and moves on. The goal that the team has committed to for the iteration or sprint is the thing that keeps the train on the tracks, with everyone focused towards meeting that goal.

Throughput and swarming

I frequently get asked whether the developers move ahead of the testers on the team during a sprint. This question implies a distinct separation between development and testing work and aligns the amount of work done along skill and functional boundaries.

My answer is always the same: “No”.

The team shouldn’t get “partial credit” for development work done. In fact, they should only get credit for fully done features, stories that are complete, with acceptance criteria met and completely demonstrable. Given that definition, teams would be better served to swarm around their work, limiting their stories in-progress (WIP) and getting their work done as soon as possible.

In fact, this isn’t to be considered an option, but the way in which well-performing and mature agile team should naturally behave. They understand that throughput (the time it takes to move a story from start to finish) matters. And that team collaboration around getting small sets of stories done as soon as possible (swarming) is the best way to do this.

In my experience, it’s a whole lot easier to talk about this than it is to deeply instill these behaviors in agile teams. This is why you’d want to get it right in your example team and see the best ways to influence this wonderful behavior.

Quality

It’s hard for me to explain the myriad of ways that quality activity needs to change in order for the team to truly be high performing. I guess the first attribute is that everyone on the team understands that quality is something you build-in and not something that’s tested-in.

Just the other day a colleague asked me what I thought were the highest value quality practices that influenced agile high performance. Perhaps sharing my reply would help. Here is the list of high-impact practices that I sent him and that I think are representative of an outstanding agile team:

  1. Fostering a whole-team view towards quality. Moving testers to "the front of the line" in that they collaborate on the requirements to get the solutions right.
  2. Pairing in general:  pair-programming, pair-testing, triad-pairing, paired code reviews, etc.
  3. Having the ability, willingness, and aggressiveness to stop work and apply corrective action(s) immediately.
  4. Test planning on an iteration and release basis while initiating whole team collaboration around what and how to test.
  5. Applying exploratory testing in a paired fashion, leveraging session-based (charter-driven) exploratory testing across teams.
  6. Performing active agile release planning so that teams gain a broad view towards dependencies and integration—including a DevOps or continuous deployment (CD) mindset.
  7. Naturally applying Unit Testing / TDD (Test-Driven Development) techniques within teams.
  8. Naturally applying ATDD / BDD (Acceptance Test Driven Development / Behavior Driven Development) and driving triad collaboration and conversations. The focus here should be collaboration first and automation second.
  9. Properly preparing for and conducting powerful sprint reviews or demos that engage stakeholders and customers to provide engaged, real-time feedback.
  10. The Mike Cohn strategy of the Agile Test Pyramid works, so leverage it—including the notion of multiple tools and layered approaches.

The first three quality differentiators listed are in order of priority. Beyond those, they’re not in any particular order. You might not need to apply all of these approaches to achieve high performance, but the list does imply some of the breadth and depth to effective quality practices. And I hope that I didn’t imply that “testing” was equivalent to “quality”.

Micro-adjustments and the stand-up

One of the most misunderstood aspects of agile teams is the nature of the teams’ commitment to a body of work in their sprint and then gathering to discuss their progress in the daily scrum. You often see teams look at their sprint plan as being a fixed set of user stories and their associated tasks.  They commit to these ‘cards’ and work diligently to execute to their plan.

Many teams allow their traditional planning instincts to rule too much within their sprints. The tasks and stories should only be a means to an end. The sprint goal is what the team commits to and in the daily stand-up they should be discussing progress towards achieving that goal and anything that comes up which:

  1. impedes or blocks achieving the goal,
  2. provides new information that adds, changes or removes work to support the goal, or
  3. Leads to discovery that influences interpretation of the goal—refactoring, under/over estimation, interruptions, skill gaps, etc.

These should be the real focus of the team. In the daily stand-up, the discussions should surround what I’ll call the micro-adjustments that an agile team makes each and every day.

These adjustments are goal-based discussions between the team and the Product Owner concerning goal achievement. Often, they require thinking about changing or jettisoning agreed scope within either the sprint or ultimately the release.

These are healthy discussions that get to the root of the agile methods “just enough” and “simplest possible solution” lean principles. Moving from a follow-the-plan focus towards a collaborative, micro-adjustment focus is one of the hallmarks of a high-performance team; an agile team that focuses on solving customer problems via their goals.

Wrapping up

One of my reflective improvements in many coaching gigs is not establishing a ‘model’ or ‘example’ team quickly enough. It’s usually driven by my need for an example that illustrates good agile practices from the same context that we’re initiating agile adoption; one that I can direct teams towards so that they can view an approach or technique beyond my just talking about it.

Brian Marick is a well-respected agile testing consultant and coach. Brian often speaks about the power of using an example and will often ask for one; an example for a user story, an example of an acceptance test, an example reflecting the customer’s problem, an example of a design you’re discussing, etc. He has even gone so far as to name his website www.exampler.com. Brian is a firm believer in examples being a wonderful communications device to focus dialog towards solutions.  I agree.

So is the point of this article to create an example team and then be done with it? NO!

It’s to create a model team as part of your agile transformation and then leverage the knowledge gained from them to improve your overall adoption approaches, techniques, and tools so that you’re consistently raising the bar and improving. A team that you can adapt with and learn from; one that is strongly embedded in your organizational culture and problem domain, and a team that can simply help guide your evolution…by example.

Thanks for reading,

Bob.