What’s the hottest word in software development? Agile. What’s the best way to develop software (depending on who you ask?) Agile. How will we bring about world peace, stop the proliferation of nuclear arms, provide clean water to everyone, and finally get hipsters to shave their beards and stop it with the French-pressed coffee?
Agile is the right way and everyone else goes the other way. That’s all very nice to say and assume, and really, to believe, but assumption and blind faith is not enough, and Agile development deserves more than slavish sycophancy.
Let’s go back to the building blocks of Agile; let’s talk about the manifesto.
1. Individuals and interactions over processes and tools
This is so much easier said than done and you know why? Because individuals = human beings, and human beings are creatures of habit. What do creatures of habit do?
- They like their coffee a certain way and from a certain shop and sometimes even at a certain time
- They prefer to use Bugzilla or JIRA instead of Remedy or Quality Center
- They like being able to commute by bicycle even though an office location change could mean a much shorter commute by train
- They assume only people with previous Agile experience are capable of hitting the ground running
In Agile development shops, don’t let your habits which were borne of good intentions, override your original desire to have great people doing great things. As a faithful adherent in the temple of Agile, don’t forget that once you knew nothing of its tenets and be willing to teach and to learn.
2. Working software over comprehensive documentation
Of course everyone wants to see working software. That’s the whole point of development, right? To make something that works and meets the needs of the customer. That said, the key word there is “comprehensive”, not working software over “documentation”, full stop.
Agile is not an excuse to avoid use cases, diagrams, specifications, or test scripts. Agile is not an excuse to fly by the seat of your parents, write spaghetti code, pray-pray-pray, insert a caffeine drip to have enough energy to code right behind the bugs as they wreak havoc, and then to do soap-rinse-dry-repeat cycle in the next iteration, on the next module, and to the bitter end where either you have to start all over again or it all falls apart.
Documentation can be iterative and it can be fit-for-purpose. Make it fit-for-purpose so that it supports your development of working software.
3. Customer collaboration over contract negotiation
Sales folks are good at promising the sun, the moon, the stars and the entire galaxy. A good salesperson can up-sell and cross-sell and not only sell snow to an Eskimo, they can make the Eskimo thank them for the pleasure of doing business.
Agile development is not sales. Being responsive to customers and working with customers to build a product that truly meets their needs is a foundational aspect, but that is not sales and it is not promising things that either:
- a) can’t be delivered,
- b) shouldn’t be delivered, or
- c) exceed the cost/value ratio
[This assumes that cost = resources/effort required + long-term product maintenance costs and value = base sales (that cover the resources/effort required) + customer goodwill]
We are very good on the resources/effort required angle, but we are all bad at weighing customer goodwill over long-term product maintenance; the trend I’ve seen is to overweight customer goodwill.
Contracts are not just about the paper they are written on. Contracts have a social aspect, and contracts include the internal stakeholders as well. Don’t forget about the whole equation.
4. Responding to change over following a plan
Ever heard the saying that “man plans and God laughs”? Sometimes I feel that engineers on Agile development teams like to step into the place of the second actor as they act “on behalf” of customers’ changing needs (or is it wants?)
The heart is in the right place and one of the key benefits of Agile over a more traditional method like Waterfall is the ability to react and adjust. The sprints, the shorter cycles, and the iterative process itself allow for an increased level of responsiveness and an increased level of positive change.
But change for the sake of change, or a deliberate stepping away from a plan, even a lightly sketched one, is detrimental overall to both project and product success. Don’t let a strength become a weakness. Discipline is a necessity for successful rapid change.
I hope no one takes this as a diatribe against Agile development. In fact, it’s just the opposite; it’s a reminder that the principles of Agile are worthwhile and that we need to make sure the implementation and practice of it remains aligned with the spirit of it:
- Keep teaching and learning; don’t create “Agile habits”, stick to the principles of people and interactions
- Make working software by writing down, in some reasonable fashion, how and why you did it especially as at some future point, you may need to know some of that
- It’s not only about making customers happy; contracts can help you build a sustainable product and keep your internal stakeholders, who matter, happy too
- Rapid change requires discipline; good plans can be guide markers if you let them