The longer a manager has been away from technical work, the less the manager still knows the technical details. And—as we all know—for software, the details matter. If you have a manager who insinuates himself into your work, ask that manager what he wants. As long as managers trust in their project teams, and as long as those project teams work to earn trust, both sides can work together.
Sally, the project manager, strode confidently into her meeting with John, the CIO. She’d reviewed the roadmap with the product owner and had discussed the risks with the project team. She was sure, based on the first few iterations, that the project was off to a good start. Sure, she knew that projects rarely stayed on course, but this project had a chance of making the dates. The product owner knew how to work the backlog, the team knew how to get to done each iteration, the architect was embedded into the team—this project was cooking! She was happy. As much as she could project into the future—which wasn’t far—this project was going well.
“Hi John. What did you want?” Sally said as she sat down in John’s visitor chair.
“I want you to cut 20 percent off the date for this project.” John replied as he pointed to the final release in the roadmap.
“Well, that’s no problem. We’re agile. You won’t get the last 20 percent of the iterations, so you won’t get the last x percent of the features, but that’s okay.”
“No, you don’t understand. Things shouldn’t take this long to do.”
Sally frowned and said, “I don’t understand. What do you mean, ‘Things shouldn’t take this long to do.’ Do you think people are slacking off? Do you think we are not working hard? What problem are you trying to solve?”
John sighed. “When I was a developer on this system, it didn’t take two months to add a feature like this,” he said as he pointed to the roadmap and to a specific feature. “It shouldn’t take that long. In fact, I added something like that back in the day.”
Sally almost swallowed her tongue. She didn’t want to try to explain that the team had spent almost a week and pulled all of John’s code out for just that feature, because it didn’t work and was unmaintainable.
He continued, “I wrote that code overnight. I know what it takes to write code for this system. It doesn’t take two weeks!”
“John, when we write code now, we write unit tests along with the code. In fact, we write the tests first. We find that when we do that, it helps our design.”
John interrupted Sally. “Well, it makes everything take too long. Stop doing that.”
“No,” countered Sally.
“What do you mean, ‘No.’ I’m your boss,” John said. “What I say goes.”
“Not when you say something that doesn’t get you what you really want,” said Sally. “Look, what you want is to finish this project faster, so you can start the next project, right?”
“Right,” John replied.
“Okay, so you can stop an agile project whenever you want, because we always get to done at the end of an iteration. No problem,” Sally explained. “We have tests so we know the code works. We have releases on the roadmap, and if you want to release before or after a ‘real’ release, we can do that, too. But my job as an agile project manager is to ensure that the team gets to practice their professionalism. I serve the team. I also serve you, but the way I serve you is by facilitating the team. So, no, I’m not going to help you get something you don’t really want. Remember when we tried to make waterfall work, and you used to try to cut 20 percent off the end of every project schedule?”
John leaned back and smiled. “Yes, that worked.”