Even if you work for an old large traditional enterprise, it’s almost impossible now not to feel the influence of Agile and my advice is embrace it!
- creates / lays claim to a lot of great ideas. Some of these pre-dated it, but there is no harm at all getting them distilled all in one place
- is extremely popular and even mandated by many organisations.
- Mis-understood, mis-quoted, mis-interpreted, mis-used, spells TROUBLE.
Therefore, I highly recommend getting up to speed, for example by reading the manifesto. But don’t stop at that, there is huge amounts of great information out there in books and blogs to discover.
I would encourage some effort to learning the lingo. I don’t want to start ranting about how many times I’ve heard Agile terminology misquoted for defending some truly bad (non-Agile) practices (it’s many many times).
However, if you are starting out dabbling in Agile within an established organisation with entrenched processes my advice is to keep the following close to hand:
- What Agile has to say about how to do things (and what it calls things!)
- You common sense
- Your experiences
There really is no excuse for ignoring any of these (and believe me I’ve seen people do it time and time again).
In my head, there is a parallel to be drawn between a methodology like Agile and an Enterprise software package like SAP (stick with me). Both are powerful, both are capable of doing massive things, “out-of-the-box” neither will ever be as effective as they were when they were first created as bespoke solutions to the unique problems that prompted them. – The problem you are solving (whether with a software package or software delivery methodology) will always be unique, and hence so must be the solution
Based on what I’ve seen over the last 4-5 years here are key success factors when following Agile in a project-based scenario:
Key Success Factors
1. Have a project initiation phase that does not complete until the sacrosanct high-level priorities of the sponsor and key high-level architectural decisions are agreed.
2. Adoption requires full co-operation of the Business as well as IT. It also requires all teams to be well trained and to distribute people with Agile experience across scrum teams.
3. Ensure that your performance management process aligns closely with the expected behaviours of people performing Agile roles.
4. Invest heavily in ensuring your application is fast and predictable to release. Without this, the benefits of faster development are lost when changes hit a bottleneck of live implementation.
5. Document and publish development patterns and coding standards and ensure you continually monitor conformance.
6. Constantly strive to reduce quality feedback time, i.e. the time from a developer making a change until the identification anything that related to the change that would indicate it as unworthy of promotion to production. This involves automating as much testing as possible and optimising the execution time of your tests.
7. Allow scrum teams to estimate and plan their own sprints and track the accuracy of this process over time.
8. Ensure you programme is heavily metric-driven and expect to need to continually refine the of your methodology over time to improve effectiveness .
Here are common pitfalls:
1. Forgetting that adopting Agile affects the whole organisation and it will not succeed in silos.
2. Making the assumption that documentation is no longer necessary. If something cannot be validated through an automated test or system monitoring, it still needs to be written down.
3. Using Agile’s innate scope flexibility to the extent that the project direction is in a constant state of flux leading to delays to benefit realisation and a lost recognition of the overall business case.
4. Becoming functionality obsessed and overlooking non-functional requirements such as performance, scalability and operability.
5. Putting an overemphasis on getting “working code” at the expense of poor application architecture and convoluted code in urgent need of re-factoring to adopt patterns and standards to reduce the cost of maintenance.
6. Devoting too much focus to executing pure Agile, as opposed to tailoring an approach that retains the key benefits whilst minimising risk on a large-scale distributed programme.
7. Making the assumption that less planning is required. Agile requires highly detailed planning involving the whole team and an iterative approach that complements and responds to the Agile delivery
8. Focusing on increasing development/test velocity when the bottleneck lies in your test environment stability and ability to predictably deploy code.
9. Ignoring the impact on service and operations teams who are expected to support new systems at a faster rate.
10. Overlooking the how to accommodate potentially slower moving dependencies such as infrastructure provisioning.
11. Doing things based on a perception of what “Agile” tells you to do and neglecting experience and knowledge of your organisation.
However, I must concede most of these pointers are based on common sense and my experience, and most could be applied to Agile, Waterfall, or any methodology.
Please let me know your thoughts.