At Google, Ken Schwaber talked about Scrum and described Infrastructure (or Core) Software and the pain that it generates for an agile team. Infrastructure Software provides functionality that most other software depends on and must therefore integrate with. Typical problems are:
It's fragile because so many things are dependent on it. Change something in the infrastructure and some external, dependent software breaks.
It's brittle because it wasn't developed with sufficient automated tests. Change something in the infrastructure and something else in the infrastructure breaks.
There are only a few people left who know the code and are willing to work on it.
So, you're working in an agile team, hustling along at a sustainable pace. You can develop new functionality quickly, that is until you have a dependency on the infrastructure. Bang! There goes your velocity. Your productivity is completely throttled back by the velocity of the infrastructure team/s (assuming they need to write some code to support your new functionality). And their velocity is much less than yours because of the problems above.
Ken asked, where Infrastructure Software comes from? He determined that it was a result of teams coming under pressure to get more done, and habitually cutting quality and writing crap code (rather than saying 'No!We can only get this much done in an iteration'). This has knock-on effects during subsequent iterations, as they stop paying constant attention to design and technical excellence and end up building legacy out of the box. Voila! Infrastructure Software.
Another infrastructure problem relates to physical organisation, e.g. when companies centralise specific skills, such as operations or database administration, apparently to improve efficiency. Unnecessary external dependencies such as these will also throttle an agile team's velocity. This is not an effective way of working together to get things done and deliver business value. Build whole, cross-functional teams that include their own operations and database administration skills.
Because centralised teams, such as operations, are disconnected from say, product teams, and because they probably support many product teams, they cannot be expected to possess extensive domain knowledge or a detailed familiarity with each product. Therefore, to make centralised teams viable, organisations allow them to enforce standardisation. And, standardisation kills innovation. Bummer!
Previous Topic
