A small break from my Software Quality series... In Agile Land I work with companies implementing Agile for their software development practices. Invariably they run into the problem that for software development to be agile, a lot of the surrounding enterprise needs to adapt as well.
A lot has been written about how to implement Agile in development as well as the broader enterprise.
Some people advocate the use of an Agile Pilot team. Take one of the Software Development teams, move them over to Scrum and start documenting the improvements. This team can then be "champions" and tell the rest of the organisation about Scrum (/Agile). The advantage is that it's a pretty non-invasive start. It gets the improvements going (the impediments this team experiences will likely be shared with other teams in the organisation) and sets up a hype. The disadvantage is that this team will run into the problem that no other team is doing anything Agile so external dependencies will have a bigger impact and the delivery of Product Backlog will be more difficult as well. This method also won't address the bigger issue here: The organisation and the processes in place. It won't alleviate the challenges of the platform-focussed teams nor the problems of Application Management. If you want to go bottom-up then this certainly is an option but beware that this pilot team is the easiest step you'll encounter in the process and only after all teams have gone Agile will you run into the real problems of shaping the organisation.
Some people advocate the "Big Bang Bottom Up" approach where you stop all current development and start running Scrum in all teams immediately. The idea is to run into all implementation problems immediately, basically stopping software development for a couple of weeks whilst people adapt to the new reality. It's faster than the Pilot team method but also a lot more invasive. The big advantage is that you immediately make the organisational issues explicit as well. Any user base will likely start complaining immediately but if you can afford that then this approach will give you a quicker insight into the organisational impediments you need to solve.
Then there's the "stealth" approach: Start introducing Agile practices without moving to Scrum immediately. Just start by setting up Visual Management and doing daily standups. Then start building your requirements as user stories to support visual management, then introduce timeboxes. This has the advantage of not needing the word "Agile" from the getgo, thus staying out of the way of the nay-sayers. The impact of the buzzword cannot be underestimated. The times I have heard "Oh, so you do 'Agile' ey? Just like those people that messed up our previous project" are uncountable and frustrating. You can build on the basis of existing trust and take the entire organisation on a trip through Agile practices. Introducing retrospectives will most likely have the most profound effect as this will allow the teams to select which practices to implement next.
In the end everything depends on the organisation you're in. Just as every person is different, every team is different so too is every organisation different. A strongly IT centered organisation will do best with a bottom-up implementation (whether pilotted or big-bang), a strongly user centered organisation may do better with the "stealth" approach.
If you want to know what would be the best approach for your organisation you can, of course, always contact me.