Agile Bewares (1)
More and more teams and organisations are moving to agile. Interestingly I keep hearing similar statements that ring alarm bells in my mind. I thought I'd mention a couple of statements to beware about. This will probably become a growing list, so I'll call this part 1.

• we're agile inside development but still run the traditional process toward the rest of the organisation

That probably means budget, milestones and feature are fixed. In my experience, that leaves little room for agile, except for what I call "agile in the small", e.g. pair programming, test-driven development in the scope of unit testing (assuming internal milestones such as code-ready accomodate this). Probably, customer/product management won't (want to) be involved, so requirements won't be prioritized and thus the most important things might not get done first. You'd probably want to query why they want to run an agile process, what benefits they are expecting and make sure everyone has the same understanding of the process.

• scrum teams are component-teams

Compared to cross-functional teams that means you lose the advantage of direct communication between those implementing a user story (feature?) and also the better resource usage of cross-functional teams. Why is the resource usage better for the latter? Because component team members only work on their own components and thus can't help put in other areas. Cross-functional teams work on features or user stories and thus learn about all the layers and components necessary to complete their user story. On a similar line that's why you need to ensure user stories or features are customer centric and not defined like this "the database access layer needs to support CRUD operations for xyz data". Otherwise your feature team will again be working on a single component. Having cross-functional teams also enables the interfaces between the components to be defined, implemented and tested within one team, avoiding the frequent communication gap across interfaces.

• we adapted this recommendation because it won't work for us

While being agile also means adapting your development process, there is the risk that teams new to the agile process adapt recomendations because they don't understand them or because they think they don't work or maybe just because it sounds like too much work. There is a real danger to leave out all the bits people don't like to do (like regression testing, documentation) which is not necessarily being agile. Another reason why recommendations are not followed is because agile is used first time in critical projects (and that itself goes against recommendations!). And then people are afraid of anything that sounds unfamiliar and afraid of failure.

My recommendation is to try out those best practises on an uncritical project first before deciding what will work for you and what will not.

• With agile development can relax from all that planning and administrative stuff and focus on the important bits

Well, in my experience XP and also scrum require more discipline. Its just the responsibility is on the teams. For example, agile places a lot of emphasis on automation, e.g. automatic testing and also on metrics, e.g. code coverage, iteration and release plans (sprint backlogs), burn down charts, velocity tracking. Or look at planning: the product owner needs to prioritize all the user stories, stories need to be estimated based on velocity, they need to be broken down into small stories and even smaller tasks. Each needs to be tracked. Remember all those charts? Then there's all that CM stuff to sort out. CM is more complicated with everyone being able to change anyones code!