Andrew Breese

Musings of a professional geek

Thoughts on the Agile Manifesto

Interesting reading on agile development recently came across my inbox, and like most things post here it got me thinking. A work fellow shared a detailed article by Mike Cohn at Mountain Goat Software which reflects on the last 10 years of agile development, and provided a link to the Agile Manifesto. Mike’s contention was excellent – that it is time to stop talking about Agile, as Agile has won. Bloody interesting contention in my opinion.

Shamefully despite having a very strong opinion on agile, having read darn widely about it, and particularly why it often fails to live up to expectations, I had not read the Agile Manifesto to which he referred, but what I read there I really liked. Up front the manifesto states why is exists (to deliver software to customers), and still acknowledges that the goals of waterfall-ish approaches are still valuable.

If like me, you were not aware of it or want to refresh your mind on agile – please the Agile Manifesto.

What I also like is that it is a true manifesto; meaning it is clear, guiding, but not overly prescriptive in detail. I think that comes from the basis that telling an organisation exactly how to work is pointless, as you can never provide a total solution for every vendor, client, or problem in advance without understanding them. To use a bad metaphor: it provides the guiding light but each ship still needs to be steered independently; and many storms and rocks abound.

Mike’s article suggests that we need to stop talking about agile as something which is needed, as it has already won. It is mostly true, and an excellent sentiment, but it is also preaching to the choir (so to speak). Developers and those who work with them as delivery practitioners are probably already converted to one of the agile-ish philosophies. But the same people need now to speak outward not inward.

The part that remains in my opinion (standing as I am at the side of the team as a project manager, and sometimes app designer) for agile to achieve is to have development customers (a.k.a. clients) and consumers to reach an understanding of what it really means, and to be able to embrace the techniques properly.

Agile development without the customer being embedded within the process is pointless, and this is time and again the area where the largest deficiencies are found. This is also the view of the person who shared the articles with me, and while his view was targeted on the product owner and project sponsor as the folks who next are to be convinced, I think it is all of the individuals in the development delivery process that need to be accepting of agile. And the end customer of the application is a critical member of the delivery process. This is because agile depends very strongly on collaboration, communication and honest shared goals.

If a key member of the team is not on-board, then the process is bound to be more difficult that it should be. It would be even worse if a member was actually working to undermine the process. I know this is also an obvious statement, but in agile not knowing and understanding the reasons why the approach is used is basically the same as blocking it. Not many people work productively when they do not value the method of work or potentially the goal.

The manifesto needs to be shared (almost forced) upon the client base of bespoke developers, so that they slowly get it. Get a true appreciation of agile into the mindsets of the marketing, admin, management, and sales areas, then tell me it is time to stop talking about it. Talk to a government organisation about how they conduct projects and you’ll see all sorts of fixed price constraints, massive up front requirements, and terrible reliance on approximate waterfall methodology. In short the thinking of some of the largest and most influential bodies in our direct communities has not changed. And I can sympathise with why these organisations are loathe to adopt agile; they do not understand it, and it sounds on the surface like an uncontrolled process which will increase costs.

The change in thinking is possible to achieve though, and there is evidence that commercial drivers will eventually pull client organisations toward different approaches from what they already know. In effect we need to change the customers’ expectations of not only the outcomes, but also the approaches. The explanations need to be provided in business terms in practical ways, and in authorative publications. If this is done repeatedly we will see a shift from either disinterest or fear about agile, to a curiosity and acceptance. Deliver clear descriptions of the improvement to outcomes and the benefits of the process to businesses, and they’ll keep changing.

It does not make sense to expect better outcomes if you have not changed the way you work, and trying to develop a project using “iterative waterfall” but then somehow have expect outcomes of an agile method is silly. Like expecting 2+2=10. To get a result of 10, we need to change the inputs and change the function. Try 2×5=10 and we’re far ahead of the old product of the old question.

Here are a few other examples of where a term or concept had been readily accepted by the practitioners of the concept, but the wider community needed time to grapple and then to accept it:

  • In the dim dark history of tech it took a while for “email” to be understood. At the time faxes were changing the way business was conducted, and email was just science fiction. It was a world changing tool, that I both love and hate daily…GTD helps.
  • Then “the Internet” was adopted, laughed at, and then changed the face of the business world. Thankfully we now have designers dedicated to creating useful web experiences, rather than devs and hacks (like me) using NotePad; they might have worked, but they were not easy on the eyes, and wide adoption needs to be delivered in a consumer friendly manner.
  • Afterward “mobile” became a popular and expected function. Carrying a batch of applications and information with you at all times as empowering as it is jailing. Getting email, information, and even bug reports at all hours, while driving, and while sleeping quickly led to management strategies for living mobile, so its safe to say its expected as standard now.
  • Recently the “social” buzzword has emerged to change the communication styles of some organisations. The connection with customer base is increasing steadily and slowly, and thankfully we’ve seen a few PR disasters which help to guide toward effective results. Counterpoint is Vegemite2.0, but I digress.
  • And now I hear that cloud is the thing of the future, despite being around in a similar form for many many years. I’ll grant that the delivery now is far more automated and elegant, but “online” delivery of “online” applications, on adaptive platforms is not altogether new (darn I feel another soapbox forming….).

When the world gets a hold of Agile properly, it will change in ways that we can’t yet predict, and change for the better. This is where the real appeal for me is with agile-ish approaches, as I think that now we can do so much if the teams know how to work, but when the concepts have been entrenched and well understood for five years in the wider community we’ll see a fantastic change in both the expectations and the products of the development community.

That said, the change is certainly coming. There is a wide range of dev bloggers and industry commentators who are already advocating for the change in perception, and driving the push. Allan Kelly’s article on Agile Contracts is excellent (also via my CEO), and I have always found Joel on Software to be excellent reading, for both agile thoughts but also for real world examples of where an open approach has delivered measureable and profitable results.

I can’t wait for agile-ish to be the standard method of dev, bring it on.

To be clear, here is a small disclaimer: While highly opinionated, I am not an authority on Agile. Not at all. In fact I’m no more an expert on agile than I am on anything else, but have successfully delivered a few agile projects, with positive and in one case an award winning result. To me Agile is real and worthy, so I probably don’t need a soapbox (or blog) to be encouraged to yell about it. 

As a counter-point I’ve also smashed my head against projects, people, and organisations which continued to whine about flexibility, the need for tollerance in change requests, and timelines; but insisted on fixed costs, up front requirements, and a total disconnect between devs and customers.

Sometimes the very folks I am arguing with are devs or managers who insist on doing work in an agile manner when it is either not required (due to agreement of methodology), or not effective. I hate to say it, but sometimes the task is better served with Waterfall-ish methods, and its wise to consider which is best before starting. That said, its not often that a project is greatly disadvantaged by agile if it is done properly, so there is little reason to not make it the default.

So my key message to business is:

If you are a key controller/buyer/manager within an organisation and you have the opportunity to develop something, you owe it to your organisation, the team, the vendors, and in particular your stakeholders to spend at least one hour having agile explained to you. And do not trust the software vendor or your own staff for the explanation, seek out an independant person.

And if you can’t find anyone, keep looking until you do. Heck spend 3 hours, and you might get a perspective that opens you to new and better options for development.


One response to “Thoughts on the Agile Manifesto

  1. Pingback: Queensland Bauxite: Thoughts on the Agile Manifesto « Andrew Breese

%d bloggers like this: