The Agile Coach's Dilemma with Alan Dayley

With each new round of layoffs, the existential crisis facing the agile coaching community deepens. Alan Dayley joins me to discuss how the community is retrospecting on this moment and whether or not it is asking the right questions. 

You can find the interview here: https://tinyurl.com/4ttkd7nz

When Your Leadership Can't Agree - Featuring Mike Vizdos

Mike Vizdos joins me for this conversation that focuses on what to do when you are competing for resources with other Product Owners in your organization and management will not (or can not) create clarity on what the company's strategic priorities are.

Mike and I also discuss his work coaching senior leadership, how Patrick Lencioni's First Team concept has become such a vital part of his approach, and the work Mike has been doing with ImplementingScrum.ai.

You can find the podcast here.

An Abundance of Opportunity with Chris Li

A student wrote in asking about how to deal with: 

• PO can’t or won’t prioritize the backlog

• Team members are always taking on special side projects in the company

• The team is 35 people spread across several time zones - both on and off-shore

• Everyone is working on new products and also supporting up to 30 applications

• Everyone is expected to be at 100% utilization at all times.

• The Sprints are 4-5 weeks long (the size varies depending on the work to be done)

• One hour is allocated for Sprint Planning

This is a lot to address here so I asked my good friend (and fellow CST) Chris Li to join me to talk through these challenges.

 The video version of the interview can be found here: https://bit.ly/3SgK2jL

An audio version of the podcast can be found here: https://bit.ly/3xwfWkg

PODCAST TEAM UP! A Couple of Coaches and DrunkenPM on Metrics

Christine Converse and Ross Beurmann, the hosts of the podcast A Couple of Coaches and I teamed up for some interviews.

I interviewed them on Agile Metrics. During the podcast, we discuss what metrics help create clarity for the team on how well they are performing and what metrics help highlight areas that could be improved. We weigh the pros and cons of standard Scrum metrics, Kanban metrics, and share the ones we each find most valuable.  

It was a great conversation and if you are looking for a deeper understanding of what metrics to focus on, there is a lot of good stuff in the podcast.

You can find that interview here.

And they interviewed me for their A Couple of Coaches podcast on what it is like to be part of the Scrum Alliance TAC and what it takes to become a Certified Scrum Trainer. You can find that interview here. I rarely get a chance to be the interviewee and it was a lot of fun. I highly recommend their podcast. They offer some great insights and listening to them banter back and forth is a lot of fun.

The Agile Coaching Income Report with Jessica Katz

 

Jessica Katz has been hard at work collecting data for the new version of The Agile Coaching Income Report. She joins me to talk about some key insights from the 2021 report, what she's learned so far from the new data she has collected, and how people are using it to negotiate for better compensation.

You can find the interview here: https://bit.ly/3xcPSv5

Coaching Stances with Dan Eberle

This episode features an interview with Dan Eberle. Dan is an Agile Coach, working at the New York Times and leading a few Agile-centric communities of practice. During the conversation, we discuss different coaching stances, how to develop your skill with employing them, how to measure your success as an Agile Coach, how being an internal coach differs from coaching at a consulting company, some tips for those moving towards a coaching role, and things to watch out for as you head down that path.

You can find the interview here:
https://www.projectmanagement.com/blog-post/68980/Coaching-Stances-with-Dan-Eberle

Agile Coaching Ethics with Shane Hastie

If you’ve been working as a coach or a consultant for any length of time you have run into situations where you have to make a decision about what the “right” thing to do actually is. Sometimes, it is pretty obvious, sometimes, not so much. Some professional organizations have established standards that credentialed professionals promise to adhere to. The International Coaching Federation has the ICF Code of Ethics and the Project Management Institute has a Code of Ethics and Professional Conduct. In January of 2020 the Agile Alliance launched the Agile Coaching Ethics Initiative. In January of 2021, they launched a draft of their Code of Ethical Conduct for Agile Coaching along with a set of scenarios to help clarify what is, and is not an appropriate response in a variety of complicated situations.

You can find the interview and more on this topic here: https://bit.ly/2Q1zWbI

Resistance to Change with Christine Converse and Ross Beurmann

Christine Converse and Ross Beurmann are back and this time the conversation centers around the problems we face when trying to create change within a team or organization. More specifically, we talk about how you can influence others to change when you have no authority, the people you are trying to help may have no desire to be helped. Whether you are working in an agile environment, a traditional organization, or something that is careening back and forth between the two, this interview is going to give you a lot to think about.

You can find the podcast here.

Untapped Agility with Jesse Fewell

In this very special video episode of the podcast, I’m joined by Jesse Fewell, whose new book Untapped Agility is full of insights, tips, and tactics that you can use to help gain support for your adoption of Agile. Jesse and I go way back. We worked together a lot during the initial phases of getting The Project Management Institute and the Scrum Alliance to talk back in 2009-2010. It was great to catch up with him and I highly recommend his new book. 

Click here to watch the interview on ProjectManagement.com

The Art of Coaching with Christine Converse and Ross Beurmann

Two of my colleagues from LeadingAgile, Christine Converse and Ross Beurmann join me for a conversation on the Art of Coaching. During the interview we discuss how paired coaching strengthens their ability to foster organizational change and help companies move towards business agility. We also explore the differences between coaching executives and coaching team members, how paired coaching works, and why it has become such a powerful approach for them. Along the way, they both offer lots of tips and techniques you can employ whether you are working as an Agile Coach or serving on a team trying to help them, and your organization raise its game with Agile. 

You can find the podcast here. 

ALSO, this podcast features a brand new theme song for the podcast that was created by Chris DeMakes. If the music or Chris’s voice sounds familiar, that’s because Chris is in the band Less Than Jake. He also has a podcast of his own where he interviews songwriters and producers about the art of creating great music. The podcast is called Chris DeMakes a Podcast and it is definitely worth checking out. 

Working in Quarantine - What We Learned - Week 1

Jessica Wolfe, Derek Huether and I recorded a Zoom call talking about what we learned after our first week of working under quarantine. This was recorded on 3/29 and we're going to try to make it a semi-regular thing. We're posting it on Derek's YouTube channel.

Getting Better at Saying No with Tim Wise

One of the hardest parts about being a good Product Owner is saying "No" all the time. No matter how much experience you have, or what your reasoning is, telling people you aren't going to give them what they want is never easy. 

My friend and colleague, Tim Wise, joined me for a podcast where talk all about how to get better at saying No to people.

You can find the interview here.

Ryan Ripley - Fixing Your Scrum

Fixing Your Scrum is a new book by Ryan Ripley creator of the Agile for Humans podcast, and Todd Miller. It is full or real-life stories with practical advice from two seasoned professional Agile Coaches.

You can check out my interview with Ryan on the Reluctant Agilist Podcast here:
https://www.projectmanagement.com/blog-post/62194/Ryan-Ripley---Fixing-your-Scrum

Agile Coaching: Wisdom from Practitioners

In this podcast Michael de la Maza and Dhaval Panchal talk about their new book “Agile Coaching: Wisdom from Practitioners”. Michael and Dhaval are the co-editors of the book which is full of stories, tips, and advice from experienced, Agile coaches and trainers. In addition to talking about the book, Michael and Dhaval also share their own thoughts on topics around coaching and they offer advice for those who are headed down the coaching path.

SHOW NOTES

01:28 Podcast Begins

02:01 Who is the book for

02:26 What misconceptions do clients have when an Agile coach walks in the door 

03:52 How do you provide coaching in an organization that is not ready for it

05:04 How do you (as a coach) coach yourself when you are trying to work with individuals that do not want your help

07:12 Some tips for getting started with a coaching engagement

10:27 What does it take to become an Agile coach

13:17 What is the job of an Agile coach

13:53 When the client wants to pay large sums for you to MAKE them agile

19:06 When will we evolve past waterfall?

23:41 Do you have to be an expert in Agile to be a good coach? What do you need to do before you can be qualified to be a coach?

29:01 Are there people who should not be coaches?

32:05 Getting in touch with Michael and Dhaval

THE BOOK

Agile Coaching:  Wisdom From Practitioners

http://amzn.to/2fEV31F

TO CONTACT MICHAEL

Michael Email: michael.delamaza@gmail.com

Michael Twitter: https://twitter.com/hearthealthyscr

TO CONTACT DHAVAL

LinkedIn: https://www.linkedin.com/in/dhavalpanchal/
Twitter: https://twitter.com/dhavalpanchal

Agile 2016 - Michael Spayd & Michele Madore on Trans4mation

Michael Spayd and Michele Madore stopped by to chat about their new company Trans4mation which focuses on helping executive leadership migrate from a traditional way of leading/working into an approach that is more deeply rooted in Agile.

You can learn more about the work Michael and Michele are doing by going to Trans4mation.coach, or by reaching out to them using the information below.

Michele Madore

Email: michele@trans4mation.coach
Twitter: @t4_agile

Michael Spayd

Email: michael@trans4mation.coach 
Twitter: @mspayd

DrunkenPM Radio 3: How to Cope with Coaching Burnout - with Lyssa Adkins

Lyssa Adkins is one of the leading voices in Agile coaching. A founder of the Agile Coaching Institute, her book “Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition”  set the bar for what it means to be an Agile Coach. In this interview Lyssa and I talk about what’s happening with the Agile Institute, coaching middle management and how to deal with coaching burnout.


Show Notes
The Super Nervous Interview Begins 2:10
Focused Listening 4:05
Four essential skill sets of coaching 6:00
The difference between “coaching” and being a professional coach 6:30
Big things going on at Agile Coaching Institute 7:45
Coaching Middle Management 8:40
The impact of the cultural change Agile brings 11:40
Is there a limit to how much change we can handle and where are the boundaries 12:30
Background on the burnt out coach14:30
Burn out is on the rise with Agile Coaches 15:00
Finding a path you can be on with heart 15:45
Finding the heart in letting the org become what it wants to become 16:40
Checking your own ambition 18:20
Goal setting and knowing when to walk away 19:00
What to do with the organizations on Life Support 19:15
Hospicing the death of old systems 20:20
Trying to reach people who don’t want to take your hand 21:30
Meeting confusion with curiosity 22:20
Agile coaches are agents of human evolution 24:00
How Agile Coaching Institute helps organizations 24:30
Developing a coaching capability that is in sync with where the organization’s goals 25:45
How to find and develop the coaches in an organization 27:45
How to help a burnt out coach/change agent 31:25
The importance of self-care if you want to be present and help others 32:50
Exposing why people avoid self-care35:00
Ways Lyssa practices self-care 35:30
The job is to “allow” 37:05
You can’t let go because it’s the tension that holds it together 38:18
What happens when you do let go 38:50
Lyssa Reads Poetry 40:25
All of us in the Agile community are part of evolving our capacity for complexity 41:45
We are in the time of organizations being living thing 43:05
How to contact Lyssa 43:25
Lyssa’s advice for the coaches who are feeling burned out 43:55
Lyssa’s Coaching Agile Teams book is 6 years old 44:45
Thanking Lyssa for making me uncomfortable (in a good way) 45:50
Upcoming Events for Lyssa 46:00
Links Mentioned in the Podcast
Lyssa in Twitter https://twitter.com/lyssaadkins
The Agile Coaching Institute
http://www.agilecoachinginstitute.com/coaches/
2016 Scrum Gathering Agenda http://bit.ly/1Upsg9W

Perseverance - Meg Wheatley http://amzn.to/1W4PSmM
Little Guide to Empathetic Technical Leadership - Alex Harms https://leanpub.com/littleguide
Agile Base Patterns, a Cross-Quadrant Conversation - a conversation between Lyssa Adkins and Dan Greening http://www.infoq.com/articles/agile-base-patterns
Iawake.com http://www.iawaketechnologies.com
The Heart Aroused: Poetry and the Preservation of the Soul in Corporate America - David Whyte http://amzn.to/1NtifV7

Language is a virus from outerspace

William S Burroughs by Gary Schoichet

"Language is a virus from outerspace"
 William S Burroughs

Language is a tricky thing. It is a broken, imperfect system of encoding and decoding a message. If the encoder and the decoder have the same key, the message may be heard and understood as it was intended. If the encoder and decoder have different keys… bad things.

The encoding and decoding takes place on many levels and often carries around a lot of baggage.

If I am in a conversation and someone says:

“Yo, hand me that jawn over there. “

It probably means they are from, or have spent a significant amount of time in Philadelphia.

If someone says:

“We need to assign some resources to work on this project.”

It probably means they have been trained to manage or work with projects using a traditional (waterfall) approach.

When I took my CSM training I sat in a room full of 40 software developers. When I referred to people as “resources”, they boo’d me... literally.

In Agile, and in traditional project management we both use resources on our projects. But, because Agile takes care to focus on “Individuals and Interactions”, resources are generally considered to be things that do not have opposable thumbs and a capacity to binge watch five seasons of Breaking Bad in a 3-day weekend.

The way we use language infects our interactions with individuals. In this TED Talk, Diane Benscoler talks about being deprogrammed from the cult she had joined as a young woman. In the talk she refers to a “viral memetic infection”. This is, simply put, how language can be utilized to hack the brain.

In working with people on a project, if I regard them as individuals I work and interact with, I am likely to behave differently towards them then I would if I were to regard them as resources I expend to get work done (like a stapler). This can appear in very subtle ways – or, at least, ways that seem subtle to the non-Agile.

When I first began working in Agile I stumbled over a lot of similar encoding/decoding issues. The more experience I got with it, the more I learned how important it was to translate ideas before they passed my lips. As I would speak with someone about the project I was still thinking in waterfall, but speaking in Agile.  I’d think “resources” but say “team members”. And that helped a little. At least, I thought it did. To other PMs, it sounded very Agile, but being a little further on with it now, I do feel it is fair to say that language aside, intent shows through. If I am thinking “resources” but saying “team members”, the fact that I have not truly bought into the Agile mindset still shows through to those who do think of individuals and interactions.

http://www.acminc.com/wp-content/uploads/festrunk.jpg

If you are in the process of trying to transition from traditional to Agile, it is important to bear this in mind. There is often a significant difference between how we perceive ourselves and how we come across to others. I may believe I am able to fit in with the Agile folks once I learn to speak their language. Certainly that is a massive improvement over not doing so, but being able to speak the language and adopting the behaviors and value systems are not the same thing. One may lead to the other, but being aware of the fact that it is an ongoing process is an important art of not destroying your credibility along the way. 

How to Avoid Overcommitment During Sprint Planning

Awhile back I was working on an Agile coaching gig with Tom Smallwood. We were working with a team that moving to Scrum and was having a particularly difficult time meeting their commitments.  Stories were being estimated in Story Points using the Fibonacci sequence and they were breaking stories down into tasks that were then estimated in ideal engineering hours. Stories were (mostly) small enough to go from card on wall to potentially shippable in about 2 days. Tasks were kept to between 4 and 12 hours. Unfortunately, despite following the basic guidelines we were giving them, they were still WAY over committing each Sprint.

Tom was the first one to notice that even though they were all confident in their ability to get the work done at the end of a Sprint Planning meeting, what they were confident about was in fact, completely impossible. What was happening was that each person was assumed to have a capacity of 8 ideal engineering hours per day. Since we were working in two-week iterations, this meant each person was on the hook for 80 hours of productive working time in a Sprint. 

The way we addressed this initially was to ask them to plan for no more than 6 productive working hours per person each day. This helped, but it still wasn't cutting it. The problem was that each person had more that they were responsible for than just the project we were working on. (Yes, this is not ideal, but it was reality at the time.)

The solution we came up with was very simple and it is one I have used on every team I worked with since. It adds an extra step to the Sprint Planning ceremony, but it has been invaluable in helping teams understand their capacity and preventing over commitment. 

(Disclaimer - this involves using relative Story Point Estimation for Stories and Ideal Engineering Hours for Tasks. There are many who do things differently and have great success - which is awesome... what follows is just what I have found to work well for me and the teams I've worked with.)

What we added was a step in the 2nd half of Sprint Planning. After the team has taken the User Stories (estimated in Story Points) and broken them down into Tasks (estimated in Ideal Engineering Hours), we would go around the circle and ask each team member to estimate how many ideal engineering hours he/she could commit to being responsible for in the upcoming Sprint. One of the most critical parts of this is the idea that the commitment being made is not to the PO, but to the other members of the development/engineering team. So, if I tell my team I'm good for 35 hours, then my team can count on me to be responsible for 35 hours of task work. If I commit to that and do not contribute that amount of time, my team members will have to cover for the work I've not done. While this should go without saying, I have found it to be helpful to mention when starting this part of Sprint Planning. 

So, going around the circle, each team member has to be aware of how much time they can commit to contributing. This means they need to account for a lot of the things that get in their way.  

Here is how I normally coach people to think through this:

In a two-week iteration, you begin with 10 working days. However, I normally block out 1 day for Sprint Planning, 1 day for the Sprint Review and Sprint Retrospective, 1/4 day for the 8 remaining days during which the team will hold a 15 minute daily standup and 1/4 day for an Estimation/Story Meeting. While blocking out 1 whole day for Sprint Planning and 1 whole day for the Sprint Review and Sprint Retrospective meetings is more than the Scrum Guide calls for, I have found that it is more realistic to working under the assumption that the team will get little else done on those days. 

If the Sprint is 2 weeks long, we start with 10 working days. Once we block out the time mentioned above, we end up at 7.5 working days.

If we assume each person can be productive for a maximum of 6 hours per day, then:

 6 hours/day * 7.5 days = 45 

So, the absolute Maximum Possible Productive Hours (MPPH) for any individual in a two- week Sprint is 45 hours. 

We then ask each person to total up the amount of time they expect to lose during the upcoming Sprint to the following events that are not part of the Scrum Framework:

• Standing Meetings  - recurring meetings held each week that will keep them from working on the project
• Holiday/PTO - expected
• Vacation/Sick time - expected or averaged
• Medical/Dental/Other Personal Appointments - expected or averaged
• Emergency Fixes* - average time lost per Sprint to emergencies which require them to temporarily abandon their work on the project
• Misc. Additional Time - Any additional time they feel they should block out to address other issues, work or personal, which will inhibit their ability to contribute to the project during the Sprint

* Getting pulled away from a project to deal with emergencies that are not related to the project is a dysfunction that will impair the team's ability to realize the full benefits of Scrum. However, in several organizations I have worked with, it is a constant reality. When things break, and the money stops flowing, it's all hands on deck.

The total of the above is the Interruption Time (IT) that each team member must subtract from his or her   MPPH. The amount of time left is the Revised Maximum Possible Productive Hours (RMPH).

If the individual is only working on a single project, then the RMPH is the amount of time that individual should feel comfortable sharing with their team members as their Committable Productive Time (CPT). 

If the individual is split on multiple projects, then they should multiply the percentage of their time that is allocated to the project by the RMPH. They should then subtract an additional 10% from the result (for context switching) to get their Committable Productive Time (CPT).

Here is an example of the above...

Interruption Time:

• 4 hours standing meetings
• 8 hours PTO
• 3 hours for dentist appointment
• 5 hours average time lost to Emergency Fixes
• 5 hours subtracted because I will just be returning from overseas and I expect the jet lag to have a negative impact on my productivity for a few days

Interruption Time (IT) = 25 hours

45 (MPPH)

- 25 (IT)

20 (RMPH) 

If I am split across 2 projects at 50% each...

20 (RMPH)

*50% allocation

10 hours

-10% (context switching)

9 hours of Committable Productive Time

In talking through this, it is very common to see jaws drop. However, if each person on the team is doing this, then the team will have a realistic understanding of its' work capacity in a given Sprint. While the idea of having to tell someone responsible for your performance review that in a two-week period that you can only be counted on for 9 hours of time may be scary, it is honest. If we are practicing Scrum and sticking with transparency (one of the 3 legs of Scrum), and we are being responsible to our fellow team members, this is the most responsible, transparent thing we can do. 

Once each team member has shared their CPT, they are totaled up and this is the Team's Committable Productive Time (TCPT). As long as the total number of estimated ideal task hours does not exceed the TCPT, then the team should feel comfortable making a commitment to the Product Owner for the Stories they will complete during the Sprint. If the number of estimated ideal task hours does exceed the TCPT, then the team may have to negotiate with the Product Owner to reduce the work being planned for the Sprint before they make a commitment. 

I have also seen teams break things down even further into number of hours for development, testing, etc., but what is above is typically as deep as I go with it.

It adds an extra step, but it helps the team members inspect and adapt their own workload and capacity. This will also better enable them to meet their commitment in a Sprint; IMHO, the benefits of this far exceed the few extra minutes it will take for a team to make sure they are not overcommitting. 

Catching up... Podcastapalooza

I'm ludicrously behind in keeping the blog up to date... working on that... here is a list of all the podcasts I've done for Projects At Work since The last posting about Mitch Lacey. There is a lot of great Agile stuff here...

Howard Sublett from BigVisible
Part 1 of 1

Martin Rosenqvist on Agile Transformation
Part 1 of 2
Part 2 of 2

Tom Kealey on Getting Agile transformation to Stick
Part 1 of 2
Part 2 of 2

Kenny Rubin on his new book Essential Scrum
Part 1 of 2
Part 2 of 2

Dan Greening on Enterprise Scrum
Part 1 of 3
Part 2 of 3
Part 3 of 3