I am amazed at how many scrum team members have not read the scrum guide. One would think a team that is going to practice scrum would read this guide extensively. It provides guidance on how to practice scrum so why wouldn’t one read it? Even more amazing is how many haven’t even read the Agile Manifesto. In one respect I thought this was a travesty. It’s like forgoing reading the instructions on how to operate your TV and then getting frustrated because you think a feature isn’t working properly. It is working properly but you must read the instructions first to know what working properly means. After reading some various blogs where people were taking the scrum guide literally, I quickly changed my mind about reading the scrum guide. It was at that moment I realized the main reason people shouldn’t read the scrum guide. 

Let’s talk about that intended purpose of the scrum guide first for a second. Why was the scrum guide developed? What problem were they trying to solve by creating it? Faster delivery? Higher quality? These are definitively outcomes that come with practicing scrum. Yet, scrum is a process framework for planning not delivering products. The result of planning effectively can be faster delivery, higher quality, continuous product delivery, greater team morale, etc. It is this key distinction that is necessary to understand when reading the scrum guide. Which brings me to the main reason not to read the scrum guide. If you have not developed an agile mindset first, then don’t read the scrum guide yet. Without this mindset, you will misinterpret the scrum guide. Your interpretation may be through a traditional planning lens resulting in undesirable behaviors and thinking.

Just recently I was asked to help facilitate an “agile assessment” survey to some scrum teams. On the surface this may seem like a good idea, getting a baseline to see where we are on our agile journey. Even so, this is a prime example of how reading the scrum guide without an agile mindset will cause trouble. One of the survey questions asked about team co-location. One team answered that they were fully co-located. Unlike other teams who had team members in India, New York and Chicago, all their team members were in the same facility; not on the same floor or in the same room or area but the same building. Technically the team was correct however they lost the intent of co-location, which is an opportunity to quickly collaborate amongst team members to discuss issues, approaches and dependencies. Having people in the same building didn’t necessarily foster the intent of co-location; there was little face-to-face conversation within the team. Their literal interpretation of co-location skewed the survey results. On paper it appeared as though the team was very agile; but in reality they were far from it. Without the clear understanding of intent  and a developed agile mindset, misconceptions will emerge painting the wrong picture of a team’s agile journey.

OK, so I imagine a few of you are asking a few different questions right now like, “What do I do if I don’t have an agile mindset? I need to at least understand what scrum is don’t I?” or “How do I develop this mindset before practicing scrum or agile?” All great and fair questions. Here’s what I recommend. Read the scrum guide and partner with someone who has already developed an agile mindset such as a Scrum Master or Agile Coach. Ask them to help you see the scrum guide with the lens of an agile mindset. Discuss your interpretations of the scrum guide with your partner and discuss the differences. To develop an agile mindset on your own, learn about the empirical process. Scrum is built on this concept and it does aid with switching your approach to planning. Ask yourself what’s important, focusing on time or focusing on flow of work? Is it important to write stories in a certain format or that the team understands the who, what and why? I recommend reading Carol Dweck’s book, “Mindset”.  It is through this approach of switching your lens of sight that you will develop an agile mindset. When one develops this agile mindset, practicing Kanban, XP, Scrum, etc. will become much clearer and easier to practice. Once you’ve done these things, then read or re-read the scrum guide.

It’s time to start playing the Sprint Lego Game! This game was designed to aid Scrum Masters and Coaches to build better teams by introducing the various challenges teams faced during the most under discussed sprint event, the Sprint itself! The game will help your teams learn new ways to deliver current and future  value when adversities such as bottlenecks, diminished team capacity or new critical work strikes a sprint. If you have struggled as a coach or scrum master to teach your team  to finish more than they start then this game is for you. Download the Sprint Lego Game Facilitation Guide  and begin having fun and teaching your teams new ways to work together when the sprint seems destined for a downfall.

COUNTLESS times I’ve been asked, “Who’s accountable for the performance of a scrum team?” I take this question in with curiosity. Often, I find the person asking this question is looking to point blame at a single individual for the failure of an outcome they expected to happen. As I dig deeper into this situation, I uncover there is a definite misconception of the application of “accountability” within the agile space. Sure, we want to hold the Product Owner accountable for the success or failure of a product. How many times have we heard that the Product Owner is the single most wring-able neck of the product? Yet how realistic is this to do? How can we truly hold one person accountable for the success or failure of a product that has so many moving parts to it? Many of these parts are largely out of control of the Product Owner. Still we want to hold them singularly accountable and responsible for things they really don’t have complete control over.

Some people apply this “singular accountability” phenomenon upon the Scrum Master too. Many people believe the Scrum Master is responsible for the success or failure of a scrum team. I ask again how can we hold a Scrum Master accountable for something they have no complete control over? Scrum Masters have no control over whether a team or team members want to be coached and guided in the ways of scrum, agility or lean thinking. A Scrum Master cannot force a team to be coached. The team must be willing to be coached. A Scrum Master cannot be held accountable for the success or failure of a team that doesn’t want to be coached. Why? Because the team is being coached to become self-organizing. This means the team answers to itself for the things that are within their sphere of control. Accountability means being able to answer for the things one has power to control. Neither a Product Owner or Scrum Master have complete control over the things they are responsible for therefore they cannot be held accountable for those things.

There is no room for singular accountability in the agile space. I would even go deeper and say we shouldn’t worry about any type of accountability in the agile space at all. Instead, focus should be on waste removal and continuous improvement. When someone asks who is accountable for team success or failure, they are asking the wrong question. The true agile, lean thinking question is, “How can we help our teams perform better?” Or “What’s getting in the way of our team’s performance?” Looking for a single wring-able neck is outdated and really wastes time. If we truly embrace agility and lean thinking, then we think of ourselves as a team working together to create great products and great teams. Accountability shifts from a blame game towards self-reflection, self-awareness and finding the best ways to increase success within the team and the organization. If you need to hold someone accountable for something, hold yourself accountable for creating an agile, lean culture within your organization. Hold others accountable for behavior that doesn’t support agility and lean thinking. In the end, it is our behavior and mindset that truly defines accountability in the agile space.

TODAY’S workforce is highly diverse more than ever. It goes beyond gender or race diversity. Now the diversity of the workforce has a new dynamic to consider regarding contractors. There has always been a compliment of contractors in the work place. Many companies acquire the services of 3^rd party vendors to supply their company with the skill sets they need to compete in the marketplace. However, the tide has shifted a bit. Once companies hired a small number of contractors to augment their staff. Today some companies go as far as to build the majority of their IT team with contractors. In some cases, upwards of 75% of the company’s knowledge assets are in the hands of contractors. When teams are formed with a mixture of contractors from multiple vendors working alongside full time team members (FTE), team dynamics rise to a whole new level of complexity. Compound this situation with team members who are remote and it becomes a spaghetti of issues a team must face.

Having worked with many types of teams, the most challenging have been those that possess a combination of multiple vendors, FTE and remote team members. This blend of diversity surfaces behavior and actions which make supporting agile values and principles highly difficult. For the purposes of this blog, the focus will be on the vendor dynamic and its impact on teams. With many contractors coming from outside of the U.S., deportation and maintaining work visa becomes the primary concern of the contractor. Secondly, being a contractor in and of itself causes many behaviors and thinking that a coach or scrum master must unwind. Proving worth and obtaining FTE status or promoting the vendor becomes the primary focus. These focal points surface toxins such as territorialism, inferiority complex, conservatism and competitiveness.

Territorialism – there is a fear of losing one’s job or responsibilities. A reluctance to share responsibility or knowledge with other team members emerges. Work and knowledge is hoarded to increase individual value rather than team value.

Inferiority complex – a belief develops that suggestions on how to improve a product or process are not welcomed. Ideas from FTE are more valued than ideas from contractors. This stifles creativity, innovative ideas and provokes silence from team members.

Conservatism – a reluctance to take chances, explore or make mistakes emerges. Focus is diverted from delivering value towards following the status quo.

Competitiveness – vendor worth is promoted over team value. Unhealthy conflict materializes within the team as team members from various vendors vie to become THE vendor of choice for the company.

Agile coaches navigate organizational impediments to create a self-organizing team consistently delivering value. The vendor principle creates behaviors that oppose agile values and principles which contests the premise of consistently delivering value. How do we maneuver through this tangled web? First and foremost, by raising awareness. When teams are created, consider the possibility of creating potential undesirable behavior by mixing team members from different vendors together on a team. Make visible the challenges this situation can cause and provide suggestions to avoid this state.

Treatment of contractors is also key. I’ve seen firsthand a FTE telling a vendor they don’t have to listen them and they just need to do what they are told. The more a person feels as though they are part of the company, the more they will speak up, present great ideas and become role models and leaders. When I managed contractors, I went out of my way to make them feel like they were part of the team. I provided them the same luxuries and benefits as the FTEs on my team. In return, the contractors stopped behaving like order takers. Instead they become innovators, leaders and vital assets to the company by contributing and thinking outside the box. Contractor attrition was reduced.

Another point to consider is the vendor’s contract. Contract review is vital to ensure the contract itself doesn’t promote anti-agile behaviors. A common area that supports anti-agile behavior is the vendor’s method of reward and recognition. Development managers should work with vendor managers to align reward systems with agile values and principles. Remove any behaviors or language in the contract that would make contractors less likely to demonstrate the preferred behavior and thinking. Lastly, consider converting contractors to full time employees. Reduce the reliance on contractors and maintain a stable balance of knowledge with FTE. Instead of an 80%/20% split of knowledge in the hands of contractors, make it more even with a 40%/60% ratio. Placing a large amount of a company’s knowledge assets in contractors can be risky and dangerous for the company.

Aside from coaching the organization on the Vendor Principle, we also coach the team members. Getting team members to see beyond the “us” vs. “them” mindset is essential to the team working together as a unified system. Noting the anti-agile behavior, reinforcing the agile values and principles and conducting 1-on-1 coaching in addition to team coaching will help bridge the chasm between vendor to vendor to FTE anti-behaviors. The more teams focus on their similarities and common purpose, the less likely they think are to focus on outside factors that butt against their shared purpose. The vendor principle is real and adds another dimension to the team and organizational dynamic. Working with your teams and the organization to make the vendor element less of a problem will create a more uniform aligned purpose for both the organization and the teams.

The more I work with agile teams one thing that consistently pops up is how teams run their daily scrum and the common practice of asking and answering the “3 standard questions”. I realize the scrum guide “suggests” using “What I did yesterday,” “What will I do today” and “Do I see any impediments” however these questions fall short of helping teams really achieve the intent of what a daily scrum is meant to accomplish. Even tacking on the “…to meet the Sprint Goal” doesn’t quite get the teams where they need to be. The intent of the daily scrum is to inspect and adapt the sprint plan. The Sprint Goal is meant to keep the team focused on delivering value and more importantly delighting customers.

The standard questions don’t foster collaborative conversation to support these intentions and tend to lead to status reporting. As I go through my agile coaching training and learn about powerful questions, I ponder what questions could be asked during the daily scrum that would actually facilitate more collaborative discussions towards inspecting and adapting the sprint plan. In addition, these questions should also get the teams talking more about delivering value and delighting customers. As I posed this question to other scrum master and coaches, some good examples emerged such as:

• “How did you solve customer problem X yesterday?”
• “What will you do on this story today to get closer to delighting our customers?”
• “I have this blocker. How can we remove this barrier I’m experiencing?”
• “What capability in this story did you deliver yesterday?”
• “What capability for this story will you deliver today?”
• “How will we test this capability today?”

Why are these questions better than the standard 3? They require teams to really think about what they are doing and how that relates to the end-user, value and customer satisfaction. They also require teams to think around how they can help one another and where adjustments need to be made in their sprint plan. These questions foster conversation beyond standard answers such as “I’m working on that” or “I’m testing that” or “I’m almost done with that one”.  The Daily Scrum has always been a great challenge for teams especially those that are just starting out or don’t understand the true intent of the Daily Scrum. In reality the point isn’t to get them to answer questions about their work but to talk about how they are going to DO their work together and progress work forward. Questions can help facilitate that however naturally discussing delivering value and delighting customers is really what teams and scrum masters should strive towards. How do you get teams to hold conversations rather than answer questions?

Imagine an entire team that thinks like product owners and knows how to test and build software. What would that be like? When teams think in terms of problems they are solving for their customers and end-users and supporting the overall product vision and strategy, they tend to hold different conversations about what they are doing. They focus more on the outcomes and value rather than outputs and they also understand WHY they are doing it. Challenge your team to think more about building a product rather than delivering software. See where the conversation takes them and how much more productive their conversations become.

ONE of my mentors recently made the comment, “Agile adoption is different than Agile transformation”. This made me really think hard about the implications of this statement. I reflected on how companies incorporate agile practices into their organization. Typically they bring in outside help to train team members on agile methodologies. Often this will be the extent of the learning and teams will go off to “do” agile. Teams will have a ton of questions and no one to guide them. The few elite companies will also bring in team coaches to reinforce the training. Unfortunately, many companies stop here and then wonder why agile isn’t working for them.  In their minds they have “transformed” their teams and the company should be agile now. They’re unaware they’ve only started adopting agile and there’s more needed.

Agile adoption cannot be fully implemented without agile transformation. To achieve true transformation, Enterprise/Transformation coaches must be brought in to move the entire organization into agility thinking. The real reason agile doesn’t work isn’t because the teams don’t understand agile or aren’t doing it right (although this may be true). The main reason is because organizations do not transform other areas outside the agile teams. These areas engage in anti-agile behavior or smells that impede the team’s ability to go from “doing” agile to “being” agile. And as the smells linger, the adoption of agile diminishes.

What are some anti-agile organizational smells that impede agile adoption? Setting deadlines is one. When deadlines are set, teams can’t be creative and ensure they build the right thing well. Technical wealth is diminished as teams take shortcuts to meet the deadline. This results in poor engineering practices, code and infrastructure that must be cleaned up later. Innovation is killed or the deadline is missed. Morale declines too as teams work extra hours to get work done in the timeline.  Teams need to focus on delivering value. The Product Owner can decide the best time to release features to the market. If teams are building small increments of value, the PO can plan what gets shown at those crucial conferences through backlog prioritization.

Projects are another smell. If your company is looking at everything as a project rather than looking to promote products, your agility adoption and transformation will suffer.  There is little room for innovation and improvements when teams focus on a project rather than a product. End-user or customer focus is lost as everyone concentrations on making the project a success rather than the product. With product focus, the Product Owner has the ability to quickly change focus to address whatever market changes may occur. These changes may fall outside the original “project” scope and instead of spending time negotiating to introduce the changes, the Product Owner can swiftly adjust the scope to deliver what’s needed now.

There are other smells such as lack of trust, command and control management, endless status reporting/meetings, missing roles (think no Scrum Masters or DevOps) and  individual evaluation versus team evaluation metrics to name a few. It is these impediments that actually thwart agile adoption and inherently make agile transformation impossible. I’d argue that true agile adoption can’t exist without agile transformation.

As Scrum Masters and Agile Coaches when we are approached about helping with agile adoption, we must stop and ask, “What are you really looking to achieve, agile adoption or agile transformation?” If leaders request adoption, it’s our responsibility to let them know they will never achieve full adoption without transformation. Then we need to validate they’re OK with that. Explaining why adoption won’t work without transformation will set expectations around what they will and won’t achieve. Maybe then, companies will change their approach to agile adoption and include transformation in their decision to become agile.

I recall the first time I saw a “healthy” scrum team. I mistakenly identified the Tech Lead for the Scrum Master. I quickly learned the Scrum Master was back away from the team hardly engaging but intently listening and observing. This was vastly different than what I had previously witnessed with teams. It was at this moment that I thought to myself “How is this facilitation”? I always believed the role of the coach was to be deep within the team leading them to victory! I soon learned the goal of a scrum master is to be present but only heard or active when needed. This brief introduction to healthy facilitation led to my own demonstration of facilitation thru invisibility.

The Product Owner team at my company wanted to determine what team investments they’d like to make to work better in 2017. I facilitated the meeting to help them determine where they felt they had gaps and what they should focus on for the up coming year. They created a list of gaps and ranked them. I found the ranking of one item to be interesting. It didn’t align with the challenges the team constantly talked about yet they ranked it as one of the top 3. I was curious so I asked one simple question as I pointed to the item, “Why this now?” This triggered a long, healthy discussion amongst the team. I sat back quietly, watched and listened.  I didn’t give my opinion nor even engaged in the conversation. I let it flow naturally until they said they were ready to re-vote.

The re-vote revealed the team felt there were other things that would help them improve more than item #3. Consequently, that #3 item got moved down to #7. Even though this wasn’t a scrum ceremony, it supported the concept that an “agile coach facilitates by creating a container for the team to fill up”. In this instance, the container was filled up by asking the simple question of “Why this now”. The room filled with varying viewpoints, debates, deep thought, questioning and a revised list the team felt a lot better about in the end. After the meeting, a team member approached me and said he really liked the question I asked. He said it was simple yet the perfect question to pose. “It forced us to really think and not just run off and focus on some ‘new shiny thing’”. He said if I hadn’t asked that one question, the team would have focused on the wrong things.

Just being present, observing what’s happening and interjecting at the right moment then stepping back is actually good facilitation. When a coach becomes invisible in the room and allows the team to run thru a ceremony or meeting by themselves with good results, you know you have a team that has a good level of self-sustainability or self management. If your teams are new and just forming, being up front and leading  the ceremonies from the front of the room may be necessary. Also, be mindful of conversation that doesn’t lead to results. It may be necessary to interject multiple times to get the team back on track from wayward conversation. As you and the team mature, become Harry Potter and use your cloak of invisibility to guide your team to a deeper level of agility.

IMAGINE walking into a company where teams have been engaged in Scrum or Kanban for a few years. After careful observation you discover teams are practicing the mechanics of these frameworks but are still struggling to embrace the spirit and intent of them. If teams or organizations aren’t practicing the values or principles of an agility framework then they have one foot stuck in a waterfall world. I use to wonder why so many places seem to implement agile frameworks yet still work in a waterfall manner. Even though scrum is relatively simple and can be explained in about 10 minutes, it still seems to be very elusive. It wasn’t long before I realized the reason why companies struggle so much with agile.

Bottom line, without a growth mindset, agile won’t work. It’s critical to its success. I would argue it’s the #1 reason why agility transformations fail in organizations. Teams AND Leadership must possess this mindset. If not, the company is misaligned and agility falls flat. A growth mindset is the most difficult thing to acquire if you don’t inherently possess it. It can’t be easily taught and not everyone is equipped to teach it. It takes hard work and lots of practice to develop. If you have a fixed mindset you probably think you can’t acquire a growth one. Well it IS possible. I had a very fixed mindset at one time and I was able to shift to a growth mindset. I was a negative “it can’t be done because…” type of person. I always saw how things would fail. I’m far from that now. I’m completely the opposite. In fact one of my recent direct reports once called me “disgustingly positive”. How did I change? Well, let me share my transformation journey with you.

My first managerial position is where my journey began. I was offered a position to manage a team of business analysts which eventually expanded to include tech writers and user experience designers. I was very excited about taking on the role. I immediately ran out and acquired any information that could help me make the leap to becoming a manager. I read books, took a company online course, consulted with others who had made the switch and talked with seasoned managers for advice. When I went into the position I felt I was ready for it. Shortly into the role however things went astray.  A former BA myself, I worked with the developers my team was now engaging. I felt since I had a long relationship with the developers, I knew what my team needed to do to be successful with them. I would specifically tell my team what actions to take and how. I reviewed their work and gave them feedback which was mostly negative and filled with promoting my solutions. I never even gave a simple “Nice job” to them. I totally believed I was helping them succeed. I was removing the obstacles I believed they had and giving them the tools they needed to succeed in our environment. Then one day out of the blue my boss called me into his office. He told me he met with my team and had feedback to share.

Thinking I was going to get raving reviews, you can imagine how devastated I was to learn my team hated my managerial style. They even called me a micro-manager which made me shutter as that was something I never wanted to become. As my boss gave me the feedback, I made excuses and became defensive. I explained how I was helping them and my communication style though blunt and direct was honest. He continued to provide more feedback but I had stopped listening at that point as I was fueled with anger. My hearing perked up though when he finally said things were changing and I may not have a team to manage if I didn’t turn things around. My heart sunk. What was I going to do? Fortunately for me, I had a friend who was just starting a coaching practice. She offered to coach me through this. She first coached me on empathy and emotional intelligence. She was able to get me to understand that words invoke emotions and I need to be more conscious of “what” I said over “how” I said it. She recommended I read the book “Crucial Conversations” to help with my conversation style. It was a hard road – an analytical mind learning about feelings?

The first time we role played, I got very frustrated. Every time I used a word, she explained the negative emotions it could ignite. In less than 5 minutes I ran out of words to use. I became so frustrated I wanted to quit. She never gave up on me though. Despite my frequent “quits”, I stuck with it. I felt awkward and uncomfortable. My communication became disjointed and unpolished. I had a lot of missteps and mistakes. I kept practicing. Slowly I began to think about things in a more positive way and my conversations improved. I took the “opposite” approach to ask questions and to use more positive words. When negativity rose in my mind or conversation, I tried to think of one thing that was positive and I focused on that. When someone said something couldn’t be done, I asked “What would we need to get it done?” I started to listen closely to words and tone of voice and noticed facial expressions. This led to realizing when empathy was needed. When the urge to explicitly direct my team on what to do surfaced, I repeatedly told myself “My way only works for me, help them find their way. Leave your ego behind”.

Within 3 months, I turned it around. My team reported to my boss things were tremendously better and I was providing the support they needed rather than the support I wanted them to have. My boss said he didn’t know of anyone who could have turned things around so quickly. My command and control, fixed mindset was starting to vanish. Yet my journey was only beginning. I still had a ways to go. I often slipped back to fixed mindset and my blunt communication was still present in certain situations. I had more to learn about conquering negativity and growth mindset. So I decided to embark on a learning quest to study more about positive thinking. I read many books (which I recommend below) to continue my mindset transition. I practiced techniques with family and friends. I learned to let go of my ego more and focused more on others and their needs. I created a list of “messages” to tell myself when I slipped back into fixed mindset. I planted the seed in my brain, “I’m just a companion on someone else’s journey; enjoy the ride and help when I can”. I visualized what others with a growth mindset would do.

My journey to growth mindset was by far the most difficult thing I have ever done in my life. Despite the pain, anxiety, and frustration I went through…it was worth it. I’m not “cured” by any stretch. I still fall into fixed mindset on occasion. But now I have the tools to quickly emerge from it. I know how to manage it before it does any damage. Growth mindset is the foundation for servant leadership. I needed to acquire this mindset to become a good leader, scrum master and coach. Hopefully by now you can see why mindset is so important and also why it takes a backseat in training sessions. If you don’t have the growth mindset know that it can be achieved. Here are some tips and recommended reading that may help you find yours.

Tips:

1. Get some coaching – My mindset would not have changed if I didn’t get some career coaching. Changing your mindset is hard and requires outside help and support.
2. Be patient – It will take time and you will fail, feel awkward, be stretched way out of your comfort zone and feel like quitting multiple times. Don’t quit! You can get through it.
3. Acquire a support system – Look to others to help you. Practice with family and friends. Tell them what you’re doing and why. Ask for feedback about how you made them feel and where you may have dipped into the negativity pool.
4. Continue to learn – Read or listen to as many books, articles videos as you can. Explore what creating a mindset means and how to keep it. Find people who already have the growth mindset. Watch them. Learn what they do and how they handle situations.
5. Develop a toolkit – Create messages, phrases, rituals, etc. that will help you when you enter into a fixed mindset. Repeat them over and over again until it becomes a habit for you to use them.
6. Find the positive – Even when something seems so bad, if you try hard enough you can find a small little bit of positivity. Focus on it and use it to keep the conversation and yourself above the line.
7. Change your lens – Look at things from all different angles or the opposite of how you normally looked at them. Try to find ways you can grow in a situation rather than ways you can’t improve. Take action on your discoveries to facilitate your growth.

---

Recommended Readings/Videos:

“Crucial Conversations” by Kerry Patterson

“Miracles are Guaranteed” by Bill Ferguson

“Mindset” by Carol Dweck

“Drive” by Danial Pink

“The 5 Levels of Leadership” by John C. Maxwell

“What Got You Here Won’t Keep You There” by Marshall Goldsmith

“Emotional Intelligence 2.0” by Travis Bradberry

“Above the Line Thinking” by The Consciousness Leadership Group

I recently took on a new scrum team. For the first couple of weeks I observed all of their scrum events sitting quietly in the back of the room. I wanted to see where the team was with their agility journey and what places may need some firming up. What immediately jumped out to me was how they were practicing their daily scrum. The scrum master I was replacing called on each person to talk. The team proceeded to tell what they did yesterday, what story they were going to work on today and ended with “No blockers”. They all talked to the scrum master instead of each other. The scrum master wrote down notes and asked questions about their statuses and delays.

After the daily scrum, all I could tell was that 4 or 5 stories would be worked on and that yesterday 4 or 5 stories were worked on. I had no clue if someone could help anyone else or if there were going to be any conflicts with the work they were doing. The team felt because everyone was working on their own separate thing, there was no need to share more details about what they completed or would work on. The team failed to see the value in discussing more because no one else would be able to help with their work due to lack of product knowledge.

I contemplated this situation and wondered how I could get them to see the value in providing more information about what they are working on to each other. I decided to create a couple of videos about construction workers working on a house to demonstrate how even when people are doing separate, discrete work it’s important to share a bit of the details so they can plan with each other. In my videos, there is a carpenter, an electrician and plumber working together to build a house. Each is only capable of doing work within their trade and there isn’t much overlap between each profession. In the first video the construction workers conduct a daily scrum like a status meeting. The second video shows how it might go if they used the daily scrum to actually plan the day’s work.

After showing the videos to the team, we had a lively discussion about the differences between the two. They started to see how they could actually learn from one another and get help when help wasn’t obvious. Of course there were still some skeptics, even so the possibilities of more collaboration was in motion. My first change was to stop calling on people to speak. This violated self-organization and empowerment. They decided who would speak next instead of being called upon by me. The next change I implemented was for them to “pretend” I was on vacation so they would have to conduct the daily scrum without me. I stood in the back of the room and let them take the lead. It took a bit for them to decide who was going to show the scrum board for the remote people and who would get the conference line going. Once that was decided, this simple change immediately showed results. There was more conversation than ever in the room. Ideas of how to help others with their work flowed and developers participated more by asking some poignant questions that gave some good insight.

I learned that it doesn’t take big changes to shift thinking. Small little things can make an enormous shift for a team. In this case, I met the team where they were, determined what a step ahead would look like and then jumped into action with small, minor adjustments. Sometimes it’s better to think small in order to make large changes. While some are still giving a status update rather than focusing on planning, others are shifting how they talk in the daily scrum. It’s a process and we’ve made progress towards improving our agility journey.