Anyone who’s been developing software and has been awake for the last five years knows that agile development is much better than waterfall development. But for those of you that haven’t heard, here’s the briefing:
Waterfall is the traditional way of creating new software. The four step “software development cycle” is:
- Gather requirements for the software
- Design the software
- Write the software
- Test the software
It’s called “waterfall” because you don’t start the next step until you’ve finished the current step. It’s been a disaster. In fact, I wrote my own description of the four steps (with apologies to Lewis Carroll and math teachers):
Agile development is very different. You start by talking to the client and writing stories about how people will use the software. If the software is deep in a server, there are still stories to tell, because ultimately someone has to be pleased or displeased with how well it is doing its job. From the stories you gather requirements, and from that you write software.
Sounds a lot like waterfall, no? That’s because I didn’t tell you the key component: iteration. Rather than assuming that one gets everything up front, you pick an initial set of features that you can complete in very little time. The client can then give you feedback, which leads to changes and additions, again through stories. The iteration continues until the client is satisfied.
One other thing you need before you can do agile development is a complete end-to-end process. That means that you create an actual product (sans many features) from the very first iteration. This includes having a revision control system and having an automatic build which produces an installation program that installs the ultimate product. During this process, it is also documented, tested and feature and bug tracked. Too many project put these things off to the end. In fact, every aspect of the software development cycle has to be in place for the first iteration. They may be incomplete, but they are there all there, and they develop in parallel.
Agile development tends to take place from the bottom up, because managers are usually behind the developers on technology and development practices, and are the only ones who know how the project is doing, anyway. Most managers are still wedded to waterfall. There are courses you can take to make you a “Scrum Master,” which is sort of the agile form of management, with daily, short, stand up meetings, for example, but those people are usually team leaders rather than actual management.
At one company I worked for, we brought in someone to help the managers with project management. I don’t just mean for a seminar, but as a full time employee. He gave a talk explaining all the latest stuff about project management. When the question and answer period came (at the end of course, no audience interaction during his PowerPoint presentation), I asked him how the system dealt with changing requirements. His answer floored me. He said that requirements don’t change, or if they do, there has to be a special process involving lots of meetings and probably gnashing of teeth. This struck me as completely out of touch with reality as I know it. Clearly, management is still stuck in waterfall.
Management is not only responsible for projects (or on a higher level, programs) succeeding, but also making sure that their people are succeeding as well. Sadly, waterfall is still in place here, too. Managers manage people once a year at the annual review. There’s some back and forth, but mostly the manager assesses each worker’s performance, and then either raised your salary, promotes you, or puts you on probation, which is just a way to draw out the ultimate firing.
The alternative is called the performance preview. On a short time period, say a month, the manager sets goals for the employee. During that time, these goals can be adjusted, if need be, and the meta-goal is to make sure that expectations of the employee and management are in sync. Both sides work towards making sure that the goals are made. A failure to meet goals reflects equally on the worker and the manager. Managers in this system are more like coaches on a basketball or football team. When the team wins, they win, and when the team loses, they lose. This is reality anyway, it’s just that the current practices don’t match up with it.
Will this change? Yes, it can, but it can only happen if senior management decides to make it happen. They need to adopt the same values and processes with dealing with the managers below them. Feedback works best when it comes quickly after the action, on a short timescale. If there is a problem or something that needs correcting, it needs to be fixed right away. In the case of employee reviews, if there’s been a problem for a year, any feedback at that time will be utterly useless.
There are many good books on this. Search Amazon or use DuckDuckGo. (Oh, are you still using Google? Sorry to hear that.)