Agile Bashing
Recently we’ve seen a load of anti-agile commentary. For example:
Good vs Bad Agile
Obie’s Comments on Pairing (via Tom)
The Death of Agile
To add my tuppence:
Software development exists to service the needs of a customer. Being religious about agile does not aid the customers requirements, neither does ignoring it. Know why you are doing what you are doing.
Assuming that development practices fall broadly into two categories:
Organizational Practices (Planning & tracking)
Those practices that ensure the software you produce is the right software:
- It’s what the customer wanted.
- It’s not more than the customer needed to do their job effectively i.e. they were able to do what they needed to when they needed to be able to do it, rather than have the capability to do more than they needed to later than they needed to be able to do it.
Technical Practices
Those practices that ensure the software produced is produced in the right way by the developers e.g:
- Test Driven Development
- Pair-Programming
I do not believe either set of practices should be implemented blindly. Attributes within each should be taken on merit:
Selecting Organizational Practices
- If you believe the best way to produce software in your organization is to write a specification, get it signed, develop, test & deliver a year later, do it.
- If your customer’s needs are better suited by an iterative prototyping development style, do it.
Selecting Technical Practices
- If you believe that your team is currently characterized by non-fungible developers who hold too much knowledge in one area, pair-programme to share knowledge and reduce risk.
- If you have junior team members who need assistance to become more productive choose how to do it:
- Give them a book and send them away
- Pair-programme to bring them up the curve with a real problem in-front of them.
- If you know one common component is critical to the future of the system and really don’t want bugs in it, pair-programme to get a better result.
- If your development team need to pair-programme in order to concentrate on the task at hand, determine why, don’t blindly pair-programme to avoid the problem.
- If your customer needs software out there NOW, weigh up future maintenance cost against the slower delivery of a system that has greater test coverage and is better designed, and take the appropriate decisions:
- Stop or start pair-programming
- Determine what an “acceptable test coverage†strategy is for your release
Do you or your customer choose the development practices to meet their needs?