An Agile Coach’s Guide to Managing Pride, Ego and Personal Growth

As a ScrumMaster and Agile Coach, one of my favorite tools to use is Mural. Mural is a digital whiteboard designed for engaging collaborations. It’s a creative outlet for me; it’s like scrapbooking for a job. I like to think that I’m pretty good at using the application. If I’m being honest, I think I’m really good at using Mural. I usually get compliments on my creativity, layouts, and functionality of my Mural boards. I pride myself on being knowledgeable and helpful in Mural, which is a part of my Personal Brand.

Recently I was in a Thursday ScrumMaster Community of Practice (CoP) where we were discussing Mural and I shared some of my examples. An Agile Coach said, “Tracy – if you want to help me dress this one up, I’d be happy to see what you can do!”. I felt honored and excited, especially since I had only been consulting at the company for less than 2 months. I had the drive and desire to do my best work and build a positive reputation for myself as an informed, helpful, and creative resource.

That night I reworked his Mural. I created a Lego Theme that focused on Building Foundations Together. I created colored Lego Brick Backgrounds for different topics. I was really excited about what I had made. I shared right away in the morning, expecting to get positive feedback. The instant gratification! However, the Agile Coach was out of the office that Friday.

On Monday, I received his response. “You were using Areas and Shapes inconsistently.”. “Wait, what?!?!”. It wasn’t the reaction I was expecting, and a meeting was scheduled. I didn’t even know what he was talking about with “Areas”. My ego definitely took a hit.

I prepared myself for a meeting with the Agile Coach. I felt like I was a student in detention. I felt like I was in trouble. I expected him to be upset with me because, after all, I ruined the functionality of his Mural.

Instead of a meeting, it was a working session. I learned about functionality I never knew existed. He showed me where, when, and how to use Mural Areas. He was not upset at all in the working session; he knew I had the best intentions.

We learned that even though we’re both passionate and knowledgeable about Agile, it was also easy to see how quickly we fell back on old patterns. We needed to align first with what we were trying to accomplish. We also brainstormed from different personas which created a variety of solutions. Those perspectives made the Mural and instructions more valuable and understandable.

I was humbled by this experience.

I can be, and still am, proud of the work I did.

If I wouldn’t have changed my defensiveness to a Growth Mindset, I wouldn’t have gotten the gift of learning something new.

If I would have gone into the meeting with negativity, I wouldn’t have seen the Coaching Demo that happened right in front of my eyes.

In my reflection, I realized I needed to put my ego aside to grow.

I did that by:

1. Change to a Growth Mindset. Embrace challenges and learn from feedback.
2. Think of every opportunity as a coachable moment. Imagine what your day would look like if you went into every situation thinking, “What am I going to learn here?”. How would the atmosphere and culture change?
3. Give grace. Give grace that everyone was trying to do the best they could at the time – Including yourself.
4. Have Gratitude. Gratitude greatly reduces negativity and anxiety. It shifts a focus from thinking of yourself to others. When we have gratitude, what we appreciate grows.
5. Pay it forward. Paying it forward is the greatest compliment you can give your mentor. Don’t just share the information that you received but pass on the learning environment. Create a space of psychological safety, patience, and understanding.

In conclusion, I still pride myself on being knowledgeable and helpful in Mural. I’m practicing a Growth Mindset and trying to embrace every situation as a coachable moment. Be grateful for being mentored, and in return, become a mentor. But what I really learned in the experience and reflection was:

You can have pride in your career, but to continue your growth journey you need to practice removing the ego.

Another great part of this story is that the mentor/mentee relationship didn’t end at that working session. We continue to collaborate, asking for opinions, and sharing knowledge. We continue to learn together. Now that’s what I call Building Foundations Together.

In December, I wrote a blog about the role of Scrum Master as a Facilitator, see it here. In today’s post I want to go into a bit more detail about the skill needed to be a good Facilitator. Many of you may be thinking that facilitating is easy, you just stand in front of the room and lead meetings. In fact, facilitators aren’t always in front of the audience, and it takes a lot of practice and skills to be a really good facilitator.

So what skills do you need to be a good facilitator?

Be Present – understand how your body language, voice intonation and tempo impact the team.
- Do you have something distracting you? Check it at the door.
- Do you have hot buttons that the team pushes? Address them in your own time, don’t let them be activated in the session.
Have a tool bag of techniques for driving to outcomes.
- How do you get teams to coalesce on a decision?
- How do you identify root causes?
- How do you ensure everyone feels heard?
Address team dysfunctions – understand what is going on for the attendees.
Humans show how they are feeling about the process in many ways, so facilitators need a large tool bag to deal with personalities in the team like:
- The Whisperer
- The Loudmouth
- The Know-it-all
- The Silent One
- The Head Shaker
- The Doubter
Have a good “Wrap Up”
- Ensure action items are assigned
- Ensure decisions are recorded
- Track and follow-up on parking lot items

All of these skills can be learned and practiced to make Scrum Master better facilitators. Use of facilitator skills extends beyond Scrum Events to everything the Scrum Master does.

To develop your skills and learn how to be a good facilitator, check out our ICAgile Team Facilitator certified class being held May 9-10 in Fairfax, VA.

In this class you learn and practice facilitating through a number of interactive exercises that relate to facilitating anywhere as well as to specific Scrum Events.

When I am out providing Agile classes, the topic of what Scrum Masters do all day comes up pretty frequently. Attendees ask questions like; “How many teams can a ScrumMaster be part of?”, and “Do Scrum Masters just run meetings?”. As a veteran of Scrum, I am still surprised at how little organizations understand about the ScrumMaster role. But let’s face it, attending a 2 or 3 day Certified ScrumMaster course provides only an introduction to the Agile Framework, Scrum Events and Roles. Experience and a desire to truly understand what it means to be Agile and how Scrum embraces these principles takes time. It’s an ongoing learning that extends beyond just getting certified.

So let’s start with the basics. The single word most often used to describe the ScrumMaster role is “Facilitator”. Here is the Merriam-Webster’s definition

Definition of Facilitator:

one that facilitates; especially: one that helps to bring about an outcome (as learning, productivity, or communication) by providing indirect or unobtrusive assistance, guidance, or supervision <the workshop’s facilitator kept discussion flowing smoothly>

How does a ScrumMaster facilitate while being “indirect or unobtrusive”? First, you need to understand where your team and organization fit on a scale from just starting their journey to practicing best practices as a highly performing team. I say this because new teams do need a little more “hand holding”, than teams that have been together for a while, and are experienced following Scrum. The ideal goal is to get the teams to work via self-organizing, while motivating them by ensuring they have the right tools and support. ScrumMasters promote the team’s work, not their own work.

The Scrum Guide (see http://www.scrumguides.org/scrum-guide.html) lists three groupings of work for the Scrum Master: 1. Service to the Product Owner 2. Service to the Development Team 3. Service to the Organization. This requires that the ScrumMaster have several skills they can call on at any time depending on where the need is. Nowhere in the Scrum Guide does it say the ScrumMaster is the boss, the secretary, or the project manager of the team.

So, let’s go back to what it means to be a facilitator by looking at a scrum event. ScrumMasters do typically organize getting all the scrum events set up. Ideally scrum events are on a cadence to occur at the same time, and in the same place whenever possible. ScrumMasters facilitate events by ensuring the space is appropriate for the job at hand, all needed supplies are available, and that the appropriate attendees have been invited. The following is an example of how Sprint Planning is facilitated by the ScrumMaster:

Sprint Planning
The goal of Sprint Planning is to identify what can be delivered and how the work will be achieved.

The Scrum Master ensures all stories being presented in Sprint Planning meet the Definition of Ready by working with the Product Owner in advance of the meeting.

The ScrumMaster provides the container for the meeting, and turns it over to the Product Owner to work with the team providing the sprint goal and a conversation to promote a thorough understanding of the stories proposed for the upcoming sprint.

The team moves on to designing how they will do the work and tasking the stories, while the ScrumMaster listens and watches to ensure there is a shared understanding and that the team members have an equal voice. The ScrumMaster can facilitate by ensuring the team stays focused and doesn’t get stuck by asking questions, inviting others with specific technical expertise to join the conversation, and managing the time box of the event.

The final step is when the ScrumMaster calls for the team to commit to delivering the work.

There are many great web articles that list things a Scrum Master does. Here are a couple of good ones:

https://www.mountaingoatsoftware.com/agile/scrum/scrummaster
http://agiletrail.com/2011/11/14/42-tasks-for-a-scrum-masters-job/

Aside from facilitators, ScrumMasters are also the team’s protector, an overall evangelist and enforcer of the Scrum method, and a coach.

Surprised? What does the ScrumMaster do in your organization? Are there improvements that can be made? I welcome your feedback, questions and comments.

“How much scrum would a Scrum Master master,
If a Scrum Master could master scrum?
He would master, he would, as much as he could,
And master as much as a Scrum Master would.
If a Scrum Master could master scrum.” —-Cindy Bloomer

When recently meeting with a client a very interesting question came up: How many teams should a Scrum Master Scrum? They had been hearing that a Scrum Master’s role is just a facilitator role and all the Scrum Master has to do is run the ceremonies, so a person in the role should be able to run 2-3 teams without any issue. Therefore a novice Scrum Master should just be Scrumming one team, an experienced Scrum Master can safely handle up to 2-3 teams and a very experienced Scrum Master can handle more than 3 teams.

In my opinion, the experience of the Scrum Master does not translate well into the number of teams they can handle. Although it is a factor, in all honesty, there are a number of factors that influence the decision, such as organizational maturity, team maturity, project type, the value of the project, and the effectiveness of the Scrum Master role.

Is the Scrum Master just a facilitator? If so, then yes, the Scrum Master can be over 2-3 teams.
Because then the expectations are just to run the ceremonies and make sure teams are running well, are working towards the objectives set in PIs, and are meeting the sprint objectives. And even for this scenario, the team needs to be a mature team. A team that has been together for at least 6-8 months has worked through the forming, norming, storming, and are now in the performing phase and no one on the team is very role specified. They believe that they have to accomplish stuff as a team.

It also depends on the Organization’s Agile Maturity. If the organization has just started the Agile Transformation journey and has yet to establish Scrum Practices, then the Scrum Master should just be dedicated to one team. This is because they will have many impediments to resolve, and they will need to help team members understand and see the value in Agile practices. Helping a newly formed team adopt Agile practices will be a full-time job for the Scrum Master.

With all that said, I believe there are many factors that help determine the “best” number of teams for a Scrum Master to handle; the experience of the Scrum Master is just one of these factors. I have seen many experienced Scrum masters running just one team and declining to work on multiple teams at a time. Although I agree in some organizations Scrum Masters don’t have a choice – the number of teams a Scrum Master handles is a key differentiator in performance, both team performance and Scrum Master Performance.

I want to hear about your thoughts and experiences with the effectiveness and the Scrum Master role when it comes to scrumming multiple teams…

In previous installments in this series, I’ve talked about what Product Owners and development team members can do to ensure iteration closure. By iteration closure, I mean that the system is functioning at the end of each iteration, available for the Product Owner to test and offer feedback. It may not have complete feature sets, but what feature sets are present do function and can be tested on the actual system: no “prototypes”, no “mock-ups”, just actual functioning albeit perhaps limited code. I call this approach fully functional but not necessarily fully featured.

In this installment, I’ll take a look at the Scrum Master or Project Manager and see what they can do to ensure full functionality if not full feature sets at the end of each iteration. I’ll start out by repeating the same caveat I gave at the start of the Product Owner installment: I’m a developer, so this is going to be a developer-focused look at how the Scrum Master can assist. There’s a lot more to being a Scrum Master, and a class goes a long way to giving you full insight into the responsibilities of the role.

My personal experience is that the most important thing you as a Scrum Master can do is to watch and listen. You need to see and experience the dynamics of the team.

At Iteration Planning Meetings (IPMs), are Product Owners being intransigent about priorities or functional decomposition? Are developers resisting incremental functional delivery, wanting to complete technical infrastructure tasks first? These are the two most serious obstacles to iteration closure. Be prepared to intervene and discuss why it’s in everyone’s interest to achieve this iteration closure.

At the daily stand-up meetings, ensure that every team member speaks (that includes you!), and that they only answer the three canonical questions:

What did I do since the last stand-up?
What will I do today?
What is in my way?

Don’t allow long-winded discussions, especially technical “solution” discussions. People will tune out.

You’re listening for:

Someone who always answers (1) and (2) with the same tasks every day and yet says they have no obstacles
Whatever people say in response to (3)

Your task immediately after the stand-up is to speak with team members who have obstacles and find out what you can do to clear the obstacles. Then address any team members who’re always doing the same task every day and find out why they’re stuck. Are they inexperienced and unwilling to ask for help? Are they not committed to the project mission and need to be redeployed?

Guard against an us-versus-them mentality on teams, where the developers see Product Owners or infrastructure teams as “the enemy” or at least an obstacle, and vice versa. These antagonistic relationships come from lack of trust, and lack of trust comes from lack of results. Again, actual working deliverables at the close of each iteration go a long way to building trust. Look for intransigence on either the developer team or with the Product Owner: both should be willing to speak freely and frankly with each other about how much work can be done in an iteration and what constitutes Minimal Value Product for this iteration. It has to be a negotiation; try to facilitate that negotiation.

Know your team as human beings – after all, that is what they are. Learn to empathize with them. How do individuals behave when they’re happy or when they’re frustrated? What does it take to keep Jim motivated? It’s probably not the same things as Bill or Sally. I’ve heard people advocate the use of Meyers-Briggs Personality Tests or similar to gain this understanding. I disagree. People are more complex than 4 or 5 letters or numbers at one moment in time. I may be an introvert today and an extrovert tomorrow, depending on how my job is going. Spend time with people to really know them, and don’t approach people as test subjects or lab rats. Approach them as human beings, the complex, satisfying, irritating, and ultimately rewarding organisms that we actually are.

Occasionally, when I speak at technical or project management meet-ups, an audience member will ask, “I’m a Scrum Manager and I can’t get the Product Owner to attend the IPM; what should I do?” or, “My CIO comes in and tasks my developer team directly without going through the IPM; how do I handle this?” I try to give them hints, but the answer I always give is, “Agile will only expose your problems; it won’t solve them.” In the end, you have to fall back on your leadership and management skills to effect the kind of change that’s necessary. There’s nothing in Scrum or XP or whatever to help you here. Like any other process or tool, just implementing something won’t make the sun come out. You still have to be a leader and a manager – that’s not going away anytime soon.

Before I close, let me point out one thing I haven’t listed as something a Scrum Master ought to be adept at: administration. I see projects where the Scrum Master thinks their primary role is to maintain the backlog, measure velocity, track completion, make sure people are updating their Jira entries, and so on. I’m not saying this isn’t important – it is. It’s very important. But if you’re doing this stuff to the exclusion of the other stuff I talked about up there, you’re kind of missing the point. Those administrative tasks give you data. You need to act on the data, or what’s the point? Velocity is decreasing. OK…what are you and the team going to do about it? That’s the important part of your role.

When we at CC Pace first started doing Agile XP projects back in 2000-2001, we had a role on each project called a Tracker. This person would be part time on the project and would do all the data collection and presentation tasks. I’d like to see this role return on more Agile projects today, because it makes it clear that that’s not the function of the Scrum Master. Your job is to lead the team to a successful delivery, whatever that takes.

So here we are at the end of my series. If there’s one mantra I want you to take away from this entire series, it’s Keep the system fully functional even if not fully featured. Full functionality – the ability of the system to offer its implemented feature set to the Product Owner for feedback – should always come before full features – the completeness of the features and the infrastructure. Of course, you must implement the complete feature set and the full infrastructure – but evolve towards it. Don’t take an approach that requires that the system be complete to be even minimally useful.

If you’re a Product Owner:

Understand the value proposition not just of the entire system, but of each of its components and subsets.
Be prepared to see, use, and test subsets, or subsets of subsets of subsets, of the total feature set. Never say, “Call me only when the system is complete.” I guarantee this: your phone will never ring.

If you’re a developer:

Adopt Agile Engineering techniques such as TDD, CI, CD, and so on. Don’t just go through the motions. Become really proficient in them, and understand how they enable everything else in Agile methodologies.
Use these techniques to embrace change, and understand that good design and good architecture demand encapsulation and abstraction. Keeping the subsystems isolated so that the system is functional even if not complete is not just good for business. It’s good engineering. A car’s engine can (and does) run even before it’s installed into the car. Just don’t expect it to take you to the grocery store.
Be an active team member. Contribute to the success of the mission. Don’t just take orders.

If you’re a Scrum Master:

Watch and listen. Develop your sense of empathy so you “plug in” to the team’s dynamics and understand your team.
Keep the team focused on the mission.
If you want to sweat the details of metrics and data, fine – but your real job is to act on the data, not to collect it. If you aren’t good at those collection details, delegate them to a tracking role.

I hope you’ve enjoyed this series. Feel free to comment and to connect with me and with CC Pace through LinkedIn. Please let me hear how you’ve managed when you were on a supposedly Agile project and realized that the sound of rushing water you heard was the project turning into a waterfall.

Scrum purists will tell you co-located teams are the way to go. If only it was that easy!

As large organizations adopt scrum, they find themselves struggling with how to be more Agile when many of their teams are distributed. As coaches and trainers, it is our responsibility to support this reality.

There are many blogs and articles like this one on the web that talk about working with remote teams.

Many of the articles I see offer common sense tips like:

Make the most of tools for instant messaging, video conferencing, and shared content.
For ceremonies, use video conferencing whenever possible.
Ensure Team Agreements, Definition of Done, and Definition of Ready are in a shared location.
Team Agreements need to include core hours when everyone will be on instant messaging.

Here are some of my own more unique suggestions:

Dealing with time zone differences – Although ceremonies should be at the same time/place whenever possible, consider alternating times by month, or sprint. For example, on odd months favor east coast times, while in even months favor west coast times. Don’t do too small of an increment (like daily).
Time for a celebration – Ensure everyone on the team, regardless of location, goes out and celebrates. Schedule an extra 15 minutes post scrum to discuss what everyone did. Get creative….hold virtual “coffee breaks” or “pot lucks”; celebrate personal events (such as birthdays, births, leaving, etc) as well as team accomplishments.
Tracking Sprint Progress – Utilize your tools’ dashboard during daily scrums to show the teams burn-down. Don’t micro-manage tasks. Insist team members keep tasks up-to-date reducing ETC to keep burn-downs current.
Product Owner – As a Product Owner (PO), engage fully with the team to ensure collaboration leads to comprehensive understanding of each story. Ask questions. Update stories in real-time during team grooming to clarify understanding. It is easy to leave PO acceptance of stories until it is too late for developers to make changes. Instead keep an eye on story progression, review stories as soon as they are ‘done’.
ScrumMaster as team facilitator – As a Scrum Master (SM), your role is especially important with distributed teams. Pay attention to how members interact. Is everyone participating in ceremonies like grooming and planning? Ask questions to draw out quiet members. Also, just because you are the facilitator, doesn’t mean you have to “be in charge”. Don’t forget to turn items like tasking stories over to developers. Just sit back and listen while they do the work. Consider a SM for each location (e.g., if you have part of the team together on the east coast and another part together on the west coast, use a SM in both places).

There’s no doubt about it…..it’s harder for remote teams to achieve the same collaborative environment that co-located teams can. But it’s not impossible….with a little elbow grease and TLC, your distributed team will shine!”