On Agile

When you joined, you were informed that our organisation does “agile”. We explained to you what this meant and how it would play a major role in the way you build software within our organisation. You were told that “agile” was something good, that it should be aspired to, and that it is miles better than the “waterfall” of days gone by. You were convinced that “agile” was the way forward, we had sold you on it.

We then instructed you on how to practice “agile”. We gave you the “Scrum” and the “Kanban” and told you to go and do them. You did as we asked and you now produce software in a manner deemed to be efficient. You were satisfied, the users were satisfied and, most importantly, we were satisfied with your efforts — all aided by the “agile” that we provided. You liked this “agile” thing.

Then, one day, you decided to do some reading up on “agile” because you have a thirst for knowledge and you feel like you can offer some improvements to the organisation’s “agile” process…

It is at this point, you discover that we lied to you.

The “agile” you have been practising was in no way the Agile described by its founding document: The Agile Manifesto. You do some more research and you discover that what you have been practising all this time is in fact some hideous mish-mash of concepts taken from all over the place. Some are Agile in nature, some are very much its antithesis.

Your research tells you that it is Agile to start with a small set of desired features and to produce an MVP which you can iterate on, determining new requirements as you go. However, we mandate that many weeks be spent beforehand determining what every last requirement of the product is before the project will be allowed to begin. We think it would be remiss that you should develop something that we weren't absolutely dead sure the users wanted; god forbid that a requirement might change along the way. When the requirements inevitably do change, we welcome these changes by saying “Ah yes, this is the agile way” whilst simultaneously lamenting that our requirements gathering process had not perfectly predicted all of the users’ needs. We lament because these changes cost money.

Your research tells you that it is Agile to perform constant refactoring and reorganisation to remove technical debt. However, we not will provide you with the time to do this. Only features that the users actually want will be allowed to make it into the illustriously touted “sprint backlog”. After all, the users must be able to see progress. We insist that you add the features demanded in this sprint by changing as little as possible of the existing code. Changing something that you’ve already built would just go to show that you’re wasting effort by redoing what you’ve already done. Later, the system fails and we are lamenting having to make a raft of changes to the code just to get it working again because the software was of poor quality. We lament because these changes cost money.

Your research tells you that it is Agile to have the primary measure of progress be working software. However, we insist on defining a seemingly arbitrary set of indicators to determine your progress and then bundling these together into something called a “milestone” which we define as being some fixed point several months into the future. We usually define this based on all of the estimates you gave at “story pointing” sessions. We will expect you to meet this milestone without fail despite knowing this is based on rough estimates of requirements that are subject to change. We begin lamenting some time later when we find that you haven’t met the estimated goals that we chose to set in stone and we have to change the milestone to occur later with more realistic expectations. We lament because these changes cost money.

Then you realise that there is very good reason for our self-created misery. We don’t trust you to develop software. Actually, scratch that; we don’t trust you with our money.

Had we trusted you, we wouldn’t have gone around trying to collect all the project requirements before development began to ensure affordability because we would trust you to collaborate with the users and figure out the requirements along the way. Had we trusted you, we wouldn’t feel the need to meddle in the way you develop and you would would have done the necessary refactoring as a result. Had we trusted you, we would have allowed you to show the fruits of your labour as they come naturally without declaring that progress is the production of an arbitrary number of features by an arbitrary point in time.

Had we trusted you, we would have saved ourselves a lot of time and effort. We would have saved a lot of money.

There’s a lot more evidence you can find that indicates our level of trust in you:

  • You should never meet a user. Any questions you wish to put to users must go through a middle person. This middle person will usually have either the title “Requirements Manager” or “Business Analyst”. The middle person will control the flow of information completely, whether or not they realise it.
  • A non-technical person will demand development must occur in a particular fashion we approve of, regardless of whether this makes any technical sense or whether or not it is even technically possible.
  • Sprints are treated like mini waterfall units inside of a larger agile project, each sprint has a code cut off and testing occurs mainly after that point. After the testing is done, a release to users occurs. The CI that you set up will serve just this one release cycle. Releasing more often is deemed dangerous and risky because it may damage the reputation of the product in the users’ eyes. The users would much prefer to see rapid releases of new features, even if they have got a bug or two.

By now, you’ve probably got a fairly sensible suggestion for our organisation:

“Trust developers to solve the problem you set them”.

This is exactly what our organisation needs to do to save money, however, you haven’t mentioned the thing that matters most to us (or the only thing that we consider to matter at all): The Money. Your suggestion will now be promptly forgotten as it doesn't seem to affect our organisation’s purse. You should rephrase your suggestion like this:

“Development teams are having their time wasted by heavy-handed management processes that don’t allow them to exercise their full potential. Giving developers autonomy over how they do their development work will improve the quality of their work”.

There, now that you’ve put the notion of wasted time into your suggestion we will take notice because we like to equate time and money. You’re almost good to go with your suggestion to us but we are a fickle organisation and we like our corporate buzz-words. Solve this problem by adding more corporate buzz-words:

“The development resources are losing valuable man-hours to micro-management and obsolete business rules which prevent the organisation achieving an optimal rate of software production. Increased productivity can be realised by taking a hands-off approach where management provides teams with a goal but leaves the methodology to the experts.”

Job done. Now its up to you to email us with your new-found wisdom.


It may be tempting to follow up your suggestion with some form of witticism, such as:

“Please just let us do our jobs.”

“Stop deciding how we can and cannot make software.”

Or even:

“If you insist on declaring how every little bit of the software works then f***ing code it yourselves!”

We don’t take kindly to such back-talk from our minions. You will quickly find yourself embroiled in the longest and most painful process known to us: the HR disciplinary process. Agile it is not.