Have you ever worked on a project where the management and/or sponsors felt it necessary to provide you warnings: “This release better do this or have that. Otherwise, you’re toast.”
I have, once. That’s when I started to use release criteria and check with the sponsors/management to make sure they agreed.
I happen to like release criteria. Even better is when you use agile on your projects. You might get feedback before the release. Here’s what a client did on a recent project:
- They had release criteria and the sponsors agreed to the criteria.
- They released internally every two weeks and asked people to come to the demos.
- They asked the product managers and product owners to review the finished work and to make sure the managers/sponsors liked where the roadmap was going.
- The team worked in ways that promoted technical excellence, so they could (relatively) easily change the code base when people changed their minds.
The project didn’t fulfill all the wishes that managers and sponsors wanted. Those folks wanted the proverbial 15 pounds of project into a 5 pound bag. On the other hand, the team is on the verge of delivering a terrific product. (They have one more week to finish.) They are all proud of their effort and the way they’ve worked.
This morning, the project manager emailed me. “I’m so angry I could spit,” she said. “One of our sponsors, who couldn’t be bothered to see any demos just told me that if he doesn’t like it, he’s going to send us back to the drawing board. Do you have time for a quick call so I don’t get myself fired?”
This is a culture clash between the agile project’s transparency and request for frequent feedback vs. the controlling desires of management.
We spoke. She realized it was a difference in expectations and culture that will take a while to go away. There are probably reasons for it, and that doesn’t make it any easier for the team.
These kinds of situations are why I recommend new agile teams have a servant leader. I don’t care if you call that person an agile project manager or some other term, but the person’s role is to run interference between the two cultures.
The worst part? With the project’s transparency and interim delivery of value, no one needed to warn anyone about anything. The data this guy was looking for was in the demos, in the meeting minutes and was easily accessible.
I don’t know why people think they need to provide dire warnings. It’s not clear what effect they want to create. Dire warnings make even less sense when the team uses agile and provides interim value and demos.
If you’re using agile approaches, and you see this happening, decide what you want from this relationship. If you think you’ll have to work with this person again and again, it might make sense to have a conversation and see what they really want. What are their concerns? What are their pressures? Can you help them with information at other times instead of a week before the end of the project?
Don’t be surprised if you see this kind of a culture clash in your organization as teams start their transformation. Managers have a lot to do with culture (you might say they are the holders of the culture) and we’re asking them to use different measurements and act differently. A huge change. (Yes, after the agile project book, I’m writing an agile management book. I know, you’re not surprised.)
| Reference: | With Agile, No Warnings Needed from our JCG partner Johanna Rothman at the Managing Product Development blog. |
