The Agile Project Manager—There Can Be Only One!

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 me 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 what I want to explore here—the notion of investing in a single team to create a working model for your agile adoption efforts.

This 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 & 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 Behavior Driven Development mechanism, while including the whole team in crafting acceptance test driven automation.

Let’s explore some of the characteristics of this 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 full of themselves ego’s. Yes, you might have some more seasoned folks on the team, but in ratios that are representative of your other teams and 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 unkempt legacy 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. But, they’re also just another team and virtually 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 some behaviors and practices that you might want to model for.

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 “Team 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. But what you want to do is allow budget for travel, training, and tooling that supports bringing your distributed team together as much as possible—both physically and virtually.

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 is ‘smells’ with respect to agile teams. 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. Not restrictive rules such as—you MUST pair at all times. Instead, it’s a more natural and organic level of pairing—as it makes sense, in small groups, based on 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 “working code” as the final arbiter of discussion and progress. So—hovering around screens and talking about software design, behavior, adjustments, failing vs. passing tests, bugs, etc.

A final smell might be chaos. I like to describe agile methods as being an “uncomfortable” methodology. They are quite strict focused towards specific practices and there’s an overwhelming sense of “controlled chaos”, especially if you’re part of a well-performing agile team. Point being—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 & Swarming

I get asked this question all of the time—can the developers move ahead of the testers on the team during a sprint? This question implies a distinct separation between development vs. testing work and aligns work done-ness along skill & functional boundaries.

My answer is always the same—no!

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

In fact, this isn’t 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—to discover 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 a team to truly become high-performing. The first characteristic might be everyone on the team understanding that you don’t test-in quality…you build it 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 reflective in 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 and getting the solutions ‘right’.
2. Pairing in general: pair-programming, pair-testing, triad-pairing (developer + tester + product owner), paired code reviews, etc.
3. Having the ability, willingness, and aggressiveness to stop-the-line and apply corrective action(s) immediately.
4. Test planning on an iteration & release basis while initiating whole team collaboration around strategies for what & 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 & integration—including a DevOps mindset or continuous deployment (CD) view.
7. Naturally applying Unit Testing / TDD (Test-Driven Development) techniques within teams.
8. Naturally applying ATDD / BDD (Acceptance Test Driven Development / Behavior Driven Development) – driving Triad collaboration & conversations around. 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 active feedback.
10. The Mike Cohn / Agile Test Pyramid strategy works…so leverage it; includes the notion of multiple tools and layered approaches

The list is in priority through the first three quality differentiators. 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 a set of effective quality practices. And I hope that I didn’t imply that “testing” was equivalent to “quality”.

Micro-Adjustments & the Stand-up

One of the most misunderstood aspects of agile team is the nature of the teams’ commitment to a body of work in their sprint and then gathering daily to discuss their progress in the daily scrum. You quite 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 rule too much within their sprints. You see 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-to-goal. And anything that comes up that—

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

should be the real focus of the team. And 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 surrounding goal achievement. Often, they require thinking around changing or jettisoning agreed upon 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 personal improvement reflections 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 “point 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 & coach. Brian often speaks about the power of an “Example” and will often ask for one—an example for a User Story, an example of an Acceptance Test, an example reflecting the customers problem, an example of a design you’re discussing, etc. He even has 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 dialogue towards solutions. I agree.

So is the point of this post 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 your 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 help guide your evolution…simply by example.

Thanks for listening,

Bob.

Don’t forget to leave your comments below.