Johanna Rothman writes that organization-wide standards don’t help if management imposes them. If people ask for help with standards, then you can provide local help to each team. And if the teams are part of a program where you have one business objective common to multiple projects, make sure the program understands the problem.
“OK, I’m really glad we can start this management meeting now. It’s time to talk about standardization. I want to create standards for our projects. I want to standardize on agile for all of our projects.” Joseph, the CIO, thought all of his directors would be pleased.
“Uh, Joseph, are you telling us you want us to go ‘all in’ on agile right now?” Cathy, the QA director, sounded concerned.
“Sure. Why not?”
“Well, we haven’t finished our pilot project, for one reason, and we don’t have enough money budgeted for training,” Dave, the development director, said. “And while I think agile is a great way to go for many projects, our business counterparts have to think so, too. We need to bring them with us. Right now, they’re still thinking in six-month chunks. You can’t standardize on agile without changing how they think.
“Why do you care how we deliver, anyway, as long as we deliver effectively? Our job is to solve problems. Your job is to make sure we are solving the right problems. If you decide which problems we solve by managing the project portfolio, we will decide how to solve the problems.
“What if we decide that we need to prototype some architecture for a while to reduce technical risk? Are you going to have my head?”
Joseph looked at Dave for a minute, then said, “No, I’m not. But I thought you liked agile.”
“I do. But the developers and I don’t quite understand refactoring to patterns at the architecture scale. We’re working at it. That’s the same way that Cathy and her team don’t always understand how to create tests and refactor to test automation all in one iteration, right?”
“Transitioning to agile—or any one other approach—isn’t a slam dunk just because you declare it,” Dave continued. “It’s a change.
“And why should we use just one approach? Why shouldn’t we iterate on architectures or designs for a while if we want? What’s wrong with that? And what about trying kanban instead of iterations? Why can’t we do that? Why do we have to standardize on anything? Why can’t we experiment and see the results of our experiments?
“I feel as if we are finally getting out of the yoke of waterfall. I don’t want to be back in the yoke of something I don’t understand. You hired me because I can think. I hired people because they can think. So did everyone else in this room. It’s time we let them think about how they do their work, not just what they do.
“I say forget standardization. Our projects are different from each other. Why should we use the same approach on each project?
“Let’s tell people the results we want and use timeboxes to make sure we get the results in a reasonable amount of time. Why do we have to do more than that?”
Joseph leaned back in his chair. “OK, as long as you reflect on your experiments and fix them when they go wrong, you have a deal.”
Standards Provide Senior Managers a False Sense of Security
When you have a “standard” approach to projects or anything else in your organization, your managers feel as if they have a sense of security. It’s a false sense, but it is there.
They use that idea of a standard as an assumption that the work will proceed smoothly. How often does that happen? Not often enough!
You can standardize work on an assembly line and make the work safer and more efficient. But knowledge work? When you standardize knowledge work, you run the risk of making the work boring, less efficient, and not oriented to the real goal of your project.
Knowledge work is unique and encapsulates its own learning. It’s why each project should design its own approach, whether it starts off as waterfall, iterative, incremental, agile, or some combination. There is no one right way to do all projects. Each project team has to decide how and what to do for its own project.