my approach to agile
I believe agile stuff fails in large companies when managers cannot get out of the team's way.
I care less about agile frameworks and more about working software. Too many frameworks exist to support the manufactured complexity of project and programme management, which is often un-agile by design and risks your company being blockbustered.
I iterate quickly and measure progress by what matters: working software. It is cheaper to readily accept changes than to go down the rabbit hole of rigid and "complete" specifications.
I need to be able to deploy on demand. Fast, low-risk deployments are the best way to de-risk software development. If we don't have the tooling to enable this, we need to get it.
I require the team to own the product. I believe the roadmap should be made up of goals to achieve, not features to build. Experimentation is how we bridge the gap.
I need small teams with subject matter expertise, competent developers, and will allow them to speak directly with users. The fewer people between the developers and the users, the better.
I recognise that there exist jobs that are incompatible with agile. I think the industry at large could better acknowledge this.
The most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. - Don Wells, ExtremeProgramming