Agile development – the importance of discipline

In my last blog post, The most badly implemented, yet most critical, technique in agile projects, I briefly mentioned discipline as being important. In this post I explore this further and dispel a couple of myths associated with Agile development.

Waterfall approaches facilitate poor discipline

Waterfall projects, the bigger the better, are almost designed to create good hiding places for poorly disciplined people.

The Project Management community has had a huge amount of experience managing waterfall projects; just take a look at the thickness of the latest version of the PMBOK and you can see the volume of material in support of helping PMs manage waterfall projects.

We've learnt through the years that we need to leave longer than we'd hope for the testing and defect fixing phases, the user acceptance testing (UAT) phase and the release phase. We've also learnt to build in a fair amount of contingency and we've learnt that businesses keep changing their requirements and that we'll need to be careful to manage them so that it doesn't blow our budgets.

One of the reasons we have all of these contingencies and buffers is that despite our best intentions, every individual in every function involved with the project generates errors; they are human after all. Whether it's in clarification of requirements, implementing a feature incorrectly, missing a boundary condition on a test, accidentally not trying one of the functions when signing off in UAT, or even in accidentally releasing the wrong version of a file into production. All of these potential problems need some contingency built in to cater for them.

This is in effect doing no more than the medical profession does with the flu, which is to alleviate the symptoms. If we're building in extra time to handle all the defects that arise, why as a developer should I bother improving the quality of my code? Why as a tester does it matter if I miss a boundary condition since we'll pick it up next time around? Why as a system administrator does it matter if I deploy the wrong file, I can just fix it after post-release testing - after all the release window would be long enough? And frankly, as a developer again, since I'm only delivering my code to the testers and then leaving the project, why should I care if it's what the end user wants? In short, many of our controls and risk management approaches on waterfall projects have been driving the wrong behaviours.

Quality is King in Lean and Agile development

Now, enter stage left, the Agile technologist. He or she is expected to frequently deliver valuable software to clients. There is an obvious change in emphasis.

For a start I've intentionally made the profession irrelevant. That's obviously not to say that there aren't separate functions, however, the statement applies to all of them, in whatever combinations they exist.

Secondly, there is an expectation that technologists can respond to a moving business agenda. We need to be able to respond to change quickly; we need to “be agile”. We are also expected to be efficient, or lean, which means we don't want to be wasting time fixing problems we've introduced ourselves, we want to be working on the useful, value delivering, interesting needs of the users and the business. We want all of this and this is what our organisation expects of us.

To be nimble and efficient however, we need to optimise our value. We can't change direction if we haven't delivered the last thing asked of us and we can't be efficient if we're spending half our time fixing defects.

Whether you're a believer of the cost-to-fix curve and its applicability to modern development methods or not, it makes sense to take whatever steps possible to ensure we aren't generating problems in the first place so that we don't waste our time having to fix them. Bluntly, we haven't got the time to do so and still meet our employers' and users' expectations of us.

It follows then that quality is crucial to our success. Gone are the days of "acceptable defect counts".

Removing stage gates requires greater team and individual discipline

To be more efficient at delivery we align our organisational structure against communication lines in the delivery chain. We do this by creating cross-functional teams. This allows us to increase our delivery frequency... to a point.

The limiting factor from a delivery efficiency stand point in most organisations moving to cross-functional teams is existing stage gates, committees or groups designed to "protect" the business from changes made by IT. Sadly, these are a necessity for organisations that align teams by function because there are no organisational structural drivers to encourage individuals to worry about anything outside of their own part of the process. This leads to local per-function optimisation rather than optimisation of the whole delivery system and the former tends to result in quality problems and eventually unhappy users.

On moving to a cross-functional team structure, the drivers change and the accountability moves closer to the teams. This is a significant cultural change.

To get more efficiency, control has to be decentralised, which means changing the remit of, or removing, those stage gates and committees in the process. Decentralising control requires help and trust. The difficulty though is that humans are error prone. Frequently when we encounter these errors our instinctual reaction is to put controls in place to ensure it can’t happen again. These controls often take the form of check-lists, a reduction of authority, or a re-centralisation of control. These will all however negate those efficiency gains and also erode trust.

Given the drive for increasing release frequencies, the need for high quality levels, decentralisation of control and the requirement to maintain trust we can see the case building for agile teams needing to be a lot more disciplined than their waterfall counterparts.

How to become more disciplined

Of course building self-discipline is a whole problem and challenge in itself and there are whole books on the subject.

I personally use Jurgen Appelo's approach as a reference, from his book Management 3.0, which identifies 4 key ingredients to self-discipline:

1. The realisation that something is important.
2. Basic time management
3. The requirement to not forget!
4. And possibly the hardest: to be motivated.

We can all help each other, our colleagues, our staff, and even our bosses become more disciplined. Don’t necessarily expect your manager to know or help you with this!

We can reinforce messaging around why discipline is important in Agile development and we can teach basic time management skills, like creating schedules, recurring appointments, distinguishing between urgent and important tasks and so on. We can also use tooling such as reminders, work flow tools, task lists, physical work boards, definitions-of-done and so on.

Motivation as mentioned above is one of the hardest to help with but, still paraphrasing from Management 3.0, fun is closely correlated with motivation so if we can find ways to make the tasks more enjoyable then this can only help!

Next steps

Thanks for reading. Hopefully I've convinced you that discipline is important for Agile development teams and you've got some pointers on how to help yourself and others become more disciplined. There are some tasks that are a constant struggle to maintain self-discipline on. My personal nemesis is putting together project reporting, but seeing that it's used by the people I'm reporting to, throwing in some recurring reminders in Outlook and using templates to keep the reports easy to produce, I find I can normally get them done. Good luck and let me know how it goes.

If you've found this post useful the please let me know about your experiences in the comments or click the Like button at the top so I know this is what you're looking for and I'll keep writing!

Ray Cooke is a Lean and Agile business transformation coach, based in Equinox IT’s Wellington, New Zealand office.