The agile software development methods and its sisters, scrum and lean, are very much in vogue at the moment. You can find countless articles extolling the benefits of agile. But that doesn’t mean turning agile is going to be your silver bullet. Agile isn’t always easy to do well, especially when you’re new to it.
Agile values are very much open to personal interpretation. Consequently many projects that claim to be agile do not seem to adopt all of the Agile Manifesto values and as a result do not deliver all the benefits and results one might expect from a well-run agile project. For example, hybrid agile, which is what we offer, provides fantastic results that work for our clients. However they are not necessarily the same results and benefits that a pure agile project would deliver.
One reason that agile projects fail is due to their reliance on direct communication between customers or users and developers. This communication doesn’t always happen, particularly in outsourced agreements where the customer-supplier relationship is not strong. Every team member should have a solid understanding of the customer’s requirements, if the team leader has not made this happen, and doesn’t share the full picture of the project with everyone, then whether you use agile or not, your project is much more likely to fail.
Teams that are new to agile often seem to struggle with fully defining both the end product and what success looks like. Without this definition any software development project is as at a much higher risk of failure, and agile won’t be your saviour.
As I mentioned in a previous post about successful software development teams, every team member should have more than one skill. Pure agile takes this one step further, suggesting developers are generalists, not specialists. This represents a tough cultural change for many developers who pride themselves on their expert knowledge of their specialist area. This can also be a tough cultural change for many teams and organisations. If, like Future Processing, not all your development is agile, then as an organisation you still need to retain some specialist developers.
One practical way of dealing with the broad-skills cultural shift is for team leaders to work with individuals to identify their current areas of expertise and their desired future areas of expertise. This then gives them a way to broaden their skills while feeling that they are not losing their existing specialisms. To make agile work, particularly in an organisation that is new to it, senior team members should also put aside time to give mentoring and technical leadership to junior team members or those who do not yet have the skills to undertake specific tasks . This also enables the team to move to a more generalist, broad-skills culture.
Humans are habitual creatures. We seem to be wired to seek out repeatable practices and customs. Agile offers many good habits, like daily stand-ups and sprints. It is worth bearing in mind, however, that agile development is as much about the spirit of agile as it is the practice of it. To really benefit from agile, organisations need to be ready, to at least try, to adopt the principles of agile. As Ron Lichty author and agile coach says in his blog, “Just as going to class doesn’t make us educated, performing practices and rituals won’t make our teams agile. Agile means embracing true change, not just tweaking the process at the outside corners where it’s most comfortable.”