However, the testers and UI people are part of pools of people. The organization calls these testers and UI people, “shared services.”
Shared service-thinking denies the reality of effective product development:
A cross-functional team learns together as they develop the product.
Without that cross-functional team, the people, product, and organization suffer in various ways:
- Neither the testers nor the UI people ever learn everything they need to about a product.
- The developers don’t realize what the testers or UI people need to be effective.
- Everyone waits for other people. Developers wait for UI people. The testers—when they finally get to work on the product—wait for developers to respond to their questions.
- The customers wait for something useful.
- The organization wonders why no one can “meet” a deadline.
The organization lives with many delays when the managers choose a shared services model. (That’s because the managers think resource efficiency works. They don’t realize how much more effective flow efficiency is.)
They think they’re saving money with a pool of testers and a pool of UI people. They’re wasting time, which costs much more than the salary costs.
Agile approaches break the idea of a “shared service” model of people.
Before I recommend alternatives, let me examine why well-meaning managers thought “shared services” worked.
Why Managers Thought Shared Services Worked
Remember the serial lifecycle, with just one deliverable at the end of the project?
Managers thought serial lifecycles worked. Even though the managers had this data:
- Many phase-gate lifecycles allowed slippery phases. A team could move past analysis, into design, and even into coding without finishing the previous phase.
- Even when the developers said they were “done” with the previous project, some developers “stayed behind” to work with the testers to finish fixing the problems.
- Projects weren’t “done” when the team said they were done. Sometimes, there were so many problems, that the entire team—developers and testers and anyone else they needed—to finish fixing the problems.
The managers did not calculate their Cost of Delay. They didn’t measure any item or project’s value stream.
The managers only looked at salary expenses.
If you look at salary costs, “shared services” looks like a terrific way to save money. “Shared services” is an example of resource efficiency thinking looking like it saves money.
However, because the flow of work takes so long, we are much less effective and the product development is much more costly. We are less effective—and less efficient.
I don’t know of any way to keep “shared services” and move to agile approaches. However, I know of several effective alternatives to “shared services.”
Effective Alternatives to “Shared Services” Thinking
My options to “shared services” thinking:
- Create cross-functional teams that work on one product at a time. You might need larger teams than I normally recommend (4-6 people). Whatever you do, create the team for the product.
- Keep teams on their single product for three months, minimum. Why three months? So people learn how to work together and so everyone learns the insides of the product.
- Reduce the organization’s WIP (Work in Progress) by managing the project portfolio. (See Manage Your Project Portfolio.)
When you take these actions, you’ll see several effects:
- People will be much more engaged.
- The team might be able to predict when they can deliver.
- You will have an easier time managing the project portfolio.
- You might not see this in the first quarter, but eventually, the cost to develop and maintain your products will decrease.
Yes, when you change your management, you will see better flow efficiency.
What if someone wants to keep “shared services?”
Don’t use an agile approach.
However, I don’t recommend anyone use a “shared services” approach for any product development. You might be able to use “shared services” in a service-oriented workgroup. Don’t use it for product development.
What’s my potential client doing? Thinking. And measuring their various value streams. (See Creating Time for Collaboration for a value stream map that might be similar to a “shared services” map.)
“Shared Services” doesn’t work for any agile approach. It doesn’t work for product development. In any culture or lifecycle.
Want to read more about why “shared services” don’t do what you want? Read Practical Ways to Lead an Innovative Organization.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Why Shared Services “Teams” Don’t Work with Agility Opinions expressed by Java Code Geeks contributors are their own. |
