As much as I love agile development, there is something more important that’s often forgotten: a good understanding of software development. Oh yes — and a little common sense wouldn’t go amiss sometimes, too. A case in point: Paul Stack tells a tale of software woe, in which his workplace has taken up a new approach, and he’s not happy. Here are some of things they’re doing, and it drives him to ask “Is it really agile?”

• The business decided that the team should be “coding” for a full 7 1/2 hours a day and continually checked that this was the case.
• The management take care of the estimates
• The developers are not part of the planning process
• Estimates are made on a best case scenario
• [Management] think when we are talking about architecture and code quality that we are not working hard enough.
• They do not understand that if time is not given to extensibility and maintainability, that delivering software will become very costly

There are other things, too, but those are the ones I want to highlight. Because the correct response to the question “Is it agile?” is “Wrong question”. It’s a bit like realising the aeroplane you’re in is heading towards a crashing landing, and frantically checking your ticket to see if you really did book a window seat after all. Never mind about whether it’s agile — this is just not even sensible.

All the practices above are the kinds of things enforced by people who aren’t very experienced with running software projects — although I would agree some of them seem like common sense to an outsider, and all of them are the kinds of things software managers can get pressured into by stronger outside forces. But they’re a long way from what should be happening in any well-run development environment. Let’s address them in order:

• Yes, coding is absolutely essential. But so is co-ordination, planning, revising, sharing knowledge, flagging complexities, helping colleagues and a lot of other things that don’t involve typing.
• If the person doing the job doesn’t make the estimates then there’s no reason to expect the estimates to be right.
• If the people doing the job aren’t involved in the planning then there’s no reason to expect the plan to be realistic.
• Estimates aren’t predictions.
• If you don’t design the system right, and keep checking and refining that design, then everything will be more difficult for everyone. Getting this right is called “architecture”. Poor quality code also usually makes things more difficult for a lot of people, so it’s worth spending time on.
• It is very easy to cut corners early so as to increase development costs later.

The second, third and fourth points here should be common sense, while the rest probably aren’t obvious to a non-software person. But in the world of software development getting these right is essential — it’s just good practice. And in doing so you would make the life of a developer like Paul (and the projects he’s working on) a whole lot better. If you want to be even more effective you could adopt agile practices, too. But you can still be sensible without being agile.