Back when we were doing waterfall projects, the whole management focus used to be on planning a release from start to the end, and then executing that plan. Everybody was doing effort estimates and resource plans, and project/program managers were trying to figure out which features would fit into the next release, and which wouldn’t. There were meetings with customers and endless negotiations about the stuff that would make it and bargaining about what can be left out.
The carefully crafted plan eventually started to fail at some point, and then it was time to replan: make new estimates, decide again which features can or cannot make it to the release, stop implementing and focus on planning, until new plan was finally accepted. And when it failed, the re-planning started again, and so on. I have now realized this had an interesting unintended effect: management focus was most of the time on the least important features.
I used my drawing skills to illustrate the point with the picture of a release plan above. In waterfall, the most important items were always going to fit into the next release anyway, so there was no need to focus on or fine-tune them after they were put to the top of the list. Instead, everybody was thinking about the features that were close to the so-called “waterline” of the next intended release: those features that were oscillating between being just important enough to make it in to the next release and being non-important enough to be left out. Everybody was focusing on these lowest value bringers, trying to fine-tune them, stripping of unnecessary parts, including just the parts that really add value, thinking about who could do what for them… In other words, doing just the stuff that should be done for your most important features!
In agile development, management focus is constantly kept on the top of the backlog, where the most important items lie.
In agile methods like scrum and kanban, the whole development organization from developer to management is all the time focusing on these most crucial features: fine-tuning them, stripping them of unnecessary parts, including just the parts that really add value, thinking about who could implement them, evaluating are they still the most important features as they see them being developed, and so on. And only when these features get done, focus turns to the next items on the backlog, which are now the most important features for the whole organization to work on.
At least to me, constantly focusing on the most important features of your next product release instead of the least important ones seems very valuable.
Coach Jarkko 