This is something I was thinking about this morning. I’ve not done it as yet, but I think it might work.
One thing that seems to hinder and aggravate the introduction of agile methodologies into large enterprise companies is the resistance of various groups to the ideas behind agile and their unwillingness to work with it.
Typically agile is seen as a way for people to get around processes and approvals, to violate safety protocols, promote poor quality code and allow bugs and hacks to get into the production systems. Alternatively it can be seen as something for small lightweight, non-critical projects which do not require stringent controls. Therefore not enterprise. Even though this is wrong, it’s how things can be seen, so the non-agile teams resist.
The agile team on the other hand, are enthusiastic about the improvements that they see agile generating in their development and delivery and want to encourage everyone else to give it a try. But having now experienced a new way of thinking they find it hard to deal with other teams who are not interested in agile and/or view it negatively.
So a cultural class occurs when agile meets non-agile at the handover boundary and the non-agile teams start demanding, assurances, sign-offs, etc. Bringing the agile process to a screaming halt because they demand single gated approvals before doing anything.
Obviously something has to change. The idea I’ve got here is probably nothing new and I would not be surprised if someone has already written a book around it -
Do not pass “Go” unless you have engaged the non-agile teams. In other words, rather than putting off dealing with the non-agile teams, start talking to them straight away. Even before you start coding if possible. The reality is that people on these teams are usually not as stand-offish as you may think, and often they want to be talked to much earlier than you would expect. Engaging them early makes them feel important and gives them the ability to contribute. You will probably find that where previous they simply might refuse to budge on some issue and appear unhelpful, now they will help you work through it quickly and easily.
Turn restrictions into features - at a low level. Better yet, acceptance tests. So when talking to these groups, list out the things they they require, find out whats needed for each and list them as stories on the wall. This does several things, firstly it means that these teams can now see that you are scheduling their needs as part of your work. They like that.
Secondly, previously scary handover requirements become just another story. And thirdly, it’s likely that you will be able to satisfy those requirement earlier because they are now not only part of the agile process, but are also highly visible instead of turning up at the last minute.
Feedback as soon as possible. Now that non-agile requirements have become part of the process, when execute one of the stories, make sure you go back to to the non-agile team and tell them you have just done it. The idea is that instead of a big bang handover as they previously would expect. They find themselves being involved in the agile methodology, getting a steady stream of sign-offs as the project proceeds. Not only that, they now get the chance to look at the restrictions as smaller units and to help make improvements if needed.
So hopefully if this works, it should result in a relatively painless delivery where non-agile requirements are met quickly before their due dates and have a minimal impact on the development. An additional bonus is that non-agile teams now get some real low-pressure contact with agile. This should have them internally debating the differences between they way you have dealt with then and the way they would normally be dealt with and hopefully, starting to understand that agile can be a real benefit to everyone.