The Main Reason NOT to Read the Scrum Guide

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. scrum guide book2

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.

The Sprint Lego Game Has Arrived!


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.

Accountability Has No Place In Agile

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

The Vendor Principle – Managing the Vendor Element of Scrum Teams

FPI-Management-Multifamily-VendorsTODAY’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 3rd 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 Standard Three Questions of the Daily Scrum Falls Short

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.

Agile Adoption Requires Agile Transformation

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

Use the Cloak of Invisibility to Facilitate

Lego Cloak of Invisbility

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.