Is More Really Better?


One of my favorite things about being and Agile coach is connecting with the Agile community through conferences, meet-ups, and other networks.  Because of these connections I get to interact with  Agilists all over the world.  Over the past few months I’ve noticed a concerning trend coming from the Scrum Master community.  They are telling me with excitement, “I’ve finally worked myself up to two teams!”  Some have said they are now working with three or four teams.  The thing that concerns me is that they seem to view spreading themselves across multiple teams as an accomplishment.  I am hearing pride in “being busy” and “being able to handle more” and that tells me that we still have work to do.  It tells me that there may still be an anti-pattern running rampant in our Agile organizations telling us lies.

The belief that “the more I can handle and the busier I am the more valuable I am to the company” is left over from days when sustainable pace wasn’t a part of the culture.  The truth is that busy does not equal productive.  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.  It is not to ensure that everyone is at least 100% (or more) utilized.  Agile processes are supposed to promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.  When we are running at 100% (or more) of our capacity we cannot maintain that pace indefinitely.  At some point, we burn out mentally, physically, and emotionally.  We cannot afford choose utilization over productivity.  Our primary measure of progress should be working software, not how much more we can get done with fewer people.  The efficiencies in an Agile organization don’t come from piling more work on fewer people.  They come from improving our technical practices, increasing automation, increasing quality, lowering technical debt, collaborating, and learning to continuously improve our processes.  These things give us the ability to produce more without adding employees because we stop tripping over ourselves and can run along a clear path.

I read the following question from a user on

“Does running your servers at 100% CPU usage cause any issues or is it just good CPU utilization?  My servers have 8 physical cores constantly running at near 100% for “open hours”/10 hours per day.  The program is architected to run on 8 threads – and it fully uses them. Performance is good but the infrastructure guys are worrying about the “maxed out servers.”  I think it’s just good use of available resources. What’s the point of having lots of core if they are not all fully utilized?”

The problem with this line of thinking is that when resources are fully utilized they don’t get more done.  Contrarily, less gets done.  They move slower, wait time increases, and so do errors.  Here’s the response someone gave to this question:

“Almost without exception it causes issues, or will cause issues down the road (as demand grows).  100% CPU utilization on a web service server is not good.  If your CPU utilization is at 100% it means that each time the server gets a new request there is a 100% chance that the work will have to wait some amount of time before the server gets started on it.  The typical performance sweet spot is about 70%.  Does that sound low?  If so, remember that 70% utilization doesn’t mean that 30% of the CPU is being wasted.  Instead, it means that 70% of the CPU’s capacity was used over a sample period.  For CPU measurement metrics, a sample period is something like 2 seconds.  During that 2 seconds the breakdown of that 70% is uneven.  In other words, it may be something like 100% for 1 second and 40% in one second.  For short bursts like that, 100% utilization is okay because we know that if a piece of work is delayed it is only for a brief period. (One that won’t make the human waiting upset.)”

I’m wondering, if we adhere to this rule with our hardware resources, why don’t we realize that the same rule applies to our human resources?

I’ve been in the position where I was a scrum master on one team doing an excellent job.  I knew the pulse of my team and they were growing rapidly and performing better than ever.  Then, I was given a second team.  Sure, I had enough down time in my average week to handle facilitating Scrum events for two teams (in theory) but because I was toggling between two team rooms I missed a lot on both. On sprint end/start days I felt very pressured.  I ran from one retro to the next on and often couldn’t compile the improvement plan into a consumable format until two days later.  I fell behind updating information radiators and had less time to think analytically through what was happening with each team.  Over time I saw that both teams were maintaining, even growing some, but the rate of growth was slower than when I had only one team.

Then, something tragic happened.  I was “doing such a great job” that I was asked to take on two more teams for a month to fill a hiring gap.  I felt like a total failure.  I had to choose which teams I was going to work with and leave the others stranded.  I had no clue what was going on in any of the four teams because I wasn’t spending enough time with any of them to catch the important conversations.  My teams all felt abandoned by me and had to pick up the slack felt by my absence.  While in my manager’s eyes nothing fell to the ground because my teams were mature enough to fill in the gaps without me, my teams felt all the pain and none of the benefit.

I learned a very powerful lesson through that experience.  Being utilized at 100% (or more) capacity didn’t make me a super Scrum Master.  It made me a terrible Scrum Master.  On a ledger somewhere it may have looked like the company saved money by utilizing me to full capacity but the impact of the hidden cost was much greater than the financial gain.  We would have done better to allow the third and fourth teams to work without a scrum master for that month.  Instead, we caused four teams to operate without a scrum master by spreading me too thin.

What message do we send as an organization when we tell our teams we expect them to plan their sprints at 125% of their capacity?  It’s a message that says we do not value sustainable pace.  What message do we send when we tell our employees we want them on multiple teams so we can fully utilize their capacity?  It’s a message that says we do not value sustainable pace.  What message do I hear when Scrum Masters tell me proudly that they are working on multiple teams?  I hear that they have forsaken the Agile principle of sustainable pace.  I hear an anti-pattern.  It makes me know that though we have come far we still have more work to do before becoming truly Agile.


The Art of Creating Space for Growth in the Retrospective

At an open space event the other day a group of people were pondering the topic “Getting people to be engaged during meetings.”  Inevitably the conversation turned to retrospectives.  People described how some teams complained about being forced to have retrospectives and how others went without complaint  but didn’t really participate.  Some of the frustrations were that introverts never want to participate and have fun conversations with their teammates.

In short, some scrum masters were describing ways that they have been trying to pull their teams into a place of participating but weren’t being successful.  Teams were feeling forced to do something they didn’t want to do and scrum masters were frustrated because no one wanted to play this very important game with them.

As I stepped back from the conversation I began to realize that what was missing was the understanding that there is an art to being able to facilitate an effective retrospective that starts long before the meeting.  The scrum masters role in the retrospectives isn’t simply to facilitate while people to talk about what went well, what didn’t go well, and what will we do to improve in the next sprint.  It is about creating new awareness.  It isn’t about pulling people into the conversation.  It’s about creating space for them to learn and grow and innovate in order to become higher performing.

This space doesn’t start in the retrospective.  It starts days, even weeks or sprints before the meeting.

As scrum masters, it is our job to cultivate vision.  It starts by stepping back every single day and seeing what the team doesn’t see.  How are they working together?  Do they really know what they are trying to become as a team?  What does high performing look like?  What are their goals as a team?  Where are they struggling and can’t see it for themselves?  What bad habits are they repeating?  What decisions are they making that are out of alignment with the agile values and principles, scrum values, and proven best practices? What’s the elephant in the room that everyone smells but no one will talk about?  What are they doing really well that they don’t even recognize?  What amazed you and made you proud?  Where do you see growth?  Where do you see them falling back?  What do they need to see?  What conflicts need to be resolved?  What isn’t being said?

It is our job to see the big picture over time and not just the little pieces of each sprint.  Planning retrospectives is about strategy, not just tactics.  It isn’t good enough to have a book full of retrospectives and blindly pick one just to mix it up each sprint.  The purpose of changing retrospective methods isn’t so the team doesn’t get bored.  We must pick the right tactic to bring the right result at the right time.  It’s up to us to remember what they said success would look like five sprints ago and bring it back around for them to see if they are getting closer to their goal.

Choosing the right retrospective format includes processing this information and crafting a retrospective that will create space for them to see what they can’t see.  It creates an atmosphere of safety where people feel comfortable with who they are so they can communicate with their team.  This means that we have to understand who they are, how they learn, and how they communicate.

Are they analytical and need more concrete types of questions? Are they visual and need to envision the questions and problems they are trying to solve? Are they auditory and need to talk through things with others to gain perspective and revelation? Do they speak in pictures, tell stories, or have a creative nature where things like props, play dough, and pictures will help them?  Are they introspective and need space to think before speaking?  Do they think through problems while talking?  How do they face conflict?  What motivates them?  Where are their passions?  Are they extroverted and get energized through interaction?  Are they introverted and get worn out through interaction?

These are things that the scrum master has to understand about the people if they want to foster engagement and growth.  Every team is different.  A style of retrospective that works for one group may not work for another.  There is an art to creating space and safety for people to gain new awareness and growth.  Successful retrospectives aren’t measured by how much participation and fun you are able to muster up but in how much actual growth the team gains through the activity.  Taking the time to really see your team and understand what they need to experience in a retrospective is the first step.

Sometimes you just need to laugh …


This is the glass door I ran into on my first morning in a new office.  Five minutes after I arrived.  And I had to laugh at myself!  “Way to go brainiac.  Good thing no one was watching that one.”  Then I giggled.

Messing up, making mistakes, looking stupid in front of others – these are things that often cause people to put up walls around themselves as a means of self preservation.  No one wants other people to look at them and roll their eyes.  No one wants to be “that person.”  Unfortunately, the need to self preserve hinders a team’s ability to be transparent, take risks, and share ideas openly.

As a scrum master or coach we need to be aware of the human nature that says, “protect yourself,” and help develop a culture of safety so team members can learn to trust one another and bring out the best in one another.  Part of the scrum master’s role is to help the team have the best communications possible.  Safe discussions in a team happen when everyone’s ideas are valued and respected.  Great ideas come forth when no single idea has to be the winner.  Instead of allowing people to fight for their position like there is a trophy at stake, teach them how each person can contribute to the ideas of the others and build the best solution for the problem at hand so everyone can win.

Facilitating brainstorming sessions can help a team to foster the ability to throw a bunch of thoughts together and safely come up with the best solution possible.  Help them dream a little using post it notes, index cards, or white boards since all of these are easily disposable.  No ideas are out of bounds.  If you had no constraints how could you solve this problem? Everyone throw out at least 3 ways we could solve this problem – include at least one logical, one risky, and one fun resolution.  This is your timebox – Go!  Once every serious, crazy, risky, and logical thought is on the table the team can review them all and dream and laugh together.

The premise of this method is that no one holds too tightly to any ideas.  Having them throw in multiple resolutions that include the outrageous and risky along with the logical helps them to have contributions that they know we may decide not to use.   What can be really amazing is when an idea that the contributing person thought was dumb or outrageous is just what the team needs to move forward.  Using this process teaches the team to put every option on the table.  Then, sort through those to see what pieces they can put together or add to in order to solve their problem.  The ones that don’t fit into the best solution just get set aside and the best solution wins.

Don’t underestimate the power of laughter.  An individual who can laugh at themselves can learn that they don’t have to prove that they are the smartest person in the room.  A team that can laugh together can dream together safely.    A team that dreams together relies on the collective wisdom of the whole.

Oh … by the way… this … is the second door I ran into … on the afternoon of my first day!


Coaching Teams Tips from the Trenches


Earlier this week I met with a group of coaches of various experience levels from different backgrounds to talk about coaching teams.  We discussed together our successes and failures in attempts to learn from one another.  What follows is a list of the results of what we discovered together.

  1. Create an environment where it is safe for people to fail – In order for teams an individuals to learn and grow they must be able to experience both success and failure.  Most of us learn more from our mistakes and failures than we do from our successes.  When we protect and buffer teams from failure we cripple them.  When we give them all the answers to their problems and provide solutions for them we stunt their growth.  As coaches, we have to step back and  help teams have the courage to make decisions, investigate new ways of doing things, take risks, and explore areas they have feared to enter previously.  They can’t do that if we will not move out of their way and allow them space to succeed and fail.  Failure is a learning experience.  We can’t always just take over when we see them struggling.  We have to give them room to grow.  We have to be confident enough in our ability as coaches to help teams navigate their way back up from failure to success that we have the courage to allow them to experience enough failure to grow and become higher performing.  This doesn’t mean that we should stand by and watch them walk head first off a cliff.  As experts, we should know when to blow the whistle – but use the whistle sparingly only when it is no longer safe to fail.
  2. Believe in people in ways that give them the courage to believe in themselves – As coaches we have to look beyond what we see standing in front of us today.  We have to be able to look at what is in front of us today and see characteristics in people and in teams and roll those things forward weeks, months, and years ahead in our thinking in order to see the great things they have the potential to become.  We can’t think of it as what they might become.  We have to see it as who they are.  Coaches have the power to activate and unlock dormant gifts and talents in people by believing in them in ways that they can’t even believe in themselves.  People don’t need someone to patronize them, they need someone who truly has vision for who they are and can articulate specifically what they see in them and why those things are powerful and amazing.  They need a coach who can point out the simple yet amazing things they do and the impacts that those actions have on the team and on their career so people can have a light shining on the path that shows them what direction to walk.
  3. Use The Language of Appreciation – Speaking to people in an encouraging language that tells them that they are valued and appreciated motivates teams and individuals and makes them want to move forward.  It builds a solid connection and helps to form a trusting relationship with their coach because they see that the coach cares about them and believes in them.  (See the other posts in this blog for more about the Language of Appreciation.)
  4. Ask Powerful Questions – Serving as an expert has a place in coaching when it is time to teach.  Becoming a mentor and walking hand in hand with people also has a place, but true coaching involves taking on a different role of allowing people to enter a place of self discovery.  Asking powerful questions is an art that helps to facilitate this discovery process.  Asking powerful questions can help people move outside the box of their normal thinking.  Questions help them to develop their own conclusions and solve their own problems which means that they actually take ownership of the solutions and plans they make for their future.  When people design their own futures instead of having those plans handed to them they are more likely to succeed at accomplishing the goals they set because they are motivated by their own ideas and empowered to make changes along the way to reach what they define as success.
  5. Treat each team as individual and allow them to have their own culture/don’t create a mirror image of yourself – Every team we coach has a different group of individuals in the makeup and should be encouraged to develop a culture based upon the individuals on the team.  Even if the teams have a similar purpose they should have their own characteristics that are developed from within the team.  I often view the multiple teams I coach like I view my multiple children.  Each of them has their own unique character, strengths, and weaknesses.  Each of them must be coached differently in order to become high performing.  Each team must be assessed individually and the proper techniques must be applied that will help them grow.  Making the mistake that we can duplicate the exact same methods, techniques, and cookie cutter process to every team we coach is harmful.  We cannot expect that every team will look the same or to look like us – in fact, I dare say that if they do this is the sign of an immature coach.  When I enter organizations and see teams that are identical I immediately think about the cargo culting phenomenon where people do things that they see others doing because they think they will get some set of results.  However, since they don’t really understand the underlying reasons why the first person took those actions the repeat of the behavior adds no value.
  6. Don’t get in the middle of conflict – force them to storm instead – Teams need to have constructive and healthy conflict.  Sometimes the conflict turns unhealthy and people don’t want to deal with it properly.  There is a very real temptation to try to solve the problems of the team by getting in the middle and handling it for them.  Bad idea.  As a coach it is our job to teach people healthy ways to resolve conflict so it is better to help individuals form a plan for confronting and dealing with conflict or to create a way to surface the conflict with the team.  In order for teams to become high performing they must first go through the process of forming, storming, and norming.  Unfortunately, too many teams never really storm because they never learn to have healthy conflict.  The elephant stays in the room and everyone just walks around him.  Teaching individuals and teams to address the elephant together using appropriate and safe communication styles, healthy conflict resolution techniques, and problem solving skills serves a better longer term purpose than getting in the middle as a go between to make today more peaceful.


This Shouldn’t Be a Status Meeting … Improving the Daily Scrum


How can I keep the daily scrum from becoming a daily status meeting? But if we are all answering three questions then who is supposed to be asking the questions?  If we are gathering to give our updates on these three questions every day on what we are doing then that sounds like a status meeting to me – what am I doing wrong?

These are all questions that I have heard new scrum masters ask.  The daily scrum seems like it should be the simplest thing we do, right?  The team self organizes daily for a time box of no more than 15 minutes and talks about three things:  What I did yesterday, what I am going to do today, and what is standing in my way.

So, why is it so hard?  In my experience … mindset.  Often, scrum masters learn a process to implement but they don’t recognize the mindset that must change in order for the process to have any value.  Being self organizing and collaborative, like being agile, is a mindset.  It’s not just something you do – it’s something you are.  It’s something you become.  It’s about individuals and interactions over process and tools. What I’m finding is that when teams are struggling with the daily scrum it’s about them putting the process and tools over the individuals and interactions.

When I encounter the struggling scrum masters I find that they have been given a process that they are trying to implement:  Meet for 15 minutes, everyone on the team answer three questions about what they are doing, don’t talk about anything else, break ~ scrum master you are responsible for making sure that the process is followed and that the team understands how scrum works so go make it happen.

But the thing they seem to miss in the equation is that the daily scrum is about the team coming together daily to collaborate and plan how they will work together to deliver the highest priority user stories today or as soon as possible.

Are you struggling in this very thing?

What would happen on your team today if instead of everyone taking a turn answering three questions about what they did on some random user story yesterday and will do today towards the sprint goal, you would all look at the scrum board together and focus on only the top priority one or two stories?  Then, collaborate and discuss what you can do as a team to get those stories completed today or tomorrow?

Tomorrow you can do the same only start by adding to the conversation any progress you made since the last time you met or what stopped you from making the progress you each thought you would make.  Then figure out together what you will do as a team to remove those roadblocks and how you will get the remaining work on the story completed before the next daily scrum.

If one or more of the stories gets finished by tomorrow’s daily scrum celebrate that success and add the next priority story to the conversation.

The advice and method I’ve just described is really nothing new, it’s just putting the individuals and interactions over the process and tools.  It’s all about what we focus on.  When we focus on the questions and the time box and governing the scope of the conversation to make sure we don’t deviate from the questions we lose the collaboration and the true heart of what the daily scrum should be.