I’m having the proverbial awake-in-the-middle-of-the-night and worrying-about-work-tomorrow kind of night.
These days I’m working with the team in trouble. They seem on the verge of giving up and are very discouraged. I’m worried for them and for the organization. Over the weekend my monkey mind has been cavorting to various places from which I could sneakily try to make them do things my way. Or at least the way that the CIO and CEO want, which is to simplify, come with a clear position and take a stand, at least for the February release.
There’s only one small problem. The confidence of this team is currently undermined. They’re not willing to take a stand because they felt they stuck their neck out in demos for the last six months, didn’t get the kind of feedback they needed, and now they’re feeling burned.
What’s more, their director quit last week and five days after that the lead developer quit. And now I’m supposed to coach and manage this team. What do they think I am? A miracle worker? I feel pressure, but it’s pressure I’m putting on myself. I do worry that they think I can save this team, save the product, save the company, save the world. But in my lucid moments, I realize that’s crazy.
The thing I have forgotten, and I’m just now trying to remember, is that the team is already naturally creative and resourceful. Sure, they’re feeling really disappointed their leader quit, and they are not sure how willing they are to keep trying. But now that I think of it, that seems like a normal reaction to the situation.
So if I put on my Agile Coach hat, and get curious about the land this team has been living in, I realize a couple things. One, they had a director who was also trying to play the roles of product owner and scrum master at the same time. That in itself is a recipe for failure, because one thing that’s inherent in each of these roles is they negotiate with each other. And you can’t negotiate with yourself.
Or at least, you can’t do it very successfully, like, “I think I’ll have some ice cream.” “No, you can’t, you’re trying to lose weight.” “How about if I have just one spoonful?” “No, you said you wouldn’t do that.” “Okay, how about half a spoonful?” “Well, that seems okay – go for it.” Not good, right?
The other thing that’s been happening is that even though the who director quit is a really nice guy, the mode of leadership he brought was command-and-control and very hard driving. I think that’s all he knew. Heck, that’s all I knew, up to about 15 years ago when I led major organizational change initiatives that failed, and then got curious about more effective approaches.
So one unintended consequence of the command-and-control leadership style was that he, not they, set dates and scope and quality, efficiently breaking both the rules of scrum and the magic triangle of time, cost, quality, scope.
And we all know what comes next. The same tired story. You got it – the team ended up working 70 and 80 hours a week. They trooped into the demo every two weeks, haggard, with circles under their eyes. They showed what they developed to a senior leadership team who was either catching up on email, tweeting or in other ways not paying attention, or else paying attention, but trying to give them the space and independence to find their own way.
One thing is clear. The team was not getting the feedback loop they needed in order to adapt. They told me they felt like they went into the demo and just tried to look good, play it safe, and be right.
And now they’ve just had it. And here I am in the middle of the night on Sunday, wondering how Monday is going to go. For my first two weeks with the team, we took a step back, did a scrum reset, then established and met with some focus groups of users to get prototype feedback.
This seemed like a good idea initially, as many ideas do. And of course what we found is that the various customers and the various focus groups all wanted different things. So as product owner I distilled these into stories and rough prioritization.
But when we got to Sprint planning we got clear that we could not do Sprint planning. Why ever not? Because this is a business intelligence team, presenting dashboards and charts. And the one common thing that everybody in the focus groups told the team is that the prototype charts are confusing, unclear, and don’t help them do their jobs or meet their business needs.
By now, as you can imagine, the team is feeling even more burned. They didn’t get the agile leadership they deserved because the company didn’t know what it didn’t know about agile and I was too busy elsewhere with other teams to spend any time with them until I was asked to come in and help.
Yet the agile coach cannot be forever in a savior mode, or even any of the time really if she wants to deliver coaching that results in something sustainable. The truth is, this team really does have the natural intelligence and resources it needs to succeed. But it also has a right to be supported by effective leadership. And what I personally stand for as a leader is dignity, growth, and freedom. So to me, working 70 to 80 hours a week does not honor those values. That’s my guidepost. But I divert.
So what happened? Not only is the team burned out, but now they are feeling overwhelmed by user feedback that what they produced is confusing and not useful. So we held a sprint retrospective that was a “come to Jesus” meeting mixed with a “tell the hard truth meeting.” In the hard truth that got told is that the team is not ready or willing to dive back in yet. And that there are certain specific things they need to be successful. In other words, they’re starting to stand up for themselves. They’re starting to exercise their natural resilience and creativity. They decided to make a list of what they need to be successful and were presenting that tomorrow to Ted, the CIO. I also proposed wireframes, and once they talk this through, they got mad. That seemed encouraging – a sign of life. It seems better to me to be mad then to just lay down and give up.
And what they were mad about is that once they understood and agile lean approach to product development, using wireframes in very light weight bill – measure – learn cycles, they realized that they should’ve been doing this for the past six months. And they realized that they should’ve had a product owner doing this for them, except now they’re mad, because they’re trying to do this themselves and they feel like it’s a day late and a dollar short.
And here I am at 2 AM on Monday morning trying to figure out how to help them. Specifically, not to help them as a savior because that never helps anybody in the long run, but instead, to help them as a servant leader who believes in them, and simultaneously holds the space that is both safe and courageous for them to recover their best game.
So I’m going into our scrum tomorrow with two ideas. My first idea is to do and agile coaching process with them called “High Dream, Low Dream.” It’s where you ask the team around a certain topic, like producing a wireframe is a straw man to be knocked down and revised, what your high dream around this? What’s the best thing that could happen? What’s your best hope for this? And what are the resources that will support this high dream? And then it’s to ask them, what’s your low dream? What are you afraid might happen instead? No doubt there will be plenty of answers to this one. And what are the variables in the situation that you think might make this low dream come true? And then in this exercise, you go back to the high dream, and you ask them, what are the resources or variables in this situation that could really make this high dream come true? How much do you want it? How close are you today to that high dream on a square scale of 1 to 10? How close do you want to be by tomorrow when we meet with the CIO to show him the top 3 to 5 screens we are proposing?
And that’s why I’m awake right now instead of asleep. Because I don’t know how it’s going to go. And I want it to go well for the team and for the company and for the CIO and, well for everybody. But the thing I keep forgetting, and the reason I’m not asleep right now, is that I’m falling prey to an illusion that things are under my control. And they’re really not.
And that’s good news. Because geez, if things were under my control and only up to me, then everybody would miss out on the contributions of the team because I would be narrow-mindedly micromanaging folks. I stopped doing that 15 years ago but I think my brain sometimes returns to it in moments of worry like this for I’m worried about the team and worried about the company.
But the thing I keep coming back to is that the more I try to manage and control, the less freed up the natural talents and abilities are of the team and the company. They deserve better from me as a leader, and taught and I’m totally up for giving them that something better. It’s my leadership as a servant leader, as one who actually has confidence in them and their ability to come together and beat this challenge. If I turn their success over to them, and put it into their hands, not mine, they get the dignity of owning it. And that feels right. They get the dignity of being a choice. And that also feels very right.
The second thing I’m going to try tomorrow is another team coaching protocol called meta-skills. A meta-skill in team coaching is the perfume you spray into a room or the spell you cast. It’s taking a particular perspective, like a perspective of courage, curiosity, inquiry, or even “bad-assery,” and using those perspectives as a guide for what you do. So since I couldn’t sleep anyway, I spent some time here at two in the morning coming up with several possible meta-skills that the team might want to step into. Those meta-skills are, focus, simplicity, coming with the position, playing it safe, taking a stand, collaboration/partnership, ownership and other.
The way the protocol works for this team coaching experience is that you lay out these meta-skills in a wheel. If people are in the same location, it works well to lay them out on the floor, and use duct tape on the floor to make a bunch of wedges, like pie wedges. Then you ask the team members to walk the wheel and consider which meta-skill they want to stand in to address the topic. In our case, the topic is bringing a straw man to the CIO by Tuesday showing the team recommendations for the top 3 to 5 screens. At least this is the request from the CIO, and the team has said it’s feeling burned and not sure if it’s willing to step up to that request. So we’ll see how that goes.
In any case, if team members are remote, this is still very do-able. Just find a remote collaboration tool like bridge space or twiddle a, draw a little pie chart with shapes and wedges, and park each meta-skill inside the wedges. Choose a tool that allows team members to edit and draw at the same time, so they can drag their dots or make their initials in the pie wedge with the meta-skill that resonates the most with them. This is going to be the meta-skill they feel they want to step into, the perfume they want to spray into the room so to speak when they are addressing the topic – in our case, producing business intelligence wireframes that are simple, clear, business focused, and help real users with real jobs.
There is an art and a science both to agile coaching, I’ve noticed. And now that I’ve thought this through, the art part of it is letting go. That means it’s time for me to stop writing this blog, remember the team is naturally creative and resourceful, let it go, take a deep breath, and go back to sleep. Letting go, to let come.
