In this final post of the three-part post about the Agile Manifesto principles, I think it’s important that we reflect on the impact the manifesto has had on software development. Agile software development started in the mid-1980s. People were trying new and interesting ways of creating software that didn’t follow a “big design up-front” philosophy with GANTT charts and such. But it was because of the meeting at Snowbird that we have a good framework for how we can deliver quality products. So let’s jump in and finish these off!
Our ninth principle is:
Continuous attention to technical excellence and good design enhances agility.
This principle can be a little challenging, especially in “get-er-done” kind of environments. Some engineers (and managers) tend to think that cutting corners now saves time. It doesn’t. We don’t want to delay quality, trying to make it all up at the end. First, that’s not how we should be thinking if we’re working in short, sustainable time boxes. And second, if we wait until the end, quality will always suffer. We see it in traditional projects where the quality team gets the code at the end of the schedule, has to kill themselves to test things before we can release, and gets blamed for “finding too many bugs”. Ugh! I often tell engineers: “If you didn’t put so many in there in the first place, they wouldn’t have so many to find.” Okay, I don’t normally do that, but I have. And it usually has the desired effect.
Building in quality is a requirement. It’s why design patterns and eXtreme Programming techniques are popular. And they’re shown to work. Add in good automation for continuous integration and testing and you’ve got a team that’s moving in the right direction.
Simplicity–the art of maximizing the amount of work not done–is essential.
I find that this one is the hardest agile manifesto principles for engineers to grok. For many engineers, the idea of coming up with the elegant or “right” solution is very tempting. “Why would I just code for this specific case when I can spend a little more time [yeah, right] making a great generalized version that anyone can use?!” Because that’s not what we’re solving, mister or ms engineer. We’re solving this specific case.
A study by the Standish Group showed that 64% of the features they built in their products were “rarely” or “never used”. That’s astonishing. And shows how much time, effort, and money is spent building things that people don’t need or even want.
The best architectures, requirements, and designs emerge from self-organizing teams.
If engineers struggle to understand the previous principle, then this one is especially hard for managers. They’re very used to creating teams from the people who report to them and then telling those teams what work to do. In an agile environment, though, we find that teams that manage themselves are more productive and produce better quality code. We find that knowledge workers, or employees who know more about how to do their work than their managers, work best when given the opportunity to self-organize and, in some cases, self-manage. That doesn’t mean that managers have no place in agile – quite the contrary! – but it does mean the role is modified somewhat from traditional business models.
In general, we want our teams to be responsible for figuring out how to build the product. The what comes from the customer or their proxy, but the how comes from the team. Are there times when we need to rely on others outside of our teams? Yes. Should we try to minimize those dependencies? Absolutely. Let the teams – as much as possible – write their own destinies.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This final agile manifesto principle is the one most chosen by agilists as their most important one. It is the basis for retrospectives and is at the core of continuous improvement. Without reflection and self-examination, change isn’t possible. Without change, improvements stall and stagnate. And that’s a recipe for disaster on any team. Retrospectives are vital in enabling these examinations and offer a framework for how we improve ourselves individually and as a team.
The agile manifesto principles are critical to our understanding of how we implement the values of the manifesto. It can be easy to think that we don’t need to hold a retrospective or that we should measure progress through a project schedule. That’s a primrose path of thought. All of these things contribute to a successful team and, by extension, successful products that result in happy customers. Can teams get by without implementing all of the principles? Sure. But then it becomes an uphill battle when it should be a downhill stroll. And the agile manifesto principles help get us where we want to get to – not just doing agile but being agile.
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)