Traversing through Change

Two years ago, I attended Agile West, and my perspective on software development changed entirely. I was bombarded by so much material that is so blatantly obvious to me now. However, at the time it was revolutionary for me. As a tribute to my epiphany, I’d like to talk about the Satir Change Model. This model and a value driven illustration which I’ll discuss another time really sold me on the need for change. The graphic below is used by coaches and trainers to illustrate the treacherous journey; the change can be as simple as introducing Test Driven Development or completely scrapping sequential development. This isn’t earth shattering material, but I want to invite readers to read and reflect where they are on this journey. Allow your minds to picture where you are, where you were, and where you wish you could go. What did it feel like as you were looking over the edge? If things didn’t quite work out, why? What would you recommend to those about to embark on their own journeys?


It takes courage by an organization to implement change, and it takes an immense amount of intestinal fortitude to hold true to that commitment; nothing will test the will of leadership when the inevitable chaos ensues. Despite the many voices in the community yelling that ‘going agile’ is not a silver bullet, companies run straight off the cliff expecting immediate results. These companies are so desperate, they are willing to take the leap of faith without measuring the depth of the chasm. Can we really blame them? In some cases their situation was so poor, it appeared like their only option at the time. Going ‘over the edge’ isn’t something to be taken lightly, and it may not even be the best decision for your team or company. There is no fault in choosing not to make a change.

Then you have the organizations that invested the time upfront to prepare for the descent. They go as far as establishing a community to help scale the change. The community, rather than the individuals, improve the likelihood of the change ‘sticking’. They’ll collect some bumps and bruises on the way down, but they stay the course and arrive at the bottom of the chasm. The scars serve as reminders of why they chose to make the journey.

It takes a lot of hard work and sacrifice to complete the descent, but just because you reach level ground doesn’t mean it’s time to relax. In my opinion this is when the organization is most vulnerable- between the chaos and transforming idea. Organizations are not prepared for this ‘lost’ feeling and immediately start looking for more solutions. Some will turn right back around and ascend the cliff they just painstakingly descended- the rubber band effect. Others will try to redefine their goal and create an entirely new chasm of change; a short term solution with a much higher climb at the end. In successful cases, they manage to trudge onward.

The ascent is truly not for the faint of heart. Here, teams and organizations have experienced their ‘transforming moment’. This is like the first spark when trying to light a fire; you keep attempting to repeat whatever caused it to happen. Sometimes you’re successful, sometimes you’re not. In this phase, the teams and individuals can start to see and feel the change. Beware of bad habits and false ledges; they’ve sent many tumbling on more than one occasion.

Finally, you reach the other side. You’ve completed your journey… you’re agile. Wrong! At this point, you’ve broken even. Remember way back at the beginning when we all agreed, ‘In order for us to produce what we’re producing now, we have to take a dip.’ You’re back on level ground. However, your organization is now equipped with the experiences of this monumental change. You’ve likely had your share of successes and failures; each one serving as a lesson learned to strengthen your resolve. From this point on it’s about consistency and striving to improve- both are easier said than done.

I purposefully made this post brief and very broad. There are many strategies to clear the chasm.With these attempt come many stories of success and failure. We can gain much insight from analyzing the journeys of others. Where are you in your journey? Are you looking over the cliff deciding if this is right for you and your organization? Are you carefully making your way down… slipping every now and then? Are you lost at the bottom of the chasm? Or are you making that final climb?

Get Off the Field, Coach!

   Could you imagine the chaos if football coaches could run onto the field during a game? With that picture in mind, every time a ScrumMaster assumes control of a team, he/she is essentially all over the field of play. Though the boundaries in football are clearly delineated, scrum has no such luxury; if you’re the ScrumMaster, you’re in the daily mix with the team. Being so close to the action has many positive aspects, but it opens the temptation to pick up some bad ones as well. Some, but not all, ScrumMasters come from traditional roles- project, technical, and general managers. As Ken Schwaber states in Agile Project Management with Scrum: “The ScrumMaster is a leader, not a manager.” It is such a simple statement, but it embodies the shift these individuals must make from command and control to servant leadership.

   I like to compare the role of the ScrumMaster with a professional football coach. Like a football coach, the ScrumMaster is constantly driving the team towards continuous improvement, and he/she needs to know how the team will react to certain coaching tactics. Unlike a football coach, the ScrumMaster doesn’t have direct authority over the team; we have to carefully and tactfully find the right opportunities to mentor them. As a member of the team, I always wanted to jump in, help, make decisions, and protect the team from failure. The short term gains earned us small victories, but I unknowingly created a co-dependence that stunted the team’s ability to self organize. In this article we’re going to cover some basic questions and use the coach/team/football metaphor to highlight the connection between ScrumMaster and football coach.

Who runs the daily standup?

   The daily standup is the first point of inspection. In many organizations adopting scrum, the standup becomes a terrible carry-over ‘status meeting’ from waterfall processes. Even with experienced teams, it is usually the first pillar to fall. It is natural for the team to look specifically at someone- the ScrumMaster, tech lead, supervisor, etc.- to answer the basic three questions:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

*The Scrum Guide, Ken Schwaber and Jeff Sutherland, 2014,

   A ScrumMaster facilitates the scrum meeting, but the team does not report to the ScrumMaster. Yes, the purpose of daily standup is to answer the three questions, but the intent is to spark a conversation between the team members about the sprint. Think of the daily standup as the huddle right before a play; the team quickly inspects and adapts their current drive based on what they’ve observed. In this huddle, the team talks to each other about the previous play, necessary adjustments, praise their teammates, or even get on their teammates for poor performance. The coach/ScrumMaster stands on the sidelines watching for any impediments that need their attention that the team has no way of resolving.

tv4-daily-scrum   The objective is to have the team run the meeting and discuss the sprint. When I have caught myself running the daily standup or interjecting during the meeting, I have used a couple techniques to ease the team back to proper practice. In a newly formed scrum team whose members I had worked with for years, I merely stepped all the way to the back of the room and asked them to huddle around our radiator- tv monitor or board with the sprint backlog. As they discussed the sprint, I listened closely for potential impediments that I required my attention.

   Later, I joined a team that had been practicing scrum for several years. On my first day, I walked into the room and was met with quiet stares. They wanted me to lead the meeting by calling out each individual one by one. Of course, this was a bit of a shock for me; rather than rock the boat on the first day, I complied. Just think of how ridiculous it would look if you saw the football coach run onto the field for every huddle; this mental picture motivated me to make some adjustments. As time passed, I started introducing different nuances to the daily scrum that would eliminate the need for a central figure. For example, rather than call out the individual team members, I created an open floor segment. I hoped this would encourage each team member to jump in and discuss the sprint, when they felt read51loQrUFfVL._SX258_BO1,204,203,200_y. As expected, this was met with some resistance and uncomfortable quiet moments. I stuck with Lyssa Adkins’ advice in Coaching Agile Teams:

“The room gets so quiet you can hear crickets in the background. Uncomfortable silence pervades the room. Team members are not even looking at one another. In this moment, your greatest gift to them is showing that you are comfortable with uncomfortable silence. So, just stand or sit there, not doing anything, not demanding anything from them, but staying connected to them. Gaze at them, each one, gently. Give each person the silent invitation to step in and speak. Someone will.”

   Eventually, the team figured out the new format. For those on the team who were resistant, I took the time to do some individual coaching. I asked and listened why they thought this was a bad change. Overwhelmingly, I heard that the meeting was fully structured before, and now it was total chaos. With each concerned team member, I took the time to explain why I wanted to make the change. The standup is for the team, nobody else; they should run it how they see fit. Eventually, I intend to step away as full facilitator and let them run the scrum. Notice the small incremental changes over time. With a newly formed team, you can make swift changes; however, you will often be met with resistance from experienced teams, so be prepared to put on your coaching hat.

Does the team make decisions on its own?

   Think back to the last time the team faced a decision. What was their first reaction? If you are the ScrumMaster, what was your first reaction? Unless the decision had something to do with an impervious impediment, the ScrumMaster plays no part in the decision. Having a technical and project management background, I have to bite my tongue as the team attempts to solve problems I can easily figure out much quicker. Too often, I have watched ScrumMasters jump into the weeds and problem solve for a team. Their intentions are all good; they don’t want to see their team struggle. They’re not aware that they are running onto the field during the middle of a play!

   Let’s tie this scenario back to the football metaphor. Once the team breaks the huddle, they look at the offense/defense and start making adjustments. They have to recognize the change in schemes, variables they didn’t account for, or opportunities that present themselves. A coach cannot hi-res-151683539_crop_northdo all of this for the team from the sidelines. He/she has to trust that they have provided the necessary tools and information to handle this scenario. The goal is to allow a team to grow and learn to make decisions on its own. Peyton Manning, probably one of the best quarterbacks in history, is known for constantly reading his opponents and making constant adjustments. Listen closely to all the action and yelling prior to each play; the offense and defense are reading and reacting on the fly. The same principle applies to scrum teams; the team needs to feel empowered and ready to address problems on its own.

   In my personal experience, teams turn to their managers and leaders for decisions because they are afraid to fail. Legendary coach Bill Walsh famously stated:


   My April article mentioned how many speakers from the TriAgile conference kept referring to failure as an opportunity to learn and grow. Nobody wants to fail; no coach or ScrumMaster wants to see their team fail. Jumping in to save a team has valiant intentions; however, what a ScrumMaster doesn’t realize is that the pattern will continue to repeat itself. The ScrumMaster inadvertently has robbed the team of experiencing that failure and growing from it. I’m not advocating completely being hands off; when faced with failure, the coach and ScrumMaster have an opportunity to mentor their team on the root cause, the decisions made, lessons learned, etc. The hope is to prepare the team when they face the same or similar situation in the future. This is where models like the one developed by Jason Tanner come in handy.

Screen Shot 2015-05-15 at 2.14.33 PM


Am I adapting to the team, or am I forcing the team to adapt to me?

   A software development team, just like the projects it works on, is in constant flux. Teammates arrive to work happy, grumpy, sad, mad, etc. In an ever-changing environment a ScrumMaster can be the steadfast dam that holds back the flowing water, or he/she can be the river bank that pushes and conforms where necessary. A great leader can read his team, understand its strengths and weaknesses, and leverage all of that information to help the team’s performance.

AP931114054--nfl_large_580_1000   The winningest football coach in NFL history, Don Shula, won several titles in the 1970s with a ground and pound offensive attack. He had two running backs in Mercury Morris and Larry Csonka that were an excellent combination of finesse and power. He also had excellent quarterbacks like Bob Griese and Earl Morral; however, everyone knew that Shula was partial to a balanced running attack. In 1983, the Miami Dolphins drafted Dan Marino- the most prolific pure passer of his time. Don Shula could have stuck to his balanced run style offense, but he would have wasted the incredible talent of Marino. Instead, he adjusted his offense to his player; together, the duo of Don Shula and Dan Marino won 116 games together- the most as a quarterback-coach combination until it was finally surpassed in 2011.

   This is where I will place the final tie for the metaphor of scrum and football coach. To be truly successful, we have to adapt to our surroundings. After being the ScrumMaster for a young team and switching to one with years of experience, I learned that the same tactics cannot be used. Each team member reacts differently to different styles of coaching. With some, you can be more direct; with others, you have to take a nurturing approach. Like, Don Shula and other successful coaches, we must realize our team composition and play to its strengths.

Closing Comments

   Every time I feel the old command and control urge taking over, I envision what it would look like if a professional football coach ran onto the field during a game. Picturing how ridiculous that would look on TV makes me chuckle, and it also reminds me that I need to be mindful of the boundaries for my team. The questions and the metaphor help to paint a picture of what we’re doing to our teams when we abandon servant leadership. Ken Schwaber did a fantastic job defining the ScrumMaster role; contrary to popular belief, it is a role that is very difficult to grasp. The ScrumMaster will always struggle with the temptation to to jump into the fray with the team; however, we can make an equal or even greater impact on it from the sidelines.