Bamboo Blog

Agile decomposes into values, principles and practices. The values are very high level, the practices are day to day implementation, and the principles tie them together. Applying the practices without understanding the principles is a big problem. Unless you prioritise and focus on the principles you believe in, changing your day to day behaviour will not bring the results you want.

So rather than explain what you need to do to be Agile, in this article I want to talk about how and why I would prioritise the principles. Placing a priority on empowered teams and frequent delivery of working software will, in my opinion, get the best work from a team while allowing them to grow as developers.

Empowered Teams

An empowered team is one that has their goals set by business needs, but has very nearly total control over how they achieve their goals. It’s fine if there are constraints (“don’t make anything pink, and make everything accessible”) as long as the team is told of these, and empowered to choose how to implement them. The Agile Manifesto talks about self-organised teams, which is a property of the more general idea of empowered teams.

Allow the team to take responsibility

To empower a team, they need to be given, and to take the rights and responsibility for, both success and failure. This has to belong to all members of the team collectively, rather than a manager. Otherwise the team is only partially empowered. When given the right to do so, a team will feel responsible for showing that their ideas work.

Motivate the team

An empowered team sees the project as something they can excel at. They see an opportunity to be brilliant. This is one of the most powerful motivations. On the other hand, a disempowered team experiences a growing sense of resentment and they struggle forward implementing things they have no belief in.

Bear this in mind if you ever find yourself about to interfere with how a team is doing something. Is your idea good enough to justify removing motivation and responsibility from the team? Actually, do you even know with certainly that your idea is better at all?

Improve the team

Empowered teams experience a positive feedback effect, every time something goes wrong. The responsibility for success brings responsibility for failure. There is no chance to use the Nuremberg Defence (that they were just following orders). There is no choice but to learn from the mistakes, and become better. If you step in whenever a team is heading for making a mistake, you deny them the chance to learn, to improve and to move towards excellence.

Frequently Deliver Working Software

Frequently means short intervals (rather than fixed duration - though that is also useful). Deliver means the latest version is in use by end users. All known bugs must be fixed (or declared “won’t fix”). There is no more known work to do on the delivered features. The form this delivery takes will vary from project to project. Deployed to a server, burned to disk, and so on.

Find bugs earlier

Frequent delivery identifies bugs sooner. Users are the world’s best testers. I am not saying do not test. I am not saying leave bug discovery to users. I’m saying when the software is given to users, more bugs will be found. When they are found, the team can commit to fixed them in the next delivery.

Know how long to launch

When approaching the launch date, many projects experience an alarming increase in the number of open bugs accompanied by no idea of how long bug fixing will take. If a date (or, worse, a time) by which all bugs must be fixed is set, rather than an informed estimate of how long it will take to fix the bugs, the chances of releasing on time are almost zero.

Frequent releases can feel like they are slowing a project down. Actually some of that impossible-to-estimate time from the end of the project, just a little bit, is being done now. Because it’s such a little bit, it doesn't matter (much) that it can't be estimated. It’s soon done, and how long it took can be measured. This produces a good estimate of how long it will take to produce a single bit of work to deliverable standard.

Know what to build

When a system is delivered to users they normally say why it doesn’t solve their problems. It probably implements everything in the specs, but thats not the same thing as solving the user's problems. This feedback is critical, as it enables a genuine understanding of the problems users have. Often it takes several attempts, with feedback, to address the user's core problem.

Choose your practices based on your principles

Every single practice in your Agile Toolbox, when applied to your team, will help or hinder these principles. If you agree with them, take an honest look at everything you do. If it supports frequent continual delivery, or empowered teams, can you do more of it? If it works against them, can you do less of it?