Today (27 Dec '07), Ash Tengshe [atengshe at yahoo com], an ex-ThoughtWorker now with Capital One Auto Finance, US, came down to the ThoughtWorks Pune office to give a talk on "Establishing the Agile PMO; Managing Variability across Projects and Portfolios".
It was a nice talk about his experiences of introducing Agile into a division in Capital One via the PMO route. Ash had presented this session at the Agile 2007 conference too. You can find an abstract here.
The key observations I took away from the discussions are these:
- It's good to have a CIO or CTO who believes in Agile... you can always do with some support from C-level executives (this is based on my own experience too)
- If teams themselves adopt Agile but face resistance from upper management, they might get demotivated and drop the idea... Agile is difficult if you have the PMO breathing down your neck fearing break of "compliance" all the time
- If Agile is driven by the PMO itself, it'll actually have the opposite effect: yes, you'd need to tailor certain things about how the PMO works though, and cut down on "waste" where compliance is concerned... but yes, Agile can be compliant with things that make sense or which cannot be gotten around with (like legal issues)... such compliance requirements can simply be treated as task cards that the team has to schedule into their backlogs along with stories
- Middle management like Project Managers, QA Managers, etc might feel threatened if their roles become unnecessary with an Agile team (because of cutting down of "approval" stages): they need to adapt their roles in an Agile setting (for example, many PM's show interest in becoming Agile coaches or Scrum Masters, although it's not necessary that good PM's make good coaches)
- PM's usually prefer Agile because it reduces the amount of documentation needed; developers like it because of the free snacks (although they are initially resistant to leave cubicles and move to noisy bullpens or Agile dining tables)
- The PMO appreciates Agile as they now have a better hold on ROI which they can revisit release by release, and make informed start-stop decisions before it's too late. Also, tricky decisions like whether to start a new project instead taking a currently 80%-complete project to full completion can be made with better judgement depending on remaining ROI (although it might be a lil' difficult to get good numbers for remaining ROI). Such decisions would not be possible in the traditional waterfall method as you cannot say that the last 20% effort can be skipped because that last 20% effort would usually be the unavoidable testing or deployment of a mammoth system that has not been delivered at all so far (as opposed to incremental but fully-tested/deployed releases in Agile)
- As in most cases, customers end up more satisfied and time to market reduces; there is a very small percentage of customers, especially technical ones, who may not agree with the decisions of an empowered Agile team, like issues on estimates or design decisions
- When dealing with multiple internal customers running multiple projects on scarce resources (oops, I mean people!), people usually end up being 25% allocated here, x% allocated there, y% allocated some place else, and so on. This context-switching and not being part of a dedicated "team" hampers effectiveness and motivation: ramp-up takes more time, people on a project lack synergy, knowledge/experience build-up on the system is low. To deal with this, an approach taken was to have dedicated Agile teams working on particular base platforms, and requirements getting bucketed into these platforms. This got rid of the unpredictability of managing numerous projects simultaneously, not knowing when one project would end and when another could be taken up (very ad hoc). Now customers knew exactly when one cumulative release would end and when their requirement would be picked up. Also, to avoid having customers wait for an entire release to complete before their requirement was picked up, there are parallel tracks so scheduled that one release would end right at the middle of another parallel release. Hence requirements could be picked up by the team working on the release which is going to end sooner. The pitfall of the new approach, however, is that there have to be common backlogs with various customers owning it (getting one Product Owner to abstract that away helps to some extent). Metrics like velocity, burndown charts, etc also become difficult to manage for multiple customers being serviced in the same iteration/release by the same team. Each customer is interested only in what's relevant to them while the team's effort is actually distributed across many customers. Overall velocity starts making lesser sense in this respect. Still need a solution to this...
- Agile is spreading from client side to the offshore IT companies working for the company, and yielding good results so far. The IT service companies have to compromise on the revenue they used to earn from Change Request fees but are glad to have happier customers in lieu ("change request" concept is something that almost always leads to tension between clients and service providers). Distributed Agile as a practice is becoming maturer and well-proven.