Are You a Credible Agile Leader? Not if you Enable Excuses.

An ongoing blog series about Agile and Leadership

“Whoa! I don’t enable excuses” you may be thinking. “I don’t even accept them” may be your follow up thought. You’ve heard the old saying ‘you reap what you sow’. The organizational structure currently in place is the root cause of the behavior and the results you are experiencing.

Let’s explore one of the more popular examples of this. As a leader you may lack the ability to Focus, one of the Scrum values. Instead of weighing the pros and cons or trusting an empowered Product Owner to make these decisions and order the work, you declare “It’s All Priority!”.

The reality of what you said is there is no priority. Priority means one thing is before something else. Which means people who have this lack of direction now are in a position of having to guess. Can you feel your credibility as a leader diminishing?

Since everything is priority- spread the people doing the work across all these items and don't allow them to Focus and get work to Done. And call them projects or tasks or teams and tell people they are 25% “allocated” to this thing, another 15% to that thing, etc. Decades old data which continues to be upheld proves this isn't effective and won't achieve faster results. In fact, it’s slower because of the context switching that people are experiencing. They need to remember where they left off on one project or task to ramp back up and get back to work on that. Only to get interrupted or told they should be focusing on a different project or task. One of the original data sets is provided here:

How credible do you feel knowing your employees not only have this data, they live it every day in your organization? The reality is you have handed every single person that is time-sliced a built-in excuse.

You ask them for information on project 1 and they tell you “Oh let me get that for you in a minute, I’ve been busy on project 2”. You ask someone for status on project 2 and they tell you they have been busy with projects 3 and 4. Who knows what is happening? With this chaotic approach to doing work there is zero transparency and a bunch of ready made excuses.

Understand why your credibility as an “Agile Leader” is pretty low and ready to fix it? The good news is it takes only 2 things:  dedicate teams and order their work.

That’s it. 

Want No Excuses and higher visibility into results? Never want to use the words Agile or Scrum again? No problem. Bring work to the team in a force-ranked order. That means something is #1. Then something else is next. This way there are NO EXCUSES. Work is either done or it’s not done and we focus on removing/working through the impediments to getting it to done. Yes, Agile approaches such as Scrum enable getting work done but only if used as directed. If you don’t make the structural changes required, the behavior doesn't change and it’s excuse time.

Want to be coached on how to become a credible Agile Leader? Contact us at: info@coleadteam.com

Why do so many Scrum Teams “carry over” work from Sprint to Sprint?

There’s no such thing as “carry over” in the Scrum framework. In fact, there are many mechanisms in place ensuring that work gets done and daily transparency into it not getting done.

One thing you might want to watch- using software tools to store the Sprint Backlog can contribute to work becoming hidden, or dark. It’s easy to just “add a card” or increase a Task time instead of unhiding that additional work.

What’s intended at Sprint Planning is the break down or decomposition of items pulled from the Product Backlog that the Development Team believes can be completed (that can get to done) during the Sprint. This is called “Topic One” in Sprint Planning or “What can be done this Sprint”?

What’s intended to happen next is often forgotten or lost. “Topic Two” or “How will the chosen work get done?” involves the Development Team breaking those Product Backlog Items down even further. Decomposing them into units of one day or less.

Why units of One Day or Less?

Scrum is an empirical process. That’s a fancy way of saying we course correct based on what we are learn. It requires Transparency to Inspect and Adapt appropriately based on what we uncovered or learned. The Daily Scrum is a Transparency, Inspect and Adapt mechanism on the Sprint Goal.

This is not intended to be a micro-management technique- just the opposite! Breaking work down enables Development Team members the chance to show progress towards the goal. That’s far more satisfying and motivating than staring at the same big blob of work on a backlog every day.

 If work is not broken down to units of One Day or less, no visibility is provided at the Daily Scrum. This is the land of 75% Done and Status Report Syndrome.

Why is lack of visibility or transparency so important?

The Daily Scrum provides an opportunity to Inspect and Adapt if the Sprint Goal is not met.

It’s also a Daily opportunity to provide visibility into where I’m stuck, where I didn’t get work to done and what’s getting in my way. Once the rest of the team knows this they can offer to help. It provides a way for the work to get “unstuck” and get Done – achieving the Sprint Goal. That’s far more enjoyable than listening to someone say over and over again “I’m still working on that thing, no blockers”.

Without this daily transparency, the Development Team and the PO have no idea if the Sprint Goal will be met until maybe the very end with no chance to course correct. We’ve also lost a learning opportunity and an opportunity for the team to pull together, working with each other to achieve their common goal.

Our Own Experience with Uncovering Dark Work

CoLeadTeam doesn’t just offer services using Agile and Scrum, we use the same framework we teach to manage our own work in two-week Sprints. Now you might be thinking because we teach this Scrum stuff, we’re really good at it right?  Nope!  The empirical nature of the process exposes what’s not working and CoLeadTeam is not immune to this. We found ourselves falling into the Dark Work trap many of our students and clients experience.

We noticed that the same thing being said at Daily Scrum. That items on our Sprint Backlog were piling up in Work in Progress (WIP) and very little was moving to Done.

We also noticed that team members weren’t offering to work together to get items to done, they would pull new items from the Sprint Backlog Not Started column into WIP.

Yep! We found ourselves in the same murky carry over situation that we caution our students and clients against. Dark Work!

At a Sprint Retrospective we agreed it was time to do something about it. A team member took one of the items on our next Sprint Backlog and brainstormed with other team members all the things that really needed to happen in order for that one item to be truly done.  The result?  There were over 30 units of work that needed to be done!

All hiding under just one card, one item on our Sprint Backlog. 

Shining a Light on Dark Work – What Can You Do?

·       Recommit to Topic Two of Sprint Planning:  Break work pulled into the Sprint down into units of one day or less.

·       Recommit to the Sprint Backlog: this artifact is the way the Development Team manages their work during the Sprint. It provides visibility into where items are on a daily basis and at a glance shows whether the Sprint Goal is on track…or not.

·       Recommit to Daily Transparency: the Daily Scrum isn’t “here’s what I did yesterday” it’s “here’s what I got to done towards the Sprint Goal”. Get on track with the actual suggested questions to be answered as noted in the Scrum Guide (https://scrumguides.org/).

·       Recommit to Transparency, Inspection and Adaptation: if there’s work not done, who can help? What is needed to get it done?

·       Recommit to the Sprint Retrospective: the Scrum Team (Product Owner, Scrum Master and Development Team) identifies a process improvement to correct in the next Sprint. If you still have carry-over from Sprint to Sprint, you have not effectively resolved the root cause of your process impediment. What is needed to prevent carry-over and uncover Dark Work?

If you’d like to learn more about using Scrum more effectively in your organization, join us for an upcoming course or event.

What is a ScrumMaster?

In a recent Certified ScrumMaster (CSM) course, a student new to Scrum was a bit confused by the repeated reference to the ScrumMaster as a “coach”.  “What do you mean coaching or when does this coaching happen?” was the question raised. Caught a bit off guard, or more importantly caught up in my own internal dialog of, “Well, doesn’t everyone who comes to a CSM already know this?” For a moment I was a bit dumbfounded. Then I realized that this is the very question that we need to spend more time answering.

Let’s just start with coaching. What do you think of when you think of coaching? Do you think of a sports team that has a coach? Do you think of losing weight and maybe hiring a personal trainer as a fitness coach? Do you think of accomplishing personal goals through engaging a life coach to help you stay focused? In any of these instances, the person that is in the coaching position does not do the work for the person being coached. The coach’s role is to:

·       Ask all kinds of questions – the obvious question, the dumb question, the hard question, etc

·       Make observations and play back what they are seeing, what they are hearing, what they are observing

·       Make recommendations, suggestions, provide alternative view points

·       Listen

·       Remind the coachee of the very goals that were set out to be accomplished and take stock of reality – is the goal being met or not with the actions the coachee is taking

Scrum is a different way to do work. It may sound simple to change to a new way of doing work, but many find the practice of Scrum difficult to accomplish. The official Scrum Guide is free to all and is available here.

The Scrum Guide is clear that a ScrumMaster does not only coach the team of people doing work or developing the product that will be used by customers, but they also have the responsibility of coaching the Product Owner and the Organization. The Product Owner gives direction about the product, and the greater Organization is comprised of other experts, users, customers and stakeholders about interacting with the Scrum Team.

That may sound like a big job, and it is!  This is why a ScrumMaster is a full-time job and not one that can be done effectively as part time. It’s not administrative at all. It’s about people. It’s about individuals and interactions. It’s about setting goals, accomplishing goals and more importantly, what needs to change if goals are not accomplished.

Think back to sports teams you may be a part of that had a coach. Or any sports teams that you watch. How many are successful without an effective coach? How many Olympic athletes achieve a medal without a coach? This idea is critical to a successful Scrum adoption. The ScrumMaster is the coach to the Development Team, the Product Owner and the Organization regarding making this change and when things get tough, not back-sliding into old habits or unsuccessful approaches that detract from the goal.

If you would like to learn more about Scrum or the ScrumMaster, refer to the free Scrum Guide. You can also join me for a Certified ScrumMaster course hosted by Hollstadt Consulting on Oct 2.

Author: Christian Antonie

Working Agreements Video

Synopsis

In Certified ScrumMaster courses a common concern of new Scrum Masters is how to be a more effective coach and help their teams improve.  One thing any Scrum Master can do to immediately add value and help the team that they are serving is to facilitate the creation of Working Agreements.  Maybe you’ve referred to these as Team Norms, Core Values or Rules of Engagement but for our purposes I’m going to refer to them as Working Agreements.  Why are these important for a Scrum team? Without working agreements, it’s really just a collection of people and not really a team. An effective Scrum Master, as active facilitator, can certainly help the Development Team and Product Owner create these agreements.

The Scrum Master can also be the steward of the working agreements, ensuring that they are posted where everyone can see them. It’s best to keep these short to ensure that they are well understood and of course, ensuring that they are enforced.

What are typical things found in these agreements? They can be tactical, such as the agreed upon times for all Scrum Events and then being on time for these events. They can also include protocol if someone cannot attend an event and how information is shared to those who are not able to attend.

An example would be sending a group text, posting to a Slack channel or sending a group email, so that everyone on the team is aware.

These agreements can also include more cultural aspects of what it means to be a part of this team.  Here are a few examples from our own Collaborative Leadership Team working agreements. We will assume positive intent. Which means, we won’t make bad assumptions about somebody else when we don't have all of the information. Another example is that it's okay to use humor but not to launch missiles at each other. It’s OK to have fun but not to cross a line to put someone down.

Revisit the working agreements from time to time and add new, relevant items or remove items that are no longer relevant.  This is the active way the team agrees to engage with each other so it should be current and visible. Hopefully, these tips have been helpful to you as you begin establishing Working Agreements with your teams.

Video Transcript

Hi. I'm Angela Johnson, Certified Scrum Trainer and Agile Transformation Coach with the Collaborative Leadership Team. Today, I'd like to talk to you about working agreements. Why are these important for our Scrum team? Well, without working agreements or team norms, you might just be a collection of people and not really a team. A good Scrum Master as active facilitator can certainly help facilitate bringing these about. They can also then be the steward of the working agreements, so that they are posted where everyone can see them. Keeping them short, making sure they are well understood and of course, enforcing them. What's in a working agreement? These can be tactical, such as being on time for Scrum events. What happens if you can't attend a Scrum event? There may be a working agreement that says, send a group text or send a group email, so that everyone on the team is aware.

They can also be things that are more cultural and what it means to be on this team. Let me share just a few examples of those from our own Collaborative Leadership Team working agreements. One of our working agreement says, we're going to assume positive intent. Which means, let's not make bad assumptions about somebody else when we don't have all the information. Another one of our working agreements says, it's okay to use humor but not to launch missiles at each other. Hopefully, these tips around working agreements has been helpful to you as you try to establish a few of your own. For more information about what it takes to be a great Scrum Master, please join one of our classes at https://www.collaborativeleadershipteam.com/upcoming-courses. Thanks for listening.

About Collaborative Leadership Team:

Collaborative Leadership Team (CLT) is the premier Agile Consultancy. We believe in the Values and Principles of the Agile Manifesto. Our mission is to train and coach Individuals, Teams and Leaders. This will improve their ability to deliver valuable, consistent, working product. Companies that adopt this way of working will reduce their cost of change and keep up with the evolving demands of their Customers. CLT helps you achieve your goals through Assessments, Training, Coaching and Mentoring.

Since 2010, CLT has had a significant impact on the way people and organizations achieve higher levels of productivity:

• Over 15,000 Students trained in Agile & Scrum

• Over 100 Organizations (Fortune 500 to family businesses) are achieving their goals by transforming and adopting Agile & Scrum

CLT brings Agile experience from all areas of business and technology. The Executive Suite, Software Development, Hardware Development, and Team Dynamics & Optimization.

For more information including Training offerings, Coaching offerings, Client Feedback. and more, please visit us at http://collaborativeleadershipteam.com

Accountability Layers

---

Do you know where your accountability layer is?

In the ocean (as marine biologist and Tom Clancy fans well know) there is a point where warm surface water and cold water from below meet. It’s called the Thermocline layer. It’s where the heat from the sun can’t sufficiently heat the water relative to the cooling currents from below.

How does this relate to Agile or Scrum? In a couple of ways, but the one we will focus on in this post is, “Where is your Accountability Layer”?

I’m talking about the level in an organization actually tasked with TCB (Taking Care of Business).  In a waterfall project this are usually Project Managers, Resource Managers, Team Leads, etc. These roles use words like “driving” and “managing” staff. Accountability for the success or failure rests here. Sure the QA team missed a bunch of bugs but those were just missed requirements, right? If only we’d have just planned more time to get the right answers first.

Agile approaches, such as Scrum, push this layer down to the team level. The TEAM is accountable for their work. The TEAM plans and executes. The TEAM decides the best way (within the boundaries set by the organization) to achieve the goal and deliver the value.

We still need the folks at the old layer level because the Team will need help, guidance, and organization changes that they can’t manage in addition to their new TCB focus. That assistance has to come from the folks that are best at providing it – the old layer.

I really feel this isn’t often addressed in current thinking about change. Moving this layer is a huge cultural shift in addition to the obvious, practical one. Most species in the ocean live above or below the Thermocline layer- and they don’t usually cross it willingly.

Want to learn more about cultural shifts with Agile and Scrum?

Click here to view our upcoming classes and register for our next CSM or CSPO course.

Author: Collaborative Leadership Team. Learn more about our coaches and offerings here.