Is More Really Better?

IMG_3265

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 stackoverflow.com:

“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.

Advertisements

Using Information Radiators to Improve Delivery

IMG_3317

Information radiators (IR) are used to help teams see information transparently so they can make fact based decisions about how they want to change.  But how do you know which information radiators to use with a team?  How do you know how many are needed and what to display?

The best way to use information radiators is in response to something you see or something the team is struggling with but needs a way to really understand what’s happening in order to grow.

In the story below a Scrum Master started using this version of a sprint (points) burn up so her team would have a visual representation of how they were actually working together during sprints as a basis for which to develop improvement experiments.

  • Symptom #1 they were consistently not finishing all of the work in the sprint
  • Symptom #2 they were starting a lot of work at one time in the beginning of the sprint but rushing to get work tested and accepted during the last two days of the sprint
  • Symptom #3 they were carrying over stories and said that it was okay because it gave the testers something to do while the developers were heads down during the first 8 days of the sprint – which indicated that they were actually doing mini-waterfalls.
  • Symptom #4 they were adding stories to the sprint after it started before the original work was complete weren’t finishing the new work brought into the sprint

During the first sprint review they analyzed the burn up and noticed that the green bars that represent points accepted did not show up until the last two days of the sprint.

  • They realized that starting a bunch of stories and working on them separately didn’t make them go any faster because it created a bottleneck in testing at the end of the sprint which left some stories unfinished.
  • They decided to pair up or swarm on work in order to open fewer stories at one time and get them tested and finished earlier in the sprint.

During the next sprint they paired on work and focused on finishing rather than starting work.  At the end of the sprint they analyzed the burn up again and noticed improvement, but not enough.

  • They realized that they were less successful completing larger stories because they took longer to develop which caused them to start testing too late in the sprint to finish.
  • They decided to break stories into smaller more manageable pieces of value so they could finished them quicker.

During the next few sprints they noticed that working with smaller stories helped them close stories faster.  By continuing to pair on stories and limit work in progress they found that they were able to more consistently deliver stories every few days during the sprint.

The team noticed that though they had begun to deliver at a more consistent rate they were still having problems finishing all of the work by the end of the sprint.  They analyzed the burn up in their next retrospective to see if they could gain any new insights.

  • They realized that they were actually finishing the number of points they originally forecast during sprint planning.
  • They recognized that during days 4-6 they finished 10 points of work but they also added 10 points.  They also recognized that every time they finished a story they seemed to add another which was contributing to why they had unfinished work at the end of the sprint.
  • They decided to work on breaking down their tasks better so multiple people could swarm on stories.
  • They also decided that instead of a developer bringing a new story into a sprint when there wasn’t development work on any of the stories the developer would cross over and help the testers with a story they hadn’t developed.
  • Lastly they decided that in the last 2 days of the sprint, if there were no stories they could assist on they would focus on some smaller technical debt clean up tasks rather than bringing in new stories they would not have time to finish.

Over the span of a quarter the team was able to effectively make improvements to their delivery and predictability by using this information radiator to help them visually inspect their work habits.  At the end of the quarter the team felt that acceptable improvements had been made and analyzing the burn up during retrospectives was no longer a value add so they abandoned that practice to focus on other improvement areas during retrospectives.

A Fixer

IMG_0069

While attending the Agile Coaching Institute’s Coaching Agile Teams class a while back the instructors read this poem to the class.  It served as a powerful reminder that as an agile coach, or a scrum master/team coach, we must see people and teams as naturally creative, resourceful, and whole if we want to empower them to grow and move forward.  As a coach I must be a servant to those I coach.  I’m not here to be better than them or to have all the answers.  I’m here to serve them in their quest for greatness.

It’s often a first reaction to want to jump in and fix things and fix people.  It’s so easy to have all the answers.  It’s empowering to play the super hero.  But the real power is in allowing people to identify their own solutions.  The real power is in self restraint and waiting for people to grow and change on their own.  The real power is in stepping back so other people’s greatness can shine forth.

This poem serves as a daily reminder that it is impossible to both be a fixer and a servant to others.

A Fixer*

A fixer has the illusion of being casual.

A server knows he or she is being used

in the service of something greater,

essentially unknown.

We fix something specific.

We serve always the something:

wholeness and the mystery of life.

Fixing and helping are the work of ego.

Serving is the work of the soul.

When you help, you see life as weak.

When you fix, you see life as broken.

When you serve, you see life as whole.

Fixing and helping may cure.

Serving Heals.

When I help, I feel satisfaction.

When I serve, I feel gratitude.

Fixing is a form of judgment.

Serving is a form of connection.

*Author Unknown

Agile Jeopardy Retrospective

2015-12-03_13-22-04

(This post is by guest blogger, Kenny Barnes.)

For our latest retrospective, I created a jeopardy board using JeopardyLabs – Online Jeopardy Template.   I used a mix of Agile related categories (Scrum, Agile), items related to the team [Working Agreements, Sprint (more details below)] and something the team is really passionate about (Star Wars).  It took about an hour and a half to come up with the questions/answers and setup the board.

To play the game, the team drew numbers and broke up into two teams.  The teams then took turns picking a category and amount.  If the team picking didn’t know the answer, the other team had an opportunity to answer and take the points.  We ended with a final jeopardy question related to Star Wars that saw one team answer correctly for the win.

Now you might be asking yourself, well this is cool but how did you come up with an action plan or discuss any team issues?  Well the Sprint category took care of this.  The “answers” in this category had both teams, regardless of who selected it, come up with things that worked well, didn’t work well, wins to celebrate, etc.  Each team had two to three minutes to come up with the answer to these questions.  We then had each team give their answers and we discussed them.  The $400 selection was what do you want to try this next sprint.  We had a great discussion and came up with our action plan.

The team really enjoyed playing the game and the change of pace it offered.  They definitely want to do it again next quarter.

Are Your Stories Ready?

IMG_4197

This week I was particularly impressed with a method used by a Scrum Master to help his team understand which stories on the backlog were “ready” and which were not.  It’s amazing how such a simple technique can bring the transparency needed to help a team prepare for a successful sprint.  His technique is to use colored stickers as markers on the ordered product backlog hanging on the wall next to the team’s scrum board to indicate the state of the story.  If the story is not groomed it gets a red sticker.  When the team begins grooming the story and has made pretty good progress but isn’t all the way in line with the definition of ready yet, he changes the sticker to yellow.  Once the team has completed grooming the story and it meets the definition of ready, it gets a green sticker.  This green sticker is an indication to the team that the story is fully groomed and ready to be pulled into a sprint.

Prior to sprint planning, he works with his product owner to ensure that any stories she has ordered towards the top of the backlog that are potential candidates for the next sprint are in ready state.  If a story is not in ready state the team does not pull it into a sprint regardless of where it is on the product backlog.

This scrum master is inspiring those around him with simple yet profound ideas and ways of creating growth in the team and product owner.

An elephant and a monkey went for a walk last sprint …

IMG_4457

This week I was walking past a conference room where a Scrum Master was preparing for the team’s retrospective.  I had to stop and take a picture because I really loved what I saw.  Here are a few of the things that really impressed me:

  1. The team’s improvement plan from the last retrospective is represented. This helps to solidify the value from the last retrospective’s suggested improvements.  By circling back around and discussing the team’s experience with the past action plan it helps the team to measure to see if the changes actually impacted their ability to become higher performing.  This also helps the team intentionally create ways to ensure that they act upon the plan they create because they re-evaluate how they implemented them and if the changes need to be adopted as part of the working agreement or if they were not valuable enough to continue.
  2. It is creative and fun.  You don’t need to be an artist to draw pictures for a retrospective.  In fact, I’ve found that scrum masters who can’t draw well but do it anyway have the most success!  Being willing to really put yourself out there when you know there’s an obvious lack of talent shows the team that you are willing to bring your full self in order to help them grow.  It helps to foster trust and relationship because you aren’t hiding your weaknesses from them.  The lack of drawing skill usually becomes a fun joke for the whole team as they try to identify what your pictures represent.  (In this retro the big joke was, “What in the world is the monkey doing?”  Answer= He’s pulling the elephant’s tail and frustrating him!)
  3. It uses the coaching skill of metaphor. This picture represents the teams experiences through the last sprint.  It helps the team to look at the sprint from multiple perspectives.  The perspective of positive things like things that specifically are helping us to do well and be better and things we want to celebrate.  It also helps the team get real about what’s frustrating them and what is really holding back their growth and progress in areas.  These perspectives take the team deeper than just what went well and what didn’t.

Agile 2015 Learning and Highlights

Presenting at agile 2015

Sunday, as I got on a flight and headed to Washington, DC for Agile Alliance’s Agile 2015 conference, I was looking forward to spending a week with other like-minded people who believe in living the agile values and principles and who are investing in themselves and in others to grow in their craft. I anticipate this conference all year because I love the full saturation of agile. I love the networking and new ideas. I love the opportunity to see what others in the industry are up to and to learn from them. And I love meeting new people who teach me great things!

Allison Pollard and I were given the opportunity to present a coaching topic called “Change Your Questions ~ Change Your World” this year. It was exciting to see Allison again and partner with her on this great topic and it was an honor to invest in the agile community at large.

Mornings were filled with “Lean Coffee” which is a facilitation game for having discussions about a range of topics with a group of people who self organize for the purpose of learning and communicating. So many coaches, scrum masters, product owners, managers, software engineers, and quality engineers had such great input and valuable perspectives to share. I had a ton of take-away items from the “Lean Coffee” sessions including ideas about new books to read, ways to manage workflow, how to inspire others, how to develop curiosity, and about interviewing techniques.

One particularly interesting thing I am bringing back from the conference is the use of improv with agile teams. I learned multiple improv activities that help agile teams learn valuable lessons and it completely blew my mind! I’m also bringing back a card game called, “The Product Owner Game” that helps product owners learn to balance cost and business value in order to select the most valuable features and user stories to work on each sprint. I attended a session on user story mapping that provided a great exercise I’m going to be able to walk through with product owners and scrum masters to help them learn this technique and bring it back to their teams for quarterly planning improvement.

There were multiple sessions about coaching in the midst of culture transformation and organizational change. One particularly interesting session provided me with a new tool called an empathy map that I can’t wait to use! Sessions about conflict and toxic environments provided exercises to help people discover their own triggers in order to learn how to deal with them in a healthy manner. I learned how to create an influence map that helps you look at an organization in a way that provides insight to areas where coaching can have the largest impact. I learned a new coaching model and attended a session on executive coaching that was fascinating. I learned from master coaches how to sharpen my professional coaching skills specifically for use in an agile environment and I learned more about how to take a coaching approach to mentoring.

In all this was one of the most successful learning weeks I’ve had all year. The return on investment for this conference was incredible just in the things I’m bringing back to the organization to help others grow. There are many ways companies can invest in its people to help them grow in understanding of agile. In my opinion, Agile Alliance’s Agile 201X conferences gives one of the highest rates of return of any conference I attend.