Michael Hunter
Hello!
Welcome to Uncommon Leadership.
I’m Michael Hunter with Uncommon Teams.
Today I’m talking with Colleen Johnson.
Colleen has been working in the technology space for over twenty years, with half of that focused on improving the way we deliver value. She has taught and presented Agile concepts to audiences around the world, but is happiest in the Colorado mountains with her husband and three kids.
Welcome, Colleen.
Colleen Johnson
Thank you for having me, Michael.
Michael
Happy to have you here today.
In your journey to seeing people as people and learning to leverage their unique gifts to best accomplish your goals, what has been your biggest struggle?
Colleen
I’m the CEO of prokanban.org and have spent a lot of my career coaching and teaching kanban at all levels of the organization.
One of the places where we get stuck a lot is in this concept of swarming.
A lot of the simulations and a lot of the ways that we teach kanban really do encourage you to have a conversation about how you can swarm the work.
Is it blocked? Let’s swarm it.
Is it aging? Let’s swarm it, or go swarm on something before you pull in new work.
Maybe in an ideal world, that’s how we would love to see teams operate, but it’s not always the reality.
We do hire for specialization in a lot of teams, and I’ve even been in organizations where I’ve had a CTO (chief technology officer) tell me, “I hire developers to develop. I don’t want them doing testing. We have testers to test.”
My gut reaction earlier in my career would have been to fight that and to say, “We can all learn from each other and let’s pair and let’s work on these things together.”
But I’ve shifted my stance with that quite a bit over the years of coaching and teaching to be more about respect for people and respect for your peers on your team.
When we think about how work moves through a team, and especially if you’re in a pull-based system, it’s not so much about whether or not you are capable or willing to swarm or pair on something to get it unblocked or to get it to done, but it’s more about not creating a pile of work that somebody else on your team is going to have to catch up with.
That’s stressful.
It means that we end up rushing and moving quickly to try to alleviate that pile wherever it is.
We see it most often if you have dedicated QA (quality assurance, often aka testing) roles, it tends to be whatever that step is between Dev and QA.
We’ve got often more developers than we have QA folks, and if we’re working in sprints, that tends to get pushed to the very end.
One of the hardest things for me and seeing that was moving away from pushing so hard on teams to swarm and switching my stance to say it’s not about that everybody has to be good at everything and everybody has to be able to do every function on this team or every activity on this team.
What it’s more about is respecting your teammates and not adding to a growing pile of work that we can’t keep pace with. And sometimes that means not starting something new.
Michael
What was hard to you about making that shift?
Colleen
I would rather see a team be willing to jump in and swarm. When we think about how teams work together, that’s what we would love to see happen.
I’ve been doing a lot of coaching work with security teams over the years, and that’s a great example where there’s such a high degree of specialization, it’s not easy to say this team with this function is going to share work because you might have somebody who specializes in development work, you might have somebody who specializes in risk and compliance, and you might have a security team here, but they’re not delivering work together where they can all contribute equally to everything on the board.
It’s taken watching some of the different applications for me to see that when we think about those things, it might seem a little altruistic to say I want everybody on the team to be able to contribute together.
But the reality of how teams are brought together and how their skills are brought together to deliver value in real life just varies.
Michael
Was part of the challenge for you, letting go of that altruism?
Colleen
Yeah, absolutely.
I would love to see teams that can swarm. If you can swarm, you should.
But it is hard sometimes for people to step into a different role.
And even though we would coach, maybe instead of pulling new work into a development column, go help a tester test, but there’s a cost, of context switching, even for a function that way or a specialization that way.
And in the same way we would say we don’t want to see a lot of context switching across work on the board that’s in progress, it’s backing away from some of those things that seem easy on paper but harder in practice.
Michael
Especially depending on the people you have on the team.
Some people love being generalists, so they’d be happy to switch between dev and test and security and release and whatever else.
Other people just really want to write code or find all the places the code is broken and making them do the other things isn’t optimal for anyone. They get grumpy, they don’t work as well as they would otherwise.
Colleen
That’s very true.
Then you’re creating a different problem, where you may have people doing a lackluster job of the tasks you’re asking them to do because they’re not very engaged or enthusiastic about jumping around and trying to be more of a generalist.
In software, well, not just software, probably every field; we say yes to everything and we want to be a good team player and a good contributor to our team.
If you go back to that lean concept of respect for people, it’s really about understanding the impacts of pulling new work in.
That’s where, when I’m working with teams, especially if we’ve gone through any kind of kanban simulation, where that becomes the hot-button topic of, “We can’t all jump around,” and “What are you saying? You want me to just sit there with no work to do if I can’t contribute to something that’s on the board?”
And it’s like, I’m sure you could do some research or review tickets for things that are in the backlog, but what we’re really asking is that you don’t screw over one of your teammates by pulling in a bunch of new stuff. I’m probably hypersensitive to it.
I started out in QA as well, and I feel like we had more waterfall-based projects back then. I would spend nine months of the year playing ping pong and then three months of the year panicking, trying to get some big project out the door at the last minute.
If you think about that, even our sprints end up that way sometimes, where at the beginning of the sprint there’s not a lot of work for testing folks. At the end of the sprint, there’s a rush to get everything over the finish line.
Unfortunately for a lot of teams, that means development goes and starts on new work for the next sprint and we end up with those offset cadences where we’re not really working together anyway.
Michael
That’s really difficult to balance within a team and across teams.
I’ve seen similar situations at a larger scope where everyone who’s done with all the work for this release gets to start on the next release and everyone who is still finishing up gets to keep working on the current release.
That means a couple of sprints down the road, some of the teams are already almost ready to release again, while other teams still haven’t got that last release out the door.
Colleen
Exactly.
When you think about the way we’re trying to encourage collaboration and the way that we deliver, we break that down the minute we let that happen.
Some of that pressure often comes from the culture of the organization to keep everybody utilized.
We’re focused more on keeping everybody busy instead of what value we’re delivering.
If you can start to shift that focus in an organization to be more about value, then there feels like there’s less pressure for everybody to stay busy all the time and end up in that scenario you just described where, my individual contribution is done, so I’m going to go find something else to keep myself busy. Even though we may not have delivered any value as a team yet.
Michael
How do you help teams make that shift to prioritizing team productivity over individual productivity?
Colleen
Typically through trying to make a lot of flow metrics more visible.
From a flow metrics perspective, probably one of the most underutilized data points you could put in front of a team is the work item age, which is: how old is this ticket that’s in progress?
That works at every level of work item.
It works for customer support tickets or help desk tickets.
It’s going to work for epics and features.
A lot of times, when we can see how old things are that are in progress, it’s going to make us stop and say, “Wait, should I pull something new in?”
If this feature has been in progress for ninety days, maybe we need to do something to address why that’s continuing to age.
If it’s aging in progress, then it means that we haven’t delivered any value there yet.
That’s the other piece: it really starts to be kind of a driver for the team to take action at any level. To say, “What are we going to do to get this thing out the door instead of pulling new work in?”
A lot of teams, that can be a more powerful place to start than even putting WIP (work in progress) limits on the board.
I see a lot of teams really push back on WIP limits because they feel like, “I could do more work. I need to stay busy. I don’t want to not have work to do.”
But if we could see how old stuff is that’s already in progress, and there’s a cost there. There’s a cost that we haven’t had a return on value yet.
Take that feature.
If there’s a feature that’s been in progress ninety days, there’s a sunk cost that we haven’t had any return on until that gets deployed and put in front of a customer.
How do we do that sooner?
So, I like to make work item age visible.
Most of the tools we use suck at this. They’re just really not very good at making that visible in a clear way.
For a lot of teams, I’ll have them just put the date the ticket started or the date the feature started in the title so that you can see it on the board and start to have a conversation about the oldest items first.
Michael
What are the signals that typically tell you this item is too old or items are getting old enough that the system is stuck somehow?
Colleen
Past data can typically be a great place to start there.
Looking at your cycle time data to say, “How long does it typically take for us to finish work?”
You have to be really careful, though.
Averages are probably going to lead you a little bit astray here because you’ll be wrong about half the time. What’s the line? “Plans based on average fail on average.”
If we are planning based off an average, we’re probably going to miss the mark.
If you have tools available that will give you the ability to see different percentiles for your past cycle time, that’s a great place to start to set what that threshold is for your team.
From a kanban perspective, we use the term “service level expectation”, or SLE. We use “expectation” instead of “agreement,” because agreement kind of implies that the customer is on board with that time too, which might not be the case.
An expectation is really the team’s expectation for how long things will take and becomes a way for them to manage the work that’s in progress.
If you have the ability to look at your cycle time data and start to look at percentiles across that data, so that you could say, “70% of our work takes eight days or less, 80% of our work takes twelve days or less,” maybe we’re going to come in somewhere in the middle as the team and say, “We don’t want anything to take ten days or less for this team. We know that that’s our signal that we need to do something different.”
There’s a step two, part two to setting a great SLE, and that’s deciding as a team what you’re going to do about it.
I see a lot of teams set SLEs and post them.
They’ll have them in Jira on a ticket, or they’ll have them in Kanbanize so that you could track your work against that SLE or that signal.
But you end up with all the little red dots across the bottom of your ticket, or you end up with all the signals flashing that things are aging and nothing changes.
It’s really important to set some working agreements as a team first.
It could be things like, “We’re going to swarm it,” “We’re going to stop and inspect whether or not it’s still valuable,” “Maybe we’ll split that story so part of it can move forward and the rest can go back to the backlog.” Maybe it was too big to enter the system in the first place.
We have a tendency with a lot of those visual cues in our boards; they’re there, they’re available, they’re telling us there’s a problem, but we don’t have a plan in place as a team to do anything about it yet. You need both.
Michael
When you experience teams that you’re working with being stuck, do you have a favorite tool or technique that you often go to first to help jiggle them loose?
Colleen
Stuck with delivery?
Michael
Or stuck in whatever they’re trying to change.
Colleen
I try to approach a lot of change at the team level, always as an experiment.
Positioning any change as something where, “We’re going to try it and it doesn’t have to stay this way,” is a little less threatening than saying, “We’re going to change our process,” or, “We’re going to change our workflow,” or, “We’re going to change our tool.”
To say, “Everything can stay exactly the same as what we’re doing now, but we’re going to test this thing out,” and trying to have a really clear expectation for what does success look like.
We’ve created a great culture in the Agile space of running experiments, but I don’t think we do a great job of saying, “What does good look like?” or “Why would we abandon this?” or “What are the criteria for what a failure looks like?”
If we said, “Hey, team, we’re going to try putting WIP limits in place, and here’s what we would expect to see as a result of putting WIP limits in place. Here’s how we’ll know it’s working and that it’s a worthwhile investment for us to keep doing. But if we don’t see that, then let’s not keep doing it. Or let’s try a different number for WIP limits.”
And we’re busy.
Everybody’s busy doing other things, too.
So, how do you make sure that you have those conversations before you start trying different things out?
The other piece in terms of change is that I always really try to understand where the team’s pain is right now, whether that’s with a survey or retro (retrospective) data or just interviews with team members.
After years and years of coaching and consulting, I hear a lot from teams when we get brought in to help them do something different, “Why do we have to do this in a different way? What we were doing before wasn’t broken.”
They may have a very different list about what wasn’t working or what is broken.
If I can understand that, I can help have a better conversation about what changes might help them with their specific pain.
But if it feels like it’s a one-size-fits-all solution that’s just being shoved down everyone’s throats, you always meet resistance.
So, trying to understand their pain so that you can have a conversation about the changes that will really hopefully show improvement for how they’re working.
Michael
How do you handle those situations where management or someone is forcing a change on the team and the team is like, “This is not the change we need?”
Colleen
It depends a lot on what the change is.
I would try to push back on the leader first if I thought it wasn’t the right thing for the teams.
Try to push back in a way to say, “Can this be something that teams get to opt into, or that we run with one or two teams to see if it’s working first for them before trying a one size fits all approach to everything?”
With a lot of things, the idea that you layer in some change without taking something away is a great place to start, even if it’s something that’s mandated.
As flow metrics and forecasting are becoming more popular in organizations, a lot of places are trying to move away from story pointing, and that’s a great example.
Some teams are ecstatic to not do story pointing anymore. Some teams really like it. They like the conversation or they like the pointing process.
In situations like that, it’s more like, “Well, we don’t have to take this away, but let’s use the forecasting methods of looking at throughput and running these models to say, ‘How does that compare with how your estimates came out from a story pointing perspective?’ and then run those in parallel for a while until the team either says, ‘We’re going to stay like this,’ or ‘We’re going to do both.’”
Instead of it being a one or the other, it’s a one and.
Michael
“Yes, and” is one of my favorite tools.
Colleen
Yes, exactly.
Michael
With all the work that you’ve done with teams, what do you believe has most impacted your ability to achieve what you have?
Colleen
Honestly, probably motherhood, which I know is kind of a weird answer.
We’re seeing a lot right now of emotion in the Agile space because our identities are so wrapped up in our roles.
As we’re seeing a lot of disruption and shift from whether or not Scrum Masters are valuable or Agile coaches are valuable in this space, there’s a lot of almost infighting, there’s a lot of angst.
It’s like if you say something wrong, I’m going to yell at you on LinkedIn because I feel maybe personally threatened because my identity is so attached to that specific role.
Maybe becoming a mother made me detach from that a little bit more.
So that, in a lot of ways, maybe it’s harder to ruffle my feathers, because I feel like there’s other things for me that are more important in my life than just being a coach or a trainer or a scrum master, whatever that role might be.
I know it’s probably an unconventional answer.
It shifted my priorities a lot.
It makes you also acutely aware for other people how much else they may have going on.
I can think back to moments in my twenties where I was very headstrong, very stubborn, probably pushing a lot of people without thinking about what they might have going on for them as soon as they walk out of the office.
That’s one of the things that’s easy to forget.
You never know what’s going on for other people.
My family helps me keep that in perspective.
Michael
Have you found techniques for helping teams become more aware of everything else that’s going on for everyone else?
Colleen
That’s a hard thing to do.
I’ve used tools like empathy mapping before when things have gotten really intense for a team.
I had a team one time that was really butting heads with their product owner.
With her permission, we did an empathy map as a group to talk about what she might be hearing, feeling, seeing, thinking.
I didn’t want to do it without her in the room.
I said, “This is going to be weird. We’re going to have a conversation about you, but I want you to be in the room with us, I want you to hear what the team thinks is going on for you so that you can weigh in afterwards and say, ‘That’s spot on. That’s exactly. I’m feeling pressure from the customers to deliver on time. But what I’m actually thinking about is, how do we break these into smaller batches? Not, why aren’t you guys delivering?’”
Those can be helpful exercises, but it’s going to depend a lot on the willingness of the team to have difficult conversations.
When we start thinking about things like that, what’s going on for other people, there’s a level of vulnerability required to be able to open up and first of all, share, but also a willingness to listen to each other and understand.
And when tensions are high, those are the first things that we typically stop doing well.
Michael
When teams aren’t ready to listen at that level, have that vulnerability, what can we do to help ameliorate the situation?
Colleen
I’ve seen a lot of different things tried here; bringing in a facilitator from outside the team or outside the company, or team building retreats.
But some of those things don’t actually address what’s going on for folks.
It can help sometimes to get a team away from work and get to know each other outside of a work setting, which gets harder as we add remote work to our lives.
Sometimes having a chance to escalate or vent the things that your team is struggling with without having to do it face-to-face can be more comfortable for some people.
Having a way to capture that feedback and a method where it can be maybe mixed together and reviewed offline can also be helpful.
That’s where retros, surveys, things like that, can be really good at making sure that you’re giving everybody a chance to be heard in a way where they feel comfortable communicating or comfortable sharing that feedback.
Michael
In all the work that you’ve done, what’s the biggest red flag you found of, what’s going on here is not okay?
Colleen
That’s a tough one for me to answer.
My mind is going to some leadership dysfunction.
And back to what you said about mandates.
Some of the most successful companies I’ve seen from an Agile perspective and healthy teams perspective give their teams a certain amount of autonomy but frame the box well with, “Here’s what’s expected. Here’s the expectations. We’re going to shape the box or frame the box. Inside that box, you’re free to pick how you work, how you do standups, how often you come into the office. But here’s the expectations we have as an organization that still need to be met.”
Maybe that’s reporting or maybe that’s visibility into what’s getting delivered.
There can be a lot of different things there.
Organizations where I’ve seen them have really strict mandates all the way down to throughput, for example, or things that are going to be a lot harder for them to control without teams maybe taking some questionable steps to do that.
That’s what you see.
You see that the output reflects the requirement.
I always think of that Wells Fargo example where the Wells Fargo employees were opening checking accounts for other people because they were incentivized to open more accounts.
If we’re going to incentivize teams to hit a certain throughput target, we’re probably going to see the quality of work deployed go down or we’re going to see that the stories aren’t completely usable pieces of functionality.
We have to be careful with the things that we decide are required for teams and try to give them a certain amount of autonomy, but really frame that box so that they understand what’s inside of their control and maybe what the expectations are across the whole organization and why.
Michael
How do you explain the business value of doing that? When managers, directors, VPs (vice presidents), whomever, don’t get it, they know what they think needs to be done and they don’t understand why this different approach might be useful?
Colleen
Unfortunately, it is often at that level less about the value of what we’re delivering and more about the cost of losing people.
If you can quantify for an organization how much they spend acquiring and retaining talent, that’s a great place to start that conversation.
You spend all this time and money to get the right people on these teams and you’re going to lose them.
Everybody’s trained to hire brilliant people to help deliver value.
If you take away their ability to do creative work, whatever that looks like for that team, and give them the autonomy about how they deliver work, they’re going to go somewhere else.
That might be a little harder right now with the economy being stretched thin in a lot of spaces.
But that’s a great way to get leadership’s attention, is to make sure they know that people won’t stick around without that opportunity to be creative.
Michael
We started with your biggest struggle. What would you say has been your biggest win?
Colleen
I would say my biggest win to date, especially around building strong teams, has been the team we’ve pulled together at Pro Kanban.
Very early in the process we were working closely with an advisor from Scrum.org, and he said very early in the process, “You have a diversity problem forming here. It’s going to be a lot harder to fix it when you have four hundred trainers than when you have forty.”
So we pulled together and created a scholarship program for women in kanban.
We’ve run three cohorts of that so far and it’s been an amazing experience not just for the women that go through, but for us, teaching and getting to help mentor and help them build this other career path for themselves has been incredible to watch and support.
We’re about to launch our first entirely Spanish-speaking cohort, that’ll start in December (2023) here.
Those kind of things are really powerful, not just from how it looks on paper.
Sure, it’s great. We have more women, more diversity in our trainer community.
But when we first set out to build Pro Kanban, one of the things we were really trying to do was kind of chip away at the old guard a little bit.
In the Agile community we have a tendency to, there’s certain voices we hear from all the time.
It’s the same speakers, it’s the same writers, it’s the same authors.
If we really genuinely want to build a strong learning community, that means also learning from the people that are new, not just the people that have been doing this a long time.
I’m really excited because what we’ve built here is, maybe it’s a big team, we’ve got over one hundred trainers now, but we have people all over the world coming together on these Slack conversations to talk about things like this.
“How do I bring change to my leadership team?” Or, “How do I convince a team to try WIP limits?”
You’re hearing from people who’ve been coaching kanban for twenty years or part of the original kanban teams, and you’re also hearing from people who are brand new to their roles, what’s worked and not worked for them.
That’s a pretty incredible place to be.
I’m proud that we’ve been able to create space for so many different voices and perspectives.
Michael
That’s fabulous that you have that environment to participate and also learn from.
Colleen
I love it.
Michael
This has been a great conversation today, Colleen. What else should I ask you?
Colleen
When we’re thinking about teams, a question I would always ask is, “Is our team actually a team, or is our team a team because of the org chart?”
I’m seeing this get challenged more and more and it makes me really happy.
I was just part of a kanban training course for a security org where we were trying to map out the activities that work went through.
A request comes in, what steps does it go through?
By the end of this session, we had all three teams back in the room going, “I guess it goes from me to this team to that team. Maybe we’re just one big team, maybe we’re not three small teams.”
We have a tendency to be so rigid in what we consider a team based off of the org chart or based off siloed roles and specialties instead of taking a step back and thinking about how we deliver value together.
I’ve been seeing a lot of chatter about that in LinkedIn lately, and it makes me really happy because it’s challenging us to think about how we work together in a different way.
Michael
On the “how” and not the infrastructure or org chart.
Colleen
Yeah.
Michael
For people who would like to learn more about kanban and bringing change effectively and everything else we talked about today, what’s the best way for them to connect with you?
Colleen
I am probably the easiest to find in the Pro Kanban Slack channel.
Anyone can join the Slack community. There is a link to join at prokanban.org under the “About Us” tab.
And that community is a thousand plus and growing strong.
If you’re interested in joining there or reaching out to me there, that’s a great place to start.
I’m also available on LinkedIn.
I am on Twitter. I’m probably a little less active than I used to be for lots of reasons, but probably the most active on LinkedIn these days.
Michael
You have a YouTube channel as well, correct?
Colleen
We do. We have a YouTube channel for Pro Kanban with a few different threads there.
There’s a playlist with videos about the Kanban Guide and getting familiar with the Kanban Guide.
And then we do a monthly series called Kanban For Everyone.
There’s some really great, probably my favorite one that’s out there, if I’m allowed to pick a favorite, is there’s a interview we did last year with folks who are applying kanban for nonprofits, I think the title of it is Kanban for NGOs. Really fascinating interview with Marcus Hammerberg and Steve Bell about the work that they’ve done using kanban really out in the field to help nonprofits who are strapped for money, strapped for resources, and still have a lot of work to get done, help manage how they’re delivering.
That’s a really great episode.
We talk about kanban application across a variety of industries, also kanban application inside of other practices like Scrum and SAFE.
You can check out our interview series there and subscribe for future episodes.
Michael
Sounds great. And I’ll have all those links in the show notes.
Colleen
Awesome.
Michael
What would you like to leave our audience with today?
Colleen
The big thing in my mind is thinking about respect for people.
Understanding where your teammates are coming from, whatever that looks like, if it’s giving them space, not starting new work, but really, there’s people behind everything we do.
Even though I’m kind of a data nerd, there’s people doing this work.
Especially right now, when a lot of organizations are making cuts, stress is high, the workload is probably the same, and there’s fewer people to get it done, everybody’s feeling that pressure and that pain.
Respecting our peers becomes an even bigger value proposition to make sure that we’re all working together.
Michael
100%.
Thank you, Colleen, for being with us today.
Colleen
Thanks for having me.
Michael
And thank you audience for joining us today.
Please let Colleen and I know: how is kanban and whatever other methodologies you’re using working for you? Where are they falling down? How can we help you make them better? We want to know.
Thanks, and have a great day.
Thanks for joining us on Uncommon Leadership today.
If you found these stories interesting, inspiring, and illuminating, sign up for my newsletter.
Use the form at the top of this page.
You’ll be the first to know about every new episode of Uncommon Leadership.
You’ll also discover how you can build uncommon teams.
Thanks so much!