Skip to main content

Author: Robert Galen

The 95% Rule for Agile Leaders

Now that I think about it, a “rule” sounds a whole lot more formal than I intend it. Perhaps I should call it a guideline or a heuristic or a thinking tool?

Ah, I don’t know. Let’s get into it and make that determination afterwards.


The Rule

It’s simple really. It revolves around telling your teams what to do. That is providing your directives, strong opinions, and guidance when you’re interacting with your fledgling Agile teams.

The premise is that for every 100 opportunities that you are confronted with in your organization to provide prescriptive advice to your teams, you get no more than 5 times actually to tell your teams what to do.

You have to keep the tally in your head.

You have to be honest about it.

You shouldn’t tell anyone else you’re doing it. It’s just for you.

What does the rule do?

As leaders, it helps us by:

• Preventing us from micromanaging or being overly prescriptive.

  • Forcing us to carefully consider our engagement points with the team.
  • Hopefully, it encourages us to keep a few opportunities in reserve, in case there is an emergency intervention needed
  • In general, it causes us to pause and think before we go mucking around our teams – telling them what to do.

But it does give us the opportunity to, dare I say it, LEAD because it also encourages us to engage when it matters the most.

Circumventing the Rule?

I hate to say it, but you can circumvent the rule. How, might you ask?

{module ad 300×100 Large mobile}

You can circumvent it by asking, carefully crafted, open-ended questions of your team. Not trick questions or leading questions, but true curiosity questions or important questions that your teams may be missing.

These questions are intended to get your teams thinking about things from a different perspective. And they are fair game, in that they don’t count against your 5 allowed prescriptive comments.

Wrapping up

I told you it was simple.

And I know what you’re thinking. Is this something I made up OR do I actually use the rule myself?

I actually use it. And I’ve found it helps me to achieve the balance I need to be an effective Agile leader. My hope is you find the same with it.

Oh and, let’s leave it as a RULE for now. I think you’ve got to practice and earn the right to loosen it up a bit.

Stay agile my friends,


Leadership Agility Compass – Reframed

I’ve often held the perspective that there are no real ‘L’eadership roles within Agile teams. The entire notion of a self-directed team in some ways confuses the role that leadership plays within Agile contexts.

One of the leadership dynamics, at least from my perspective, is at the Agile or Scrum team level. I’ve always observed that leadership is one of the central ingredients to a successful Agile adoption. In fact, the larger the scale, the more important it becomes.

That being said, the larger the scale, the more incumbent managers and leaders struggle to figure out the new role they need to play in the shift. And quite often the organization really doesn’t support them (coaching, training, funding) in this effort. It’s sort of left as an exercise for the student; which mostly fails.


Leadership Agility Compass

I’m intrigued by Bill Joiners’ Leadership Agility Compass idea presented in his book – Leadership Agility. For the post I’m referencing his LinkedIn article that can be found here:

The compass has four “territories” that cover areas of concern or focus areas for the Agile leader. For the purposes of my post, I’m going to reframe these territories from being management or leadership-centric, to being tied to the ScrumMaster and Product Owner roles within the Scrum framework.

I think the territories present an interesting view that supports the expansive focus that these two roles should have. That is if operated by more experienced individuals.

Here are the 4 territories:

  1. Context-Setting Agility: The larger systemic context surrounding your initiative.
  2. Stakeholder Agility: Your initiative’s key stakeholders.
  3. Creative Agility: The specific problems and opportunities your initiative must address for it to be successful.
  4. Self-leadership Agility: Yourself as a leader.

Next we’ll explore each in turn.

Context-setting agility

Think of a specific real-life initiative you are planning or are already undertaking. Focus your mind on the doing of this initiative. Now, step back and let the larger strategic context of your initiative come into view. As you scan this larger environment, you recognize and anticipate changing circumstances, you decide which initiatives are most worth your time and effort – and why, and you clarify the outcomes you want each initiative to achieve.

From an Agile team leadership (SM+PO) perspective, quite a lot of this falls to the Product Owner. It implies engaging your team in backlog refinement activity towards not only the current or next sprint but with enough look-ahead so that they (and you) can contribute to future release planning and forecasting.

And this isn’t simply focusing towards features, but having a balance across features, infrastructure, defect repair, and addressing technical debt.

It also implies that the ScrumMaster and the Product Owner get together to provide a “vision” for their team. Often this only focuses on the product or application the team works on. And yes, that’s certainly an important part of it. But it should also include continuous improvement initiatives and team investment. For example, what is the vision around team cross-training, investment in automation, or experimentation.

Finally, all of this good strategic thinking needs to be communicated outward and upward so that the organization is fully aware of and supporting of your vision.

Stakeholder Agility

Now, when you step back from focusing on your initiative, bring to mind its key stakeholders. These are the people and groups who will be impacted by your initiative and whose support you need for your initiative to be successful. As you step back and survey this territory, you can identify your stakeholders, then put yourself in their shoes: How do they view and feel about your initiative? To what extent are they aligned with what you want to do? To the extent that you are not aligned, how can you engage with them in ways that might lead to more optimal alignment?

This is often one of those areas where many ScrumMasters and Product Owners lack skill and courage to truly align and innovate their connection to stakeholders. Often it is much simpler to deliver “the ask”. But that may not tell the entire story surrounding your stakeholders’ challenges and real problems.

In larger scale efforts, often Product Owners have many “stakeholders”. I remember a set of teams at Deutsche Bank a few years ago that had approximately 15 stakeholders spread about the world for a specific application. It was incredibly challenging for the Product Owners (2 in this case) to align everyone. But that’s exactly what the teams needed in order to work on a cohesive set of features.

The above example is a place where ScrumMasters with strong facilitation skills can shine. For example, you could leverage playing value poker with included funding as a way for the large stakeholder group to align their priorities towards shared business value. And it also requires a great deal of courage to tell some stakeholders – “No, clearly this feature doesn’t have the global priority to fit into the teams’ capacity.”

Here’s a link to an article exploring value poker

Creative Agility

Another territory is made up of the specific issues your initiative needs to address. Creative agility starts with stepping back and identifying what these key issues are and how they are related. It also involves diagnosing the underlying root causes of these issues, and developing creative solutions. Why creative solutions? Due to the nature of today’s turbulent business environment, the problems that need to be addressed tend to be novel and non-routine and to cross organizational boundaries. Research has shown what you already probably know: The best solutions to these “ill-structured” problems come when we engage our capacity for creative thinking.

This territory probably excited me the most from an SM+PO role perspective; mostly because it’s often a weak area of both.

I’ve often talked about Scrum/Agile not being a speed play, stating that it’s a quality play that has the potential to go fast. But that potential is only realized by focusing on certain things. I mention four areas in this post, but the one that aligns here is the creative or innovative problem solving.

It’s often the hardest area to truly inspire your teams to engage in, but it’s the one with the greatest promise from a speed and customer value/delight perspective.

I can easily think of three areas where you can both make a huge difference in your teams.

  1. Creativity when refining your backlog
  2. Allowing for space (slack) for your teams to think creatively and innovate.
  3. Encouraging experimentation (learning) as much as possible, and yes I’m going to say it, embracing failure
  4. Honoring “all voices” within the team, because you never know where the creativity and innovation will come from.

I sometimes tell Product Owners that a big part of their role is making “mini-PO’s” out of every member of their teams. This sets the stage for creative solutions, as everyone starts thinking of the customer, their persona, and creative solutions to their biggest challenges.

You get much better results of it’s the entire team envisioning the future creatively.

Self-leadership Agility

The fourth territory is, frankly, the most frequently overlooked. There is a saying: “Wherever you go, there you are.” You yourself are at the heart of everything you do as a leader. You activate your self-leadership agility when – before, during, and after an initiative you lead – you step back and reflect on yourself. Stepping back repeatedly in this way allows you to accelerate your own leadership development by clarifying your strengths and areas where you want to improve, proactively finding opportunities to stretch and grow as a leader, and reflecting your experiences as you continue to experiment toward higher levels of effectiveness.

I agree with the point Bill makes here that this area is often overlooked. I highly recommend that a Product Owner and ScrumMaster frequently assess themselves and their teams. This normally begins by creating a “leadership partnership” between the two roles where they work together to lead the team. The partnership allows for honest and open communication about anything – weaknesses, blind spots, challenging conversations to be held, stakeholder “management,” etc.

For example, privately having ongoing discussions between (SM+PO) related to team challenges, strengths & weaknesses, and opportunities for growth. Then presenting these ideas for consideration and action in retrospectives. I’ve found that Agile teams rarely can figure out everything from their own lens. Having the ScrumMaster and Product Owner provide that courageous and independent view can often be the difference in teams achieving a high level of performance.

Another important part is meeting with the leadership and stakeholders for their team, usually behind closed doors, and asking for honest feedback about themselves and their teams. Seeking out all forms of feedback and embracing it towards action and change is a critical skill.

Wrapping up

I just want to thank Bill for writing such a neat book that has relevance for leadership and beyond. I’d encourage you to read it, but, more importantly, to leverage the concepts to change and broaden your lens.

Agile teams need their ScrumMasters and Product Owners to step up to a different level of thinking and role beyond facilitating a stand-up and writing user stories. And this model helps you in that journey.

Stay agile my friends,


Creating Self-Directed Teams – A Question of SPACE

Over the past few months, I’ve been coaching my clients who are in the early stages of adopting Agile approaches for software. Most of them are adopting Scrum, but a few are adopting Kanban.

Universally, one of their complaints is that their teams aren’t “stepping up” to the

  • Empowerment
  • Responsibility
  • Accountability
  • Passion & Energy
  • Creativity

that is implied as part of the culture of self-directed, Agile teams.

To say that they are disappointed is an understatement. And these comments are coming from all levels of the client leadership teams.

But it may not be the team’s fault

I have a shock for these folks. It may not be the teams that are the problem in these situations. It may be the leadership team that is still standing in the way of the team’s self-organization.

How, might you ask?

Well, lately I’ve been referring to the problem as – not giving the team enough SPACE, space to grow, to become autonomous, to become self-directed.

You see self-direction doesn’t just happen because you adopt Scrum, Kanban, or another Agile variant, or because you say ‘Agile’ twenty times to your teams. It needs a fertile space to grow. It needs to be watered and fertilized.

Related Article: How Kanban Can Change Your Life

It needs an honest environment.In far too many cases, this is simply not happening.

So what are the aspects of Self-Directed SPACE? Let’s explore a few that come to mind.

Managers – stop managing

The first element is for your managers to stop “managing”. In other words, stop trying to tell people what to do, estimating their work for them, or solving their problems for them.

I usually share the notion of “push” vs. “pull” to managers who are making the transition to Agile. You want to resist “pushing” yourself into the teams at all cost –the less frequently, the better. However, IF the teams ask you for help, or otherwise “pull” you into the team, then indeed assist your team. Push reduces their autonomy while pull supports it.

Be careful what you measure

Measures often drive behavior. For example, if you measure code complete milestones within sprints, then you’re emphasizing development-done rather than a whole-team done focus. So don’t be shocked if your team doesn’t gel as a good Agile team. It’s probably because of the way you’re measuring or incenting them.

I remember once doing an Agile training activity for a Ukrainian team. I spent a couple of hours emphasizing the mindset of agility, including the collaborative aspects. Near the end, one young man raised his hand and said:

But Bob, we are not incented to work together. Our compensation model and bonus structure is solely focused on individual performance. I don’t care about my team member’s performance or helping them; I only care about myself.

At that point, I respectively closed the class.  

Team Leads

I’ve run into quite a few organizations of late that have the notion of “Team Leads” within their Agile teams. Quite often they’re also serving as Scrum Masters. In general, I’ve found that anytime a team member is declared a “lead” they’ll have a requisite of “followers”. That is, the self-directed nature of the team succumbs to the leader. Not always, but often.

If I can, I try not to create unnecessary hierarchies within Agile teams. I want the leadership to emerge from each team member as appropriate and as the situations dictate. You see, in a self-directed team, anyone and everyone can and should lead as appropriate.


The language you use becomes very important. Do you reference developers, as “development” and do you reference testers as “test”? Or do you reference your teams as cross-functional teams?

I try to change my language to deemphasize organizational silos and instead leverage team language whenever possible. And I encourage all leaders to do the same. I’ve found the language we use (verbal, tone, body) sets an incredibly important tone with organizations. And the emphasis from an Agile point of view should be on the team.

Team organization

One of the craziest ways to build an Agile team is to connect a disparate group of remote folks from around the world and then call them a team.

I often get challenged that remote Agile teams simply don’t work. But, when I explore the dynamics that the challenger is talking about, I find the resulting organization structure to be, can I say this, insane.

Try to build your teams as sensibly as possible. Co-locate as many as you can, have as few time zones between them as you can, and support them with collaborative tooling. And, when you form your teams, pay the price to get them all in one place to kick things off.  Here’s another related article.

Scrum Masters

I don’t know what it is about today’s organizations, but I encounter so many who aren’t willing to pay for Scrum Masters – or at least experienced, it’s my job, Scrum Masters. Why? Often it’s because they don’t understand the role. They trivialize it and minimize the need for it. But Scrum clearly states that solid teams include the Scrum Master. It’s an important part of a Scrum team, and it’s not a side-effort. It’s a full-time role or job within the team.

I also believe it’s a crucial one. Sure, perhaps not the simpler parts of the role – like impediment remover. But the parts that include coaching the team and guiding them towards continuous improvement, effective collaboration, and high-quality delivery.

Give your team space by providing them with a focused and capable Scrum Master – then support the Scrum Master with ongoing training, coaching, and mentoring.

Failure and Discovery

I often talk to leaders making the transition to Agile about enabling or empowering their teams to try new approaches and to possibly support failure.

The room usually goes quiet, and everyone gives me a look like I’m trying to sell them a bridge in Manhattan. There’s almost a universal reaction that – Bob, we don’t fail around here, so please don’t mention the ‘F’-word.

The reality is that failure is a part of learning and a part of success. It lies at the core of innovation and creativity. And as leaders we need to create or encourage an environment of risk-taking, learning, and exploration within our teams. That is if we want them to grow and learn and become an outstanding team. Here’s another related article.

We also need to trust their intentions related to this journey.

Let the team solve their challenges

I liken many managers to birds circling their teams, ready at a moment’s notice to swoop in and save the day.

A few years ago, I worked with a manager who I’ll call Bob. Bob was an incredibly experienced and knowledgeable manager. His intentions were also good, that is, all he wanted to do is help his teams and our business to succeed.

When his teams struggled a bit or encountered an obstacle, in a few seconds, Bob was there to help them. He would leverage his vast experienced and essentially tell them how to handle the situation.

The Scrum Masters on Bob’s teams has a term for this. They would tell me that Bob swooped in today. In fact, some of them kept a swoop-ometer to keep track of the number of swoops.

As I coached Bob, you see he reported to me, I told him that this behavior was detrimental to the teams becoming independent and self-directed. That he was inadvertently taking things on himself rather than allowing the team to face and solve their challenges. In other words, I told him to stop it!

Wrapping Up

For you Star Trek fans outer space was always – The Final Frontier. I beg to differ. I now think that team space is the final frontier.

It may be just as hard (or harder) to achieve than leaving earth’s orbit on another adventure. Why, because traditional management techniques and approaches are a strong part of our DNA and incredibly hard to shift away from.

But if your goal is to foster a sustainable, empowered, trusted, and engaged self-directed team, then shift you must.

Engage #1 Stay Agile my friends,


With All Due Respect

Giving feedback is one of the things I like most about Agile methods. There’s this thing about it though. It’s not that easy to give effective feedback. Lately, I’ve been hearing Agile team members start their feedback with the following statements:

  • I don’t want to rain on your parade, but
  • I don’t mean to be negative, but
  • I don’t mean to criticize, but
  • I don’t mean for you to take this the wrong way, but…

And then there’s the Ricky Bobby quote from the movie Talladega Nights regarding – “With all due respect…”

The first time we hear it is right after Ricky Bobby has cost his racing team 100 points for flipping the bird on TV. His team owner confronts him about it after the race and the following exchange is priceless.

Ricky: “With all due respect, Mr. Dennit, I had no idea you’d gotten experimental surgery to have your balls removed.”

Dennit: “What did you just say to me?”

Ricky: “What? I said with all due respect!”

Dennit: “Just because you say that doesn’t mean you get to say whatever you want to say to me!”

Ricky: “It sure as hell does!”

Dennit: “No, it doesn’t–”

Ricky: “It’s in the Geneva Conventions, look it up!”

Clearly none of these prefaces is honest or effectively mask the intent of the person to give very critical feedback. But often they allow the giver to do it poorly under the banner of – well, I said with all due respect…or I warned you.

Related Article: How to Motivate a Team?  Honesty and Respect!

Consider the outcome

I would encourage everyone in Agile instances to be more thoughtful with their feedback. Remember, your job isn’t simply to say it. It’s to say it in such a way that it is effectively received and drives the changes you are trying to influence.

What I’m trying to say is that effective feedback should be measured by the outcomes that it inspires and not by the simple fact of saying it.

Other considerations

Here are a few other key considerations to think about before you give someone feedback in your next sprint review/demo, retrospective, or other Agile ceremony.

  • • Have you prepared to give the feedback or are you just reacting? Often reacting in the heat of the moment is a bad idea. Give yourself some time to be thoughtful about what you’re going to say and how you’re going to say it. In other words, prepare!
  • Timing is everything. We’ve all heard that giving feedback at the moment is always best – so not waiting too long. But as I mentioned above, you can deliver feedback too quickly as well. I often find that waiting a little bit helps me to be more thoughtful and effective in my delivery.
  • Consider your context. Do you know the team or the person you’ll be giving feedback to? What is their history related to receiving harsh or constructive feedback? Do they do well or struggle with it? Have they received it in a while? And have the received similar feedback to what you’re about to give them?
  • The environment is important – public, private, or something in between? Where you give the feedback is almost as important as when you give it. I like to lean towards more private situations – limiting the exposure to just those that need to receive the feedback.
  • Ask permission first. I don’t know where I learned this, but along my career someone told me always to ask first. And, if the answer is no, now isn’t the time, then respect that. This connects to the timing is everything earlier point. The feedback should be timed conveniently for the giver AND the receiver.
  • Face-to-face is best. I find some many situations in Agile teams where feedback is given by email, text, or some other documentation based mechanism. Call me old-fashioned, but I’m a firm believer that feedback should be best-served face-to-face so that you can see the body language of the receiver and adjust your message according to how it’s being received. That’s so much harder to do (impossible) via email.

Wrapping Up

I’d argue that this theme applies to all sorts of feedback. For example, have you ever received an email reply that was clearly sent too soon? One where you could tell the sender had reacted to something in the email and said things that (you imagine) they now regret?

I’ll bet you have. I have too. In fact, I’ve been on the sending side of many of those messages. But I’ve learned. Learned to hold onto my messages and not simply react too quickly. I often wait for a day to send them. And what a difference a day makes in the crafting of my feedback!

So with all due respect, I want to encourage all of us to be careful and thoughtful in giving our feedback within our Agile teams. But indeed, please GIVE it!

And if you’re interested in learning to be more effective, then look at the “outbound side” of your feedback. In other words, did it inspire the action, change, or adjustments you were hoping for? If not, then we need to continue to improve in our delivery skills.

Stay Agile my friends,


BTW: This blog post was inspired by a recent bit of feedback I received to a tweet. The person began their reply with: I don’t want to rain on your parade, but… Now perhaps their intentions were good, but with all due respect, their comment basically sucked. Seriously though, it inspired this article and I do appreciate that inspiration towards the importance of effective feedback in all of it’s various forms.

Building Agile Teams – A Primer for Organizational Leaders

I frequently get asked about the dynamics of building Agile organizations from an organization structure point of view.

The most important point is that you don’t create a high-performance Agile organization by the defined structure. Managers don’t do it; neither do VP’s or Directors.

Surely we set the stage. But the teams are the ones that create the organization. We don’t have to optimize the structure for every technical hurdle or risk. Or create a structure that perfectly balances skill-sets and experience across all functional roles.

Whew! I’m glad because I never figured out how to do that perfectly anyway.

We simply pull together a reasonable view to structure and attempt to be as balanced as we can. Then we form the teams, provide some intelligent constraints, get out of their way, and allow them to grow and perform. It’s as simple as that!

Over time, the teams learn and adapt and will suggest changes. We need to be supportive of the insights and learning and help them adjust structures for increased productivity, quality, and value-based delivery.

What I thought I’d share in this article is some of the personal guidance I’ve developed for myself and my leadership teams when I’ve “built” Agile organizations.

Remember, these aren’t guaranteed rules, just things that I’ve found very helpful in setting the stage for enabling great Agile teams to emerge.

Self-Directed, Cross-Functional Team

First of all, we have a responsibility towards creating self-directed teams. These are teams that are composed of a cross-section of skills and capabilities to implement their Product Backlogs – the work the teams will be given.

Beyond raw technical skills, experience also comes into play, especially from a business domain perspective. For example, I usually try to place a more experienced engineer who has the technical chops on each Scrum team in the areas the team will be exploring. Sometimes we refer to them as a Technical or Team Lead or similar title. The title isn’t what’s important. What’s important is that we have inserted a seasoned and experienced person on each team.

But it’s never perfect.

Related Article: Agile Teams – The Weakest Link

I think we’ve all realized that there will always be constraints. You might not have a particular skill-set in-house or enough testers to go around. I think our job as leaders is to wisely distribute the skills we do have in a fair and balanced way across a set of teams. We should make this process as transparent as possible to our teams. And, if we have discovered gaps, we need to share our intentions and plans to fill those over time.

One way to handle these short-term gaps is splitting or sharing folks across teams. While not optimal, sometimes it’s all we can do.

Oh and, ASK the teams for feedback.

Oh and one more thing. I always suggest vetting your proposed organization alignment and team structures with your team members. They’ll ask questions, provide feedback, and even raise issues that you never thought of. It will help you better align your initial stab at teams.

But beyond that, it will increase the understanding of the teams as to your “design choices” and help to create buy-in when you roll out your teams.

Distributed Teams – Good?

Let’s make one thing perfectly clear – distributed teams are hard. They’re out of the “sweet spot” of Agile team construction, that is: co-located and cross-functional teams.

Does that mean you can’t make Agile approaches work in distributed teams? Of course not. But it does mean that you should adjust your thinking when it comes to setting up the teams. Here is my baseline guidance:

  • As often as possible, keep teams entirely together. Even if that means you have to make some skill-set, budget, or strategic compromises.
  • If you do have to distribute a team, try to do it intelligently. For example, try to keep the developers together in the same place…or the testers. So they can have a modicum of teamwork.
  • Invest sufficiently in tooling that will foster collaboration. For example, development tools, Agile tools, video conferencing, interactive sites, etc. Let your team(s) explore and define their needs and simply respond to their requests.
  • It’s actually quite hard to have a Scrum Master or Product Owner who is separated from their team. If you must do this, consider asking someone on the team to serve as a local liaison for the remote person to connect to.
  • Invest in getting the entire team together at the beginning of the project (charter / initiation). Do some training, team building, and run the first sprint as a localized team. This will pay huge dividends longer term.
  • Make sure you allocate sufficient funding for frequent team member travel to/from your different sites.

And I think most importantly, coach your teams to really invest in solid Agile teamwork and collaboration practices no matter the distance. For example, the team needs to commit to daily stand-ups, backlog refinement, and sprint planning AS A TEAM no matter how challenging the time and/or cultural differences.

And one final point, you’ll get your best results with co-located, self-directed, cross-functional Agile teams. So whenever possible, consolidate your distributed organization towards this goal. In other words, be relentless about moving your teams closer together over time.

Part-Time Team Membership – Good?

I often get asked “Can you have part-time team members on a solid Agile team?” I think the correct answer is…it depends, but I try to avoid the situation as much as possible.

If, for example, everyone on a given team were at 50% availability, then I’d say it’s a terrible idea. We’d clearly need some team members to be fully engaged and focused on the tasks at hand.

But if you asked me whether we could have a part-time performance testing person on a team? I might say yes. Or whether a part-time technical writer can be on a team? Again, it might make sense.

In my mind there are two reasons to have shared or part-time people assigned to Scrum or Agile teams. First, they might have specialized skills that aren’t needed full-time on every team. A good example of this would be a technical writer. The second reason is the ebb and flow for some specialized folks.

For example, I made the mistake once of placing UX folks full-time across a group of Scrum teams. The end result was that they couldn’t effectively deliver on many aspects of their jobs because the focus of the teams was on feature execution and the UX folks needed some time for design “look ahead” and research.

We ended up connecting them part-time to the teams when needed and this created a much more effective balance for them.

Do We Really Need a Scrum Master?

For someone as wordy as I am, the short answer is yes. I even recommend that organizations find a Scrum Master-like person (a coach) for new instances of Kanban. This role, if staffed with the right people and done well, is a game changer in accelerating new Agile adoptions.

Do they need to be certified? Perhaps not, but they need experience instead of or in addition to certification.

Can you do a time share with an internal team member as a Scrum Master? Sure, you can do anything you wish. But I’ve found that part-time (or multi-tasked) Scrum Masters aren’t a good idea. I much prefer to invest in professional and experienced Scrum Masters. And, if I’m running short of funding, I’ll overload them a bit with two teams each.

Not finding/hiring/training Scrum Masters in your organization is one of the most shortsighted cost decisions you can make when you’re planning for your Agile transformation. Yet, I see it all the time – sort of a penny-wise and pound-foolish mistake.

And while I won’t get into it much here, taking that same approach with Product Owners is potentially even more dangerous.

Team Size

When considering team size, one of the first things I think about is the general Scrum advice of teams in the range of 7 +/- 2. I’ve found that to be sound size advice for forming Agile teams.

I’ve also found that even within that range, smaller is often better. For example, in my experience teams of 5-6 people are the sweet spot from a productivity and efficiency perspective. I’ll give you an example:

I once worked at a company called ChannelAdvisor as a Director and Agile Coach. We had one team that had grown to about 12 individuals. We were growing as a company and we had a habit of growing our Scrum teams with new hires and then when they reached a certain size, we would split them.

This team was working really well, but it was large. Before we could naturally split it, a business priority shift happened and we split the team to double our focus on another business initiative. So we split them into two teams of six. I’ll never forget this example.

In the first sprint of the original team, their velocity only took a marginal impact, 1-2 points. So we had literally cut them in two, BUT their velocity didn’t reflect a change. How can that be you might ask? We determined that reducing the team from 12 to 6 individuals simplified the communication and their effectiveness – to the point where half the team was nearly as productive as the larger group.

I try to keep teams as small as possible and still contain the requisite skills to get the job done.

Team Cohesion – Does it Matter?

I’ve encountered organizations that move team members around from team to team as if they’re playing a game of musical chairs. Sure, there’s always a reason for it. Often something like – this project is late so we’re reassigning more team members to the project for the next 30 days to recover it.

The people are treated like commodities or as if they’re fungible. They’re not by the way and I’ve written about this before. But that doesn’t seem stop us from treating them as if they were.

The impact of this can be severe – especially within Agile teams. When I’m in a leadership role in an Agile organization, the last thing I do is disrupt the cohesiveness of my teams. I consider well-formed, high-performance teams to be a critical aspect of my delivery proposition.

It takes so much time to build a cohesive team that I wouldn’t think of changing it willy-nilly.

So the answer to this question, and I know you realize it too, is YES, team cohesion and stability matter. Try to keep your teams together as long as they’re healthy and performing, even when the business pressure is on.

Sitting Together

There is an incredible amount of debate surrounding how to set up your team areas for collaboration. One extreme is to keep team members in cubes or offices that separate individuals and impede teamwork and collaboration. The other extreme seems to be throwing everyone into a large room at a single table.

Both of these have a grain of truth in them and the goal should be somewhere in between the two. There is a relatively old convention or tactic within the Extreme Programming community called “Caves & Commons” that makes the point well. It implies that Agile teams need both – “caves” for private, individual immersion and work and “commons” for collaborative work.

I believe the best spaces (and team dynamics and results) include both types of space for the teams’ use.

I’ve written about this “space dilemma” before in another article. And this InfoQ article does a nice job of exploring the options as well.

Identity and Ownership

I have two loose rules when I’m trying to guide and determine what teams work on. First, I work with the business, Chief Product Owner, and the PO team to decompose the business products/projects towards a meaningful set of focused themes.

Then I try to staff the teams to align with these Product Backlog themes. Clearly each stream gets a Product Owner. Not only do I want the team to be staffed in order to successfully deliver on the business expectations, but I want the backlog stream to allow for having an identity and end-to-end ownership of all of the work. By that I mean they own the maintenance, feature development, technical evolution, and future release roadmap for their product or feature area.

I’ve found that giving each team a sense of holistic identity and ownership is key to establishing team empowerment, ownership, and ultimately delivering great results.

Wrapping Up – 4 Biggest Mistakes

To wrap up this discussion, I believe there are four primary mistakes that most organizations make when building their initial team structures for Agile execution:

  1. Not engaging their teams in the organizational modeling process;
  2. Not viewing their organizational modeling as an iterative, learning process;
  3. Not applying appropriate training and staffing of their SM and PO roles;
  4. And not leveraging the opportunity for change, at all levels, that an Agile transformation offers.

I’ve had the wonderful opportunity of creating a few high-performance Agile organizations. The advice I’m sharing in this article isn’t theoretical or academic. It’s based on my own hard-won experience and realization of what works. And yes, I realize how challenging some of my advice will be for most leaders.

Nonetheless, I stand by it and hope you try it. I promise you it will be worth your efforts.

Stay Agile my friends,


This is an article by Mike Cottmeyer that takes a different approach to constructing your teams. He’s looking at alignment to various business dimensions. I don’t agree with some of the intent behind it, BUT it is an interesting read related to my articles theme.