Agile Ways of Working
A quick summary...
22 March 2018
Totally fucking nicked from GDS, but had to provide a bullet-point round-up for a TL;DR at work, and thought this worked.
As an aside, I never really understood why agile was needed, as it seemed like an additional layer of complexity for software projects until I came to a large organisation and saw all the many gloriously dysfunctional legacy ways of delivering things. Hoo boy.
Still, like anything else, when something becomes dogma or the status quo, it’s always worth interrogating and not just blindly accepting as ‘the way things are done here.’
I also had a quote from a colleague of mine around how and why we work the way we do, and I’ve pinched a line from that here (thanks Kim):
We work collaboratively in short iterations. We value working software over comprehensive documentation and expect that we don’t know all the answers up front.
Obviously, a great debt here is owed to The Agile Manifesto.
Agile Ways of Working
- Focus on user needs
- Identify the users of a service and what their needs are
- Putting users first takes primacy over the needs of stakeholders
- Deliver iteratively
- Build things that focus on user needs
- Gather feedback
- Iterate before moving onto the next prioritised user need
- Emphasise short feedback loops
- Keep improving how your team works
- Improvements in the team will be reflected in improvements in the service
- Discover blockers and remove them
- Use techniques such as standups and retros to keep processes and issues visible
- Fail fast and learn quickly
- Learn to fail and learn from failures
- The scale of failure can be mitigated with processes such as
- Active stakeholder management
- Test-driven development, automated testing, continuous integration and delivery
- Monitoring key metrics
- Release regularly; this
- Improves quality
- Improves visibility
- Reduces cost
- Keep planning
- Continuously plan, and revise these plans based on:
- New data
- Usage patterns
- New requirements
- Your progress