The Sprint Lego Game Has Arrived!

20180712_141918

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.

My Path to a Growth Mindset & 7 Tips to Help You Acquire Yours

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