Originally posted by GreyWolf
View Post
I just snipped number 4 above - that's not the reality of agile at all. Who told you this? I know a lot of people think this but it isn't true. This is a Scrum thing, not agile, but whatever... a product owner is perfectly entitled to negotiate (although he has the ultimate say) the ongoing sprint backlog at any time. In fact he can cancel the sprint entirely if he sees fit. The aim is to not have to do these things, but there is nothing to say that you cannot swap something out for a brand new story, mid-sprint, if it's deemed a priority.
I'm not sure it would make sense to label a process as being 'agile' when it's actually rigid and inflexible

If someone wants to train their team to embrace agility then they should start with software craftsmanship - quality code is the bedrock on which any agility must be built.
Automation - you can't be agile when change is too expensive. This fits in with the software craftsmanship. So perhaps teams might need some TDD tuition - then their code will not only evolve such that every line of code has a reason to live, but it will be fully xUnit tested. Then you can layer on some automation when it comes to acceptance level testing, etc. Then some automation when it comes to CI and the release process (some mature teams release several times per week).
At that point we can really get the testers pairing up with, or working closely with the devs on tasks. Perhaps the devs can build test fixtures for the testers who hopefully have some technical ability to build tests from them, while the developer is coding up the production code. This helps us to achieve agility because we don't end up with a load of tasks all coded up but in an indeterminate state because they haven't been system tested yet.
Then there's the agility when it comes to working closely with clients and drawing requirements out of them, etc. We don't mind that they might change their minds because we have awesome test coverage making any changes to existing code stress free. We embrace the idea that requirements will change, rather than throwing a tantrum like some people would in a more old-school environment, because ultimately the whole reason we're doing this is to deliver the client value.
THEN something like Scrum is the last layer to add. Getting a team to follow a Scrum methodology (which isn't 'Agile' - it's just a tool to help you work with agility) when they don't even understand what agility is, or why they might want agility, is like teaching someone to bake a cake without telling them what the ingredients are that they are using - they might get top marks, but the next cake they bake on their own is going to taste like tulip. What's worse is that the team will (which i'm observing now at clientCo) will end up jaded with the whole thing because it doesn't make sense to them.
Comment