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

No matter what kind of work we do, we look for feedback from our customers, our co-workers and our peers. Why do we do that? To improve and to get better at what we do.  The same thing applies to Agile teams and programs, no matter what methodology the team is following: Scrum, Kanban, XP, SAFe, LeSS, or DAD.

A good retrospective is the key to helping teams improve what they are doing. It helps them identify and streamline processes which can create efficiencies and get them to that next level of maturity.  Hard to believe, but this is the event which is most commonly ignored or taken lightly. Teams often feel they are too busy and do not have time to retrospect.  This makes the team get into a ‘Plan and Do – Plan and Do’, vicious cycle. They never stop to reflect and adjust and then they complain Agile doesn’t work.

An Agile Methodology isn’t magic and it doesn’t solve all problems by itself.  It makes the problems transparent, clear and appear sooner in a project’s lifecycle. But to identify the problems and to find out what can be done differently to improve the processes, the teams need to retrospect.

So why don’t the teams do retrospectives?  Here are some of the reasons they give:

• Don’t have time just to talk, it’s a waste of time
• Retrospectives are boring
• No one takes any actions from the retrospectives so why bother
• Same monotonous technique
• Unplanned meeting
• High performing team already, nothing more to improve on
• No participation

So how do you make retrospectives interesting, add value to the team and make them a place where the team members can express their opinions without any repercussions?

First of all, the retrospectives should follow the “Vegas Rule” – what happens in Retrospectives stays amongst the team members.  All of the information is shared in this container of trust and all team members and facilitators should respect the container.  Information or data in the retrospectives is collected with the sole purpose of making the team better and improving processes.  The information should not be used as performance management feedback.

Secondly, and most importantly, it is not intended to be a finger pointing session or to point out the skill or knowledge gaps in any individual team member. Retrospectives should always be respectful and be conducted professionally by a skilled facilitator (usually a Scrum Master).

Thirdly, the retrospectives should be done by selecting interesting activities that engage all team members.  The activities should be relevant to what is happening in the team. They should let the entire team collect data, learn the insights and decide on what actions they can take together to improve.

Fourthly, the retrospectives should be made exciting! The teams which asks the same dreaded questions – what did we do well, what did we not do so well or any suggestions for improvements at the end of every sprint really gets boring and monotonous, not only for the team but for anyone facilitating the retrospective as well.

Create an environment of trust, honesty and make room for some creative retrospective ideas.  It should be planned in advance so the team feels like it is a treat being part of a retrospective after the hard work in the sprint. It should allow the team to think about innovative ways in which they can adjust and make themselves and the processes better. The book by Ester Derby on making retrospectives great is an excellent resource and so is the website Tastycupcakes.org for activity ideas.

Next, what about the findings and action items from the retrospectives? Many tools like Version One have a section wherein the output of  retrospectives can be created, stored and referenced in next retrospective. The best thing is to prioritize the resulting action items, assign them owners and place the list both in the online tool for distributed team members and on the physical board as an Information Radiator. Do a check-in on the retrospective action items and see if they are completed.  Items can be added to the team’s backlog and be accepted by the team’s PO.

Just collecting feedback and forgetting about the retrospectives is what makes most people discouraged from holding retrospectives.  When people feel that no action is taken and nothing changes, they wonder why they should keep on wasting time with this retrospective exercise.

Participation from all team members is key.  Especially if you have some very quiet team members and others who have a lot of ideas and take over the meeting. Good facilitation skills come-in handy to address this concern. If the facilitator knows that some team members are reticent to jump in and be part of the conversation, they can ask direct questions to engage those team members so that everyone is heard and valued.

Lastly, no team is so high performing that they cannot retrospect or find anything else to improve.  They might have found other mechanisms of inspecting what they are doing and how to adjust, such that they do not wait until the end of the sprint for this formal retrospective session.  But they are still doing a retrospective, even if it’s all the time.

If I told my 6-year-old daughter, Gracie, to get out a piece of paper and a pencil, she would likely get out a pencil and a piece of paper.  But if I made the same request of my officemate, Ron, he would likely look at me funny and ask me why.  Of course, if I made the same request of my 14-year-old daughter, she would completely ignore me but that’s another story.

So why the difference in reactions from Ron and Gracie?  It really boils down to how we learn.  As children, we learn by being fed information.  During our early academic career, we take what teachers tell us as gospel.  However, as we get older, we begin to question authority, as if it’s a sort of rite of passage to adulthood.  I can hear those of you with teenagers, passionately shaking your heads.  What I am trying to say is that adult learners need to be involved in the learning process. As adults, we need to understand why we are in this learning experience and how it’s going to make our lives better.

Um, CC Pace is an Agile coaching and training company, why are you talking about learning stuff? 

Well, I am glad that you’re paying attention.  Aside from the fact that CC Pace recently hired me to focus entirely on creating effective learning programs and I gotta do something to show them that I actually know stuff, how we learn stuff is part of how we create lean, mean, efficient machines…er, organizations.  Just because you consider yourself an Agile environment doesn’t mean that you actually are!  Waving the magic wand does not make a company Agile, although it’s kinda fun to suggest it to the senior leadership team to see if they bite.   Agile needs to be embraced at the top AND at the bottom.  Getting buy-in from the folks in the trenches means that the training needs to be created with them, very clearly, in mind.

Think of the last time you had to go to training because management said so, or because of a requirement for some regulation.  What did you learn?  Did you pick up lots of good stuff?  Would you wish it on your worst enemy?  Learning experiences that fulfill a check box are often set up for failure because we forget to explain how this information will ultimately help the learner.  If we just chalk it up to a requirement or some mandate, then we have missed an opportunity to help reinforce the content.

It’s critical that a successful learning program understand that key difference; that adult learners need to be engaged with the process, rather than as just a passive participant.

So how do we get the learners engaged?  Well, hopefully, you can see where I am going with this.  If we start by successfully demonstrating how this information will connect back to the participant, then we stand a much better chance of helping the learner retain the information.  Otherwise, participants are left pondering all of the other ways that they could be wasting time while still on the clock. But if the participant sees why the training will impact them, then they will submit to the learning process.

And as Johnnie Cochran once so famously said, “If the training reason is legit, then you must submit!” Ok, so Johnny never said that, but I bet he would have if he read this post.  Ok, that might be a bit of a stretch, too.  But it’s a nice way to remind ourselves of the importance of setting up a training for success. Keep this in mind when you are planning Agile training for a team within your organization.  Thanks for sticking with me this long, how about we pick this up next time with some more ideas on building engagement in your learning program?

Have you heard that not all Agile Transformations are successful? Have you wondered what makes some transformations more successful than others? Are you wondering if your organization can be successful?

Here is a little analogy to think about. I recently lost 40 pounds on an eating transformation plan, or more simply a diet. I don’t like to call it a diet, because if I ever go back to my old way of eating I’ll likely gain my weight back. Also if I don’t follow the basic guidelines of the diet, I may not lose weight at all.  So what does this have to do with being successful at Agile?

When organizations pick and choose what principles to follow in Agile, it’s like low carb dieters choosing to still eat potatoes, or white bread on their diet. While they may see some improvements, overall they are not setting themselves up for success on this plan. The diet gets blamed rather than how the dieter chose to implement the diet.

When preparing for a transformation, the first step is to get the foundational pieces right. Learn about the plan. Prepare your house by cleaning out your cupboards and fridge, and shop for the good stuff to replace the bad stuff. Learn what the rules of your plan are, and set a date to begin. Note, a new eating plan works better if everyone in the house is on the same plan! Then measure the results, and make corrections as needed.

In an Agile transformation, the steps are much the same. Identify what method you want to follow within the Agile framework. Get everyone onboard by helping them learn about the methodology. Prepare your “house” by looking at the organizational structure and identifying what will work within the transformation and what won’t. Make a decision to replace the practices that don’t fit in the transformation with practices that will support a successful transformation. Inspect and Adapt to keep improving and making course corrections along the way.

So what if your organization doesn’t want to follow the plan to the letter? It’s OKAY… BUT the organization needs to know the impact of alterations in the plan. If I can’t give up my potatoes what does that mean? Will I see the same success rate? How can I compensate for keeping my potatoes?

Some Agile principles are more easily adapted than others. I can counteract teams not being co-located for “face-to-face” interactions, by providing great tools for them. I can bring those team members together for planning sessions, or other occasions to help build the team rapport, and offset the lack of co-location. Other principles aren’t so easily adapted. A poor company culture where trust and empowerment are lacking, may prove to be too much to overcome, leaving the organization with unmotivated and un-empowered teams.

If your transformation has hit a plateau, or doesn’t seem to be working. It may be time to take a look at how you are following the new plan, and where your potato-eating cheats are causing you bloat, and derailing your success. It may not be the method, but rather how you are following it.

In my personal experience working on various software development projects, the concept of team energy often appears to be either undervalued or benignly ignored by management teams. The reasons are many. First of all, the term may be confused with “team velocity” which is a relative measurement of a team’s average output or productivity. If the velocity appears to be at either predictable or positive levels, the management team may choose to believe that team energy is also at satisfactory levels. Organizations may attempt to boost employee morale by putting together team-building exercises and outing events. This macro approach may result in generating a perceived positive effect on team energy, thus obscuring the need for focus on individual teams.  So, what is team energy and why should managers consider devoting some attention to it?

When thinking in terms of team energy, one can look at it as building credit with each individual team. One can also look at it from an analogy of having a rainy day fund. From a management’s standpoint it is important to keep team energy in the positive territory. This helps ensure that the team will likely empower themselves to exceed expectations, as well as step up during times of crisis or high pressure situations. I have worked in high energy teams, in which members voluntarily pushed themselves past regular working hours to produce deliverables. These cases did not involve any direct increase in compensation or promotion. People naturally wanted to succeed because they possessed enough energy to do so. I have also witnessed the opposite, where a team’s energy was low, deliverables were in a perpetual state of tardiness and the backlog was steadily accruing bugs. Developers and testers did not feel empowered to succeed and entered a cycle of doing the absolute bare minimum to “get the management off their back”.

Science behind building teams 
Agile methodologies, whether Scrum or Kanban, prescribe various techniques that are focused on continuous improvement that may positively affect team energy. Regardless of whether an organization has truly embraced Agile, it is difficult to find managers that would oppose efforts in improving a team’s processes of delivering faster and at a higher value. After all, who is against a boost in productivity? There is a hidden psychological component to continuous improvement that has a causal effect on team energy. This component is more associated with the experience of individual team members.

Studies of team dynamics such as ones conducted by MIT’s Human Dynamics Laboratory, and documented in Harvard Business Review suggest that there is a science to building high performing and high energy teams. One of the keys is to focus on the human brain and social dynamics of a group. Your teams may be composed of introverts as well as extroverts and a wide range of personalities, but there is a common factor that seems to persist. The studies show that humans feel good when they achieve their goals and overcome obstacles. A human brain actually rewards its owner with extra levels of dopamine when a goal is achieved. When the team feels good more often than not, the team energy goes up. When the opposite occurs, team energy goes down. Therefore, focusing on small achievable goals not only helps the organization to shift focus of deliverables, but it also fosters this psychological benefit of achievement for each individual team member.

Measurements 
An organization may choose to periodically measure team energy. One way to achieve such measurement is through anonymous surveys. Usually this is done at a more enterprise level to gauge the overall organization energy. There is certainly value in doing that, but the effort is not focused and may not necessarily apply to teams. Small teams may not produce very accurate results. There may be disincentives to be frank when answering a survey because team members may feel singled out and fear reprisals from management. In addition, more introverted team members may choose not to “rock the boat”.  A more effective and team-focused approach is to have an Agile coach periodically take team energy measurements. An opportune time may be during team retrospectives, when a team is usually more receptive to be candid.  Most importantly, these measurements do not need to be secretly stored in a manager’s vault but should be shared with the team. Adding transparency to the team building and management process will not only increase team energy, but also foster leadership skills among the more proactive and extraverted team members.

As Agile Coaches, we help teams grow and mature. But there’s no how-to manual that tells us how to do that.  So how do we accomplish it?

Today I’ll talk about a model I find useful when working with teams. The “Johari Window” model was developed by Joseph Luft and Harry Ingham in the 1950’s from their work with groups.  “Johari” comes from a mash-up of “Joe” and “Harry.

What is it?
The Johari Window is a simple model, a tool that can help build trust and improve interpersonal relationships within a group by increasing self-awareness and mutual understanding, and improving communications.

Johari’s Window has 4 quadrants:

OPEN
The public self or open persona.

This quadrant represents what you know about yourself that others also know about you (includes behavior, knowledge, skills, attitudes, strengths, weaknesses, etc).  This is the self we share with others.

BLIND
The blind self or naïve persona.

The blind area represents what is known by others, but you are unaware or don’t know about.  We can’t access the positive things in this area because we don’t know about them, and negative aspects that we don’t know about make us vulnerable.

HIDDEN
The private self or secret persona.

This quadrant presents what you know about yourself, but keep hidden from others.  These are the things that make us uncomfortable or that we’re not confident in.

UNKNOWN
The undiscovered self or mysterious persona.

The unknown area represents what is unknown by you and unknown by others.  This dark area is where our deepest fears and buried talents reside.

The model is based on two fundamental concepts:

• Trust and growth can result from being open
• Awareness and self-development can result from asking for feedback

 How is it used?
Johari’s Window can be used from an individual, team, work group, or project perspective.  The ultimate goal is to increase the “open” quadrant….expanding the public self, and reducing the hidden, blind, and unknown areas.

Opening this window is accomplished by:

• Telling others about yourself…..willingly sharing your thoughts and intentions. The more people know about us – how we think, what’s important to us, how we make decisions – the more cooperatively, collaboratively, and effectively we work together.  The sharing here refers to things that are appropriate for the environment, e.g., sharing intimate details isn’t appropriate at work, and would not have a positive effect on relationships in this setting.
• Asking others for honest feedback….on how they experience you and what impact your behavior etc has on them. Be open to receiving feedback, as it’s a way for us to learn what others see but we don’t, highlighting opportunities for growth.

It’s important to acknowledge here that the word feedback has a negative connotation in American culture.  That’s because feedback is usually couched as “friendly advice” about what we’re doing wrong, or delivered in a context of judgement and intimidation, e.g., “you’re wrong/broken, and you need to fix this or else”.  So we fear it.

But feedback is really about the person giving it, not about the person receiving it.  Most of us have good intentions; we do what we think is right, for the right reasons, and are unaware that others might receive it differently than we intended.  Feedback isn’t about us being wrong or broken, but rather a way for others to tell us our impact on them.  It is a gift….ours to do with what we want.

• Introspecting regularly….regularly looking inside, honestly assessing what we want, how we behave, what we have to offer, what we need to develop, and increasing our self-awareness.
• Challenging ourselves….take more risks, expand boundaries, solve bigger problems, work with different people, or execute on a bigger stage. This will tap into and reveal our deepest fears and help us discover unknown strengths.

So what do I do next?
Whether you’re using the Johari Window model for as an individual or for a team, the key is the more developed the “open” area is, the more comfortable, happy, successful, and collaborative we’re likely to be.

Stay tuned for my next installment where I’ll talk about crafting a team retrospective using concepts around the Johari Window.

Send me your comments…..I’d love to hear your questions, experiences, and ideas for helping teams grow.

You’re driving along on a four-lane freeway.  For a football field’s length in front of you, there are no cars.  And behind you, a similar distance is free of traffic.  It’s like you’re all alone – I know, I know, for some of you that seems an impossibility, but go with me here.

It’s about 10 o’clock on a bright, sunny Monday morning and you’re headed up the east coast for a business meeting a few hours away.  There are big fluffy clouds in the sky, you’ve got the sun roof open, your music is blaring, and you’re singing along – not well, but nobody can hear or see you, so who cares?

The speed limit is 70 mph, and you’re in the third lane from the right going between 72 and 74, making sure not to go over that magic 5 mph “speed-safe” window.  You’re alert to the situation around you, not rushing to overtake the cars in front of you, yet staying ahead of those behind you.  You’re relaxed, and content with the progress you’re making.  You check the rearview mirror, and suddenly.…

BOOM!

There’s a car in the lane behind you.  Barreling down on you.  Going 15, 20, maybe even 25 miles faster than you are.

What’s your first reaction?

DANGER!! Don’t Move!
My first reaction is….danger, stay alert, don’t move.

I watch what the car’s doing.  It’s approaching so fast, there’s no way for either of us to safely recover if we both make a move in the same direction.

So I maintain my speed, stay my course, and watch to see what happens.

The car comes right up behind me, so close I can’t see the head lights in my rearview mirror.  And sits right on my tail.

O.K., buddy
Really?

With all this space to go around me, you’re going to sit right on my tail!?!

And what’s with the wiggling back and forth, is that a signal for me to do something?  Maybe a sign that you’re a madman?

What do you expect me to do, move over?

Why should I?  After all, you had, and still have, plenty of room to safely get around me.  It’s not like I’m going slow, it’s just not fast enough for you.  Well, I’m not gonna move over.

But maybe I’ll slow down juuust-a-bit.

A Common Response
My reaction above is considered “passive-aggressive”.  A passive aggressive response is a way of indirectly retaliating or resisting demands made by others.  It’s a subtle way of expressing irritation, anger, or resentment, when we can’t communicate directly with others or don’t know how to express those feelings.

Passive-aggressive behavior is expressed in many ways including pouting, sulking, forgetfulness, stubbornness, procrastination, not providing input, the “silent treatment”, resisting or evading requests, creating confusion, purposeful inefficiency, and passive obstruction.

Any of these sound familiar?  They’re are common responses, ones we all exhibit from time to time because they’re easier than confrontation, and require less skill than more positive, assertive ways of expressing ourselves.

While passive-aggressive responses are not the healthiest type of response, as long as it’s not the only way we behave, it can be helpful in the short term especially if there’s a need for acceptance, fear of conflict, dependency, power inequity, or perceived threat.

Consider This
In every organization, there are people who are content where they are, satisfied with the progress they’re making.  They look up one day to check the rearview mirror, and suddenly.…

BOOM!

The change car is right behind them.  Barreling down on them.  Going 2, 3, maybe even 5 times faster than they are.  Urging them to move faster or move to the side.  And you’re driving it.

What’s their reaction?

DANGER!! Don’t Move!
Voila!  There you have it, resistance to change…behavior “that serves to maintain the status quo in the face of pressure to alter it”.[1]

Do you have stories about resistance to change?

Please share…I’d love to hear them!

[1] Zaltman, G., & Duncan, R. (1977). Strategies for planned change. New York: Wiley Interscience

Last month I had the opportunity to attend my first ever Coaches Retreat. The retreat was made up of about 80 participants. Preparation for the retreat started months in advance, even for us participants. First we were requested to send in an introduction poster. Second, we were asked to suggest topics for the retreats. As I had never been to a retreat like this before, I didn’t exactly know what to expect. So I thought I’d share my experience of the event.

One of the first things we did after the retreat got going was to form teams around topics. There were plenty to choose from, after all the customers (us attendees) had sent them in. We “self-organized” in teams around topics we were passionate about. I became part of a team organized around the topic of Virtual Teams. Next we set off to plan for three 180 minute sprints. Our team was awesome. We picked a team name; stormed a little, formed a little… We created a vision, a backlog, and committed to sprint 1. Of course we did all the ceremonies for each sprint. Each team’s sprint review was in front of the entire group which provided an opportunity for feedback from customers!

Three days of working with peers from near and far led to each team providing a “product” related to their selected topic in 180 minutes. Wow, what an experience! What a result!

My experience of the retreat was not only a learning experience, but a growing experience. I experienced true team self-organization, and boy was it cool. Within my team, I learned that utilizing Scrum Values (Focus, Courage, Openness, Commitment, and Respect) are as important as the Principles and Manifesto. As our team went through storming to norming, we demonstrated these values. We talked about the work ahead of us, and how we were feeling. Yes, feeling! Our volunteer Scrum Master wasn’t sure she was in the right role; I wasn’t sure I was with the right team. I felt that our team more than any other practiced what we preach as ScrumMasters, Coaches and Trainers. I credit each one of us with following Scrum Values to get through storming quickly. In seeing everything the other teams delivered I gained a set of tools I can utilize anytime. I grew in my sense of belonging to the Agile community, and pushed through my fear and lack of control by exhibiting Scrum Values, and being engaged with my team. The retreat was an opportunity for me to continue a journey of learning and growing, all while making new friends.

Here’s to Team Dysfunction!

In a previous blog I shared how unfinished tasks tend to constantly interrupt our thoughts, create anxiety and affect our productivity. Research has proven that in human endeavors, once expectations have been set, our brains seek a conclusion. If that conclusion is not forthcoming, the brain “stays open” to receive it. Zeigarnik effects result from our mind’s tendency to seek conclusion: when leaving tasks unfinished to focus on something else, we experience anxiety and intrusive thoughts about the uncompleted tasks. Since multi-tasking is simply diverting our attention from one task to another (basically making the new task an interruption), our brain won’t allow us to fully focus on the new task because we have left the previous one uncompleted.

Kanban core practices not only help alleviate these effects, they can spin the Zeigarnik effect on its head and use it to our advantage. Here are several ways how this works:

• One of the Kanban practices is to “Limit Work In Progress (WIP)” based on available capacity to complete the work. This practice supports our brain’s natural inclination to seek closure by finishing what we started.
• Another core practice is to “Manage Flow”, meaning that we want to reach the optimum cycle times possible for everything we do. Besides a definition of “Done” teams define a definition of “Ready” that helps prevent starting on work they could not complete due to missing information or unavailability of subject matter experts (SMEs) along a value stream.
• In the event that information or people are not available, the affected work item is blocked visually indicating that work cannot continue until the blocker is removed. The physical act of blocking a work item cancels Zeigarnik effect by providing the closure our brains seek.
• Author and psychologist Perry W Buffington described the Zeigarnik effect by stating that people tend to remember negative experiences and feelings longer than positive ones. In our world this means that we hear more often from our stakeholders about what we haven’t done for them and less about what we delivered. Drawing upon this phenomenon, in our Kanban consulting practice we coach delivery teams how to consistently review with customers how delivered work is always completed at the expense of other work not being done. This leads to better prioritization, less escalations and minimizes interruptions.  This approach is part of two other Kanban practices: “Develop Feedback Loops” and “Improve Collaboratively, Evolve Experimentally”.

Do you have a lot of unfinished business like a multitude of projects, tasks, and priorities that constantly change, requiring you to stop working on something and start working on something new or on something that was already on hold? Is the unfinished business (The Zeigarnik Effect) hunting you? Do you know how to forecast the capacity you or your team has and how to improve it?

High performance or high productivity require staying focused and avoiding multi-tasking or disruptions. Kanban practices can help you and they are easy to adopt alongside any other processes you already have in place. Our Certified Kanban Foundations Course will help you get started. Let us know what questions you have.

_____________

References

Zeigarnik, B.V. (1927). Über das Behalten von erledigten und unerledigten Handlungen (The Retention of Completed and Uncompleted Activities), Psychologische Forschung, 9, 1-85

Perry W. Buffington, Cheap Psychological Tricks (Atlanta, Georgia: Peachtree Publishers Ltd., 1996), pages 93-95.

Each year, the notable Scrum Alliance hosts a Scrum Gathering in an energetic city somewhere in the US.  This year, 2015, the Scrum Gathering was held in Phoenix, AZ at the Talking Stick Resort.  During the 3-day conference at the beginning of May, there were many speakers who took the stage in an effort to share knowledge and experience with those of us who attended the conference.

The week started off with a keynote by Mike Cohn.  The basic theme of his keynote was “#ICouldBeWrong”.  During his “Let Go of Knowing: How Holding onto Views May be Holding You Back” presentation, he spoke of how we as Agilists have long thought certain things were either good practice, part of Scrum, or a belief we have held onto for some time.  He talked about how we may have some beliefs which we consider to be known to us as definitive things that are without question.  We also have other beliefs that are just that—beliefs, or things we have heard, seen or thought and hold onto.  We, as Agilists, need to be open-minded enough to realize there is a difference between these two types of beliefs and that some of the things we believe, even those of the ‘known type’, can be questioned and possibly even refuted.  Mike Cohn used an example where, for a long time, he believed that a team needed to be defined and fixed then, after working with a few teams that weren’t, he managed to change his belief to one that said that teams can be more dynamic and change periodically.  The main thing I took away from this session was that some of the things I think I’m doing that are ‘right’ could actually be the ‘wrong’ thing to do; I need to look at each situation with an open mind and made decisions or recommendations based on those situations.

After the opening keynote, I moved on to the session for which I was the speaker: “Everybody Out of the Pool – Agile Teams and Dedication”.  In this session, which was attended by a number of people, I talked about moving from the concept that project teams are built out of resource pools to the Agile mentality that everyone is a person and they all bring something different to the team.

The remaining portion of Monday was spent in various sessions of 45 or 90 mins each.  My most notable on Monday was a session on coaching conversations.  This was a workshop that was led by Martin Alaimo that centered on the Coaching Canvas.  This workshop gave me great insight into better ways to help clients understand themselves by asking the right questions to learn more about their: 1) goals, 2) impediments, 3) facilitators, 4) action plan.  By using the ‘coaching questions’, from the question bank on the site, you are able to better understand exactly what the needs and wants of your client are and how to help them achieve the goals.

Tuesday morning started out with a series of PechaKucha presentations.  There were 10 in all, with a wide range of topics.  I enjoyed this very much as it was just enough to keep my attention; there was not too much detail.  A couple of the notable topics for me were “Getting Your Team from Good to Great”, “People over Process”, and “So You Want to be a Scrum Trainer”.  Each of these presentations caused me to learn things I didn’t know before, or helped to strengthen my understanding of the topic.  One of the presentations that hit the trainer nerve was the “So You Want to be a Scrum Trainer”.  It really pointed out that we are not just ‘lecturers’ but those of us that do Scrum training must really understand our audience and what they need; but more importantly, we need to understand what they bring to the conversation.

Tuesday afternoon was much like Monday in that it consisted of various sessions of 45 or 90 mins each.  The most notable for me on Tuesday was a session led by Bob Galen where we discussed things that were said by coaches, either those in the room or others, that were anything but encouraging to teams.  After hearing how some coaches may say things like “You do it because I said so and I’m the coach” or “I’m the coach, so you know I’m right”, it got me to thinking about the things I say.  While I would never say these types of things, it provided insight for me to think twice about things I would say before saying them and also to help others from making the same kind of mistakes.

The last thing on Tuesday was a session of Ignite Talks.  Beginning on Monday morning, anyone with any particular topic they wish to present posted those topics and the attendees of the conference voted for the topics they wanted to learn more about.  The Ignite Talks on Tuesday consisted of 10 topics for 10 mins each of those selected by attendees.  There were a number of topics that ranged from Kanban to keeping teams engaged.  While there was no one topic that stood out for me, all of these topics were fun to listen to and contained great information.

On Wednesday morning, while most of the attendees were in Open Space, I attended a workshop on becoming a CST (Certified Scrum Trainer).  The workshop was facilitated by 3 members of the CST TAC (Trainer Approval Committee) that are responsible for interviewing candidates for the CST designation.  During the workshop, those of us in attendance were informed about how the process works, what was expected of us, and were given a chance to ask questions of the TAC members.  During this session, many questions were answered from various attendees.  At the end of the workshop, I walked away with a better understanding of the process and how it would apply to me.

During Wednesday afternoon, there was a closing keynote by Jim McCarthy where he discussed the value of freedom in our “software culture” and how we have obligations to push movements forward so that we can design our culture to meet the needs of the many.

Overall, the Scrum Gathering Phoenix 2015 was a great opportunity to catch up with some old contacts and meet some new ones.  I managed to learn a lot and gain insight into myself and my beliefs as an Agilist.

Looking forward to the next Scrum Gathering!!!

In January, I moved from Texas to North Carolina.  When I was in Texas, I flew to client sites around the country. But the last few months I’ve been spending more time at clients on the east coast, and have been driving more often.

Now, my brain considers flying an opportunity to catch up on sleep.  Driving on the other hand, is an opportunity to tiptoe-through-the-tulips, or anyplace else it seems.  No map, no rhyme, no particular reason, even…..just random thoughts, reflections, conversions, explorations, and discoveries.

And if the day is sunny and bright, the traffic light, the scenery beautiful, and the music inspiring, I’m filled with the same freshness, optimism and excitement I felt as a kid on a road-trip.  Yet at the same time, quieter, easier, more comfortable being with myself.  I thought I’d periodically share a few of my observations from these road-trips.  Not because they’re brilliant, or deeply philosophical, or earth shattering or anything, but because sometimes random thoughts are all I have.

Last week as I was driving back from NOVA (Northern Virginia), this song by Lee Brice came on the radio.  I was singing along (not well, mind you), and it occurred to me (randomly, of course)….if the conversation took an Agile view, what would it say?  So, I took a shot:

Today, outta the blue

Driving along, singing with the tunes

I heard him say, “What would you do,

If you’d never met me.”

I laughed, and said, “I don’t know,

I could make a couple of guesses, though.”

I breathed deep, my thoughts ran free

I said, “Well, Agile, let me see,

I’d do a lot more estimatin’,

I’d probably spend more time project plannin’,

Play the same ol’ schedule game

If I’d have never known your name

I’d still be doing that ol’ waterfall,

I probably never would have heard the call

Of a different way.

Now, I’m just a simple man

Unaware, yet pretty astute

And, I’d be looking for an option like you.”

I could tell that got his attention,

And I said, “Hey, did I also mention,

I wouldn’t trade one single day

For a hundred years the other way.”

Agile smiled and raised his brow,

‘Cause of course, he’s heard it all

I said, “Come on Agile, don’t you see,

If I hadn’t been so lucky, I’d be

Managin’ meetings for team members,

Reportin’ status to senior leaders,

Stockin’ up on ibuprofen,

Plannin’ stage gates every so often.

There’d be a project schedule in the hall,

And not one index card on the wall,

I’d keep candy in my desk drawer,

But I’d be in an office on a different floor.

And honestly, I don’t know what I’d do,

If I’d never met an answer like you.”

Well, that’s my version….how would your version go?

I get this question a lot. And I ask back “What business problems are you trying to solve?” Each method has great potential when applied within the right context. If you are already using one of them, it doesn’t mean that you can’t use practices from the other. You should adopt any practice that enhances your current toolset for solving business challenges.

Here is a good article that takes a pragmatic approach on how each one of the methods can be used based on what is best for your customers: What is Best, Scrum or Kanban? – http://www.agileconnection.com/article/what-best-scrum-or-kanban

CC Pace provides a variety of Agile services, and we can help you build your toolset as your business needs change. This blog site is a great forum to ask methodology related questions. What do you want to learn more about?

I spend a lot of my time coaching individuals, teams, and organizations interested in reaching higher levels of performance through the use of Agile methodologies like Scrum, Kanban and SAFe. Some clients expect me to tell them what to do step by step, while others are interested in learning how methods work so they can determine what practices to use as their circumstances evolve. The approach that leadership teams prefer usually reflects the problems they are trying to solve, as well as their domain of expertise, their size, their culture and their organizational purpose (for-profit, non-profit, government, etc).

In conversations with leadership teams, we discuss patterns and practices they could help institute or amplify in order to sustain their Agile transformation journey.  Our message, reinforced by all success stories in the industry in the last 15 years is clear: The success of an Agile transformation, regardless of the practices adopted, is directly proportional to how well people in leadership roles at all levels understand, exercise, and constantly improve their Agile mindset.

Leading with an Agile mindset means letting go of the traditional notion of leadership as strategy and control from the top according to a pre-determined plan of action. In times of rapid change when high levels of complexity and uncertainty are the order of the day, leaders can no longer assume they can know or control what goes on. Individuals at all levels must adapt constantly to changing conditions using their best capabilities and judgments in the moment.

In these circumstances, the role of leadership in Agile organizations is to shape the understanding, development, and learning of team members so they can act both independently and in concert with the goals of the whole organization. Leaders need to become coaches, coaching across the organization as well as individuals:

• Individual Coaching: You institute a style of leadership that is participative, servant, transparent, and unleashes the intrinsic motivation of a workforce that seeks mastery in their respective skills
• Organizational Coaching: You focus on understanding and managing the organization as a whole, optimizing the interdependence of teams and departments in order to minimize waste and maximize effectiveness

In practice, we observed that effective leaders in Agile organizations are also effective coaches. I constantly meet people who have a natural coaching mindset and they don’t even think of what they do as coaching. Here are three definitions and models of coaching that have emerged in recent years:

• Coaching is a process that enables learning and development to occur and thus performance to improve. To be a successful Coach requires knowledge and understanding of process as well as of the variety of styles, skills, and techniques that are appropriate to the context in which the coaching takes place.– Eric Parsloe, The Manager as Coach and Mentor
• Coaching is unlocking a person’s potential to maximize their own performance. It is helping them to learn rather than teaching them. – John Whitmore, Coaching for Performance
• Coaching is an interactive process through which managers and supervisors aim to solve performance problems or develop employee capabilities. The process relies on collaboration. – Richard Luecke, Coaching and Mentoring

Leaders in Agile organizations understand that coaching creates a learning environment where individual and collective challenges are the first priorities. Coaching skills enhance their management tool-set in a way that benefits themselves, their staff (those who are coached), and their organizations.

Trust – The Foundation of a Coaching Relationship

Trust has been defined by some as the ability to be vulnerable (Schooman, Mayer, and Davis, 2007). Implicit in this definition is the assumption that when you trust someone, you’re willing to be open, less guarded about your weaknesses and more candid about your opinions and ideas.

In his 1993 dissertation, A Construct of Trust,  Dr. Duane C. Tway, Jr. defines trust as “the state of readiness for unguarded interaction with someone or something.”

And in Rhetoric, Aristotle, 384-322 BC), suggests that Ethos, the Trust of a speaker by the listener, is based on the listener’s perception of three characteristics of the speaker: competence (correctness of opinions), character (reliability – a competence factor, and honesty – a measure of intentions), and the goodwill of the speaker (favorable intentions towards the listener).

When a manager uses a supervisory approach, the relationship between the manager and their subordinates is based on expertise. Boundaries are strictly maintained. Trust, while relevant, is not a key component. The relationship is embedded in the hierarchy of the organization.

When managers coach, the relationship between them and their subordinates is based on both expertise and on abundance of trust. Subordinates trust their managers to do the right thing for them, for themselves, and for the organization.

Samuel B. Bacharach, director of Cornell University’s Institute for Workplace Studies conducted extensive research and wrote over twenty books on management, organizational behavior, and industrial relations. His research indicates that organizations that do not embrace a coaching culture perpetuate a static culture of inertia, bureaucracy, and control. In contrast, coaching is a characteristic of organizational cultures that value innovation, creative thinking, problem solving, growth, and change.

Bacharach points out that “a coaching relationship requires that the protégé (the person being coached) views the coach as someone who possesses the expertise of a good supervisor, but who is simultaneously as trustworthy as a good friend. This combination of expertise and trustworthiness composes the personal integrity of the coach. The more your protégés believe in your personal integrity, the more committed they will be to you, and the greater the likelihood of your success as a coach.”

In another study, C. Ken Weidner, an assistant professor at the Center for Organization Development at Loyola University Chicago, found that trust in the supervisor is associated with better individual performance.

You don’t need to be a trained professional coach in order to include coaching in your set of Agile leadership skills. You have to be able to tell your employees “I know how to do it,” or, “I’ve been there and done that,” without giving them the impression that you think you know it all. To establish or amplify trust, Bacharach recommends you let your protégés know that:

• Confidentiality is the golden rule
• You have their interests in mind when making decisions in the workplace
• They have the ability to speak freely to you
• You are open to learning new things and some of those things can be learned from them

Trust is the foundation for coaching relationships. It is also the foundation for what you want your organization to become.

The Supervisory and Coaching Mindsets

Both coaching and supervisory relationships exist within the hierarchical dynamics of an organization, yet they are fundamentally different.  A coaching relationship temporarily suspends the hierarchical structure, and is a partnership based on the candid, free-flowing transition of ideas and information between coaches and their protégés, which serves to support, reinforce, and motivate both.

Coaching holds that employees potentially possess the best answers to the problems they are faced with, and that the coaching process helps them discover the sources of those answers within themselves.

Leading involves both supervising and coaching. As a proactive manager or leader, you perform each of these two different roles, and each is characterized by its own mindset. Moving between these roles requires a subtle mind shift. Here are several examples:

Let’s look at several examples of how a supervisory mindset or a coaching mindset can influence the way we communicate with others:

• “I suggest you complete your work in the order that you receive it.” – The supervisor focuses on coordinating work rather than facilitating it.
• “Since our last scheduled meeting, you’ve been doing a good job. Keep up the good work.” – This statement is an evaluation of job performance and is characteristic of a supervisory mindset. There is no suggestion of a plan to develop skills together or of a partnership, both hallmarks of the coach-employee relationship.
• “I understand the tight deadlines, the constant pressure from customers to provide the best service, and the intense competition that are all a part of your job. How do you think we can continue to improve the organization and ourselves given these conditions?” – This is a coaching statement. The speaker is empathetic and shows expertise regarding the current situation. The speaker indicates an interest in partnering with the direct report.
• “Working closely with you is very helpful, because not only do you improve on your abilities, but working with you also enables me to isolate those areas that seem problematic in general for employees in your position.”  – The sense of partnership communicated here indicates a coaching relationship.
• “I appreciate your coming to me for assistance. It takes a lot for people to recognize their limitations and to know when they need to seek advice from others. In my experience, there are a few different ways we can approach solving this problem, so let’s work together to think of a feasible, realistic, and desirable solution.” – The sense of partnership communicated here indicates a coaching relationship.

Next Steps

Mindsets like Agile Leadership and Coaching are critical to the success of an Agile transition in your organization.  It takes practice to be good at them, and that means you have to go out there and do it. If, in the process of coaching, questions or challenges come to mind, we’d be delighted to hear from you.

If you read this far, you probably enjoyed this article and I hope it stimulated ideas you can start using at work.   I greatly appreciate your curiosity, and hope you stay in touch! Let me know if we should expand on this topic or if there are other topics that you would like to read about.

In a prior post, Getting Ready for Your Technical Transformation, I defined technical transformation and why it is so important.  Now, I’d like to dive a bit deeper into some tips on going about it…

To begin to transform your technical ‘world’, you need to first make sure your organization’s environments are aligned. As a start, the technical experts in your organization should decide what environments are necessary to deliver the value to the customers; sometimes it could mean as few as 3-4, and sometimes 10-12 may be more like it.  The idea here is to build only the environments which are required and leave the others behind; the more environments your organization has, the more attention and costs that will need to be given to them.  When you have more environments, you vastly increase your costs in areas such as physical hardware, bandwidth, cloud storage, software platforms, which also calls for an increase in cost to administer and configure these environments.  It is wise to plan out the environments carefully!

From what I have seen, and know from my experience as a developer, organizations can usually get by with 4-7 environments, such as “Development”, “Testing”, “User Acceptance Testing”, “Staging”, and “Production”.  A couple of these may be combined or broken out in some organizations, depending on who is doing the acceptance, if there is training to be done, or if there is any beta-type testing needed, but remember that the more you have, the more work they require!

The point is to have the environments, regardless of how many you have, be aligned with the delivery, meaning “Development” would be used for team member to write code, write test scripts, etc., while “Testing” would be used to run stable code, execute test scripts, etc., with a constant set of data to check for bugs, “Staging” would be used to smoke test everything before it is put into “Production”, and so on.

Once the environments are established, the next question is what to do with them and how to move the product through them to “Production”.  There are numerous ways to do this, and the ‘go-to’ way is by manually copying the product between them or even rebuilding the product in each environment.  However, by doing these manual processes, the move is prone to errors—anytime you insert manual, people-driven processes, you introduce error.

In order to eliminate as much error as possible, it makes sense to have machines do the moving.  This process is referred to as “Continuous Delivery”.  You can make this happen by utilizing tools that are out there to help with this very thing.  Some of them you may want to explore are: Jenkins, TFS, Ant, Gradle, Bamboo, or Puppet.  While these are a start, there are many, many others tools to choose from.  The selected tools will depend on your preference, i.e. if you are a person comfortable with scripting/coding or someone who feels better about checking boxes and clicking buttons.

These tools will help you move the product through the environments to “Production”, but they will also help you with another key aspect of transformation:  continuous delivery of each product increment.  To complete an Agile transformation, including the technical ‘stuff’, you really need to be able to deliver continuously to each environment.

Any organization that feels it has truly become Agile will hold to the true nature of Agile:  iterative and incremental delivery.  If this is the case, then it stands to reason that you need to be able to continuously deliver product, pretty much on demand.

If you get stuck and are not sure what to do, you can always call upon a Technical Agile Coach—they can help you align your environments, choose the right tools, and even get you delivering continuously!

In a previous blog, “The Reality of T.E.A.M”, I talked about Agile teams being dedicated, or part of a ‘permanent’ team that focuses on a single solution and remains together over time.  Another big factor of an Agile team is that they are cross-functional in nature.

What is a Cross Functional Team?    
When the topic of cross-functional teams comes up, there seems to be varying opinions that come out.  What does it mean when I refer to teams being cross-functional?  Does everyone on the team have to be able to do every job?  Do all team members have to know every detail of everything that goes on inside the team?  Does the team have to ensure that they can complete their solution?  Let’s look at what cross-functional means for Agile teams that I work with.

If you want to define it, you will most likely find that it means something like “a group of people with different functional specialties or multidisciplinary skills, responsible for carrying out all phases of a program or project from start to finish.”[1]  If you stick with this definition, you may find that you do not have to have a team where everyone on the team knows how to do every job on a team, but more that it is meant to keep members focused more on their role in moving the product forward than on their title.

Now that you’re on a Cross Functional Team
When the members of a team hear they are to be cross-functional, I’ve seen them get a little uneasy thinking they have to become something they may not want to be or learn to do things they don’t want to do.  I call this their ‘mini identity crisis’ because these team members are so centered around their title defining what they are supposed to do, they lose sight of what it means to be a team.

Team members will hopefully come to understand that becoming part of a cross-functional team means they will be focusing more on their role as a team member than on what their title is on their HR file.  Being a cross-functional team member is about ensuring you chip in whenever necessary and do as much as you can to ensure the solution is complete, and as good and valuable as it can be.

It’s not necessarily important that all team members know how to do everything, but it is important they work together, embracing common Agile principles from the Agile Manifesto and Principles, as well as principles that are found in Agile methods, such as “’Collective Code Ownership’ in Extreme Programming, which ensures the entire team owns the code and ‘Self-Organization’ in Scrum, where the team organizes themselves to get the job done.

Where does an Agile Coach fit in?
When coaching cross functional teams, I try to support and help them understand they won’t be losing their identity, but they are going to become part of a larger solution.  I emphasize that they’re not ‘against each other’, or ‘apart from each other’, but ‘for each other’.  I’ve found it’s important for team members to communicate and collaborate so they feel like part of a team instead of a pool of resources thrown together and asked to feel and behave like a team.

For all you sports fans—A Sports Analogy
Cross-functional teams remind me of football teams.  In football, there are multiple positions, both on the offense and on the defense.  While each member of a football team is most likely drafted onto the team to play a specific position, such as protecting the quarterback, the skills they possess for that position may also translate to other positions on the team.  For example, the player that protects the quarterback can use those same skills to get around the protection of the other team’s quarterback and sack him.  Just like a football team has players who are able to move to different positions in order to win the game, Agile teams use the same idea to produce the best possible solution!