Nearly every day I encounter teams who are violently, passionately and extremely “going Agile”. Often they look at it as a life changing event. Quite often their thoughts surround the following:

• Managers and Leadership folks …consider it a force multiplier for driving more stuff to sell;
• Teams … consider it a way of having fun building software without the management overhead;
• Project Managers … are simply “deathly afraid” of it;
• And everyone else … are simply “along for the ride”.

And in a way, all of the above have a sense of truth about them, and I’ll certainly agree with the “you’re in for the ride of your life” aspect.

With these thoughts and emotions, come questions for me. As an experienced agile coach, I often get asked about agile tactics and practices. What works and what doesn’t.

Quite often, folks are looking for a “silver bullet” answer. For example, just tell me how to estimate using Planning Poker or what’s the right length for a Sprint? I often struggle with giving direct answers because of the complex and contextual nature of agile. There are no “singular answers”. Each team’s mileage will vary and they need to largely figure things out for themselves. And this ambiguity often frustrates my clients and students. Many of them don’t want to discover it “on their own”, but would much rather be simply told what to do.

That being said, there ARE some generative behaviors and rules for agile done well.  In this 2-post series, I want to explore common anti-patterns that I see in an effort to share “what not to do” in your agile journey. My hope is—this will help you start well and serve as a benchmark for some of the better practices and tactics.

But again, you’ll need to THINK and apply these to your own contexts.

Early Agile Adoption: Anti-patterns

1) Developer-driven Agile

Instead of a whole-team approach, the developers are mostly driving the adoption. I coached one client years ago that had 120 Scrum teams. Even though they had 300+ testers in the organization, all of the Scrum Masters were developers. You also see this focus with estimation and planning. While developers ARE important, agility is truly a respectful and appreciative team sport. You need to be inclusive of all functions in all aspects of your team and delivery.

A subset of this pattern is measuring progress by function. For example, where the developers do their part in delivering a user story (coding it) and then pass it along to others on the team to complete it. Then they move on to do more coding. So the measurement is functional (front-end development, back-end development, testing, analysis, etc.) This sub optimizes the teams’ delivery; much better to focus on everyone getting each user story completed together as soon as possible.

Healthy Pattern: Remember that Agile is a “whole team sport” that is inclusive, transparent, collaborative, and open.

2) Distributed Team Excuses

I probably get this question at least 2-3 times a week. It goes like this: we are a distributed team so many of the collaborative aspects of agile are too hard for us. Things like: pairing, code reviews, stand-ups, planning together, and sprint reviews are impossible. Can’t we skip the “hard bits”? I don’t think folks like my answer, but it’s always: No, you can’t.

As a distributed team you have to “commit to” the collaborative principles of solid agile teams—even though they’re hard. Ask your leadership for facilities to make collaboration easier (tools, webcams, video support, seating, flying folks around, etc.) but don’t use distributed agility as an excuse to minimize collaboration.

Healthy Pattern: Distributed teams commit to collaboration practices and innovatively improve their ability to behave as much as possible as a co-located team.

3) Interrupt-driven Work

co-authored Peopleware[i] in 1997 and wrote Slack[ii] in 2005. In each, he made the case for the power of focus, with less interruptions and multitasking for knowledge workers. I think everyone realizes that multitasking, while it feels like you’re going ‘faster’, will in the end, get less done. But yet, we still make the choice to churn ourselves at every turn.

Minimizing, encapsulating, and sharing impact data for multitasking costs is a hallmark of good agile teams. And the discipline comes from two directions, both outward towards your organization, but also inward within the team. It seems that “heroic fire-fighting” can be very addictive and individuals need to be weaned from this form of churn.

Healthy Pattern: Focus is crucial to getting more things done well. Try to limit interruptions and task switches at all turns by leveraging the core agile tenants.

4) Inmates are running the Asylum

A common anti-pattern I see is organizations confusing self-direction with letting the teams do whatever they want. The theory goes that agile teams should essentially figure things out on their own, without organizational rules or constraints. I once coached a team where the leadership literally would not provide any guidance, even when asked, due to the fact that they were supporting self-direction. It was absurd.

Leadership is necessary in solid agile teams. Constraints are quite healthy when they’re couched in a Definition of Done, in the working backlog, in goal-setting, and in planning. And teams need to follow solid behavioral norms, while trusting and respecting the basic agile roles as they are defined.

Healthy Pattern: Realize that self-directed teams are indeed…directed. There are effective constraints and guidelines that need be applied.

Wrapping Up

I’ll continue this post with four more anti-patterns in the next post. I hope you’re getting some insights from the discussion. But I don’t want you to focus on the anti-patterns too much. They are simply learning tools.

Your real focus should be on establishing your own set of “healthy agile patterns” within your own teams. Now that’s an investment worth making!

Stay agile my friends,

Bob.