How on earth do you go from every developer 110% loaded, 3 or 4 projects each and each person wearing analyst, architect, developer, test writer and project leader hats to the 20% slack, 1 project each and proper role allocation when management are tearing down the door with the next Big Thing that's going to make the company money every other day?
Now I realise that an answer many practitioners would give would be:
"Get management buy-in"
Great, that seems like good advice, but those of us that aren't on a beautifully functioning Agile team know that when we suggest a change in working practices that the answer's going to be:
"Fine, we can do that when we've finished project X"
Of course, project Y comes along long before X is finished. X 1.0 is rubbish anyway and needs an X 1.0.1 service release, backwards compatibility of X with W rears its ugly head, project Z is already in the marketing pipe (and if you're unlucky, it's already been sold).
It seems that there are quite a few things that may have to happen that are - in the short to medium term at least - extremely incompatible with business needs:
- New projects cannot be started. This is terrible news for a company that is scraping by: new products and new releases of existing products are needed to continue to drive sales and a gap in product production means depriving the sales team of oxygen.
- Fewer projects can be executed. See 1, the sales team turns blue.
- More people are needed. Team members wearing multiple hats is not good, so more roles need to be created if the project workload is to remain high.
- Project management has to be improved. Money has to be spent on training and/or coaching.
- Development teams need to be shielded from sales and management pressures. This is a perceived problem when management feels the need to control development excessively in order to get anything out of them (and lets face it, they will view a development team operating in a manner as described above as extremely under-productive).
- People have to change. The most important thing about being Lean/Agile is its culture, without which a conducive environment can never be created, only simulated in short bursts as the business can afford the spare time, resources and money to do so.
Are there any answers? Perhaps one option is to transition one team. This is probably attractive to management, as it is only a toe in the water and they can pull the plug and go back to the old methods should it fail. The challenge here is likely to be providing the right leadership such that the team is properly shielded from existing external pressures. Additionally, if everyone's working on multiple projects, you can't do this overnight: you probably have to live with people being on many teams to start with and that slowly coming right over time.
What answers do we have to curry favour with management? Of course, we can promise them more productivity in future, but maybe we have to stick our necks out and offer them more productivity right now. If we can start showing management a clear advantage in Lean/Agile practices such as visual control, a clear value stream, better schedule estimation and so on, perhaps this would be sufficient to show greater productivity long before a project is finished.
All of this is of course dependent on changing that key person's mind. Depending on who they are (and who you are), this can be extremely challenging. They have to trust you, so that when you say you can improve things, they'll be confident enough to let you go against history and try it. How can you gain this trust in your abilities to pull off something as managerially and technically challenging as Lean or Agile? Maybe you have to go ahead and do Just Do It(TM) (see Fearless Change) and prove that you can with evidence that you just did.