Agile is not a new concept. Over the last few years I have taken on various roles (and combinations of roles) within the teams I have worked in both in a corporate organisation and more recently as part of a tech startup here at SuperAwesome. I have had many different experiences with Agile development along the way.
What I have gleaned from these experiences is that Agile has become more and more process driven over the years, often at the expense of the underlying principles that enable agility in development. In many ways, Agile has lost it’s way since the original Agile manifesto was drawn up back in 2001. Dave Thomas – one of the authors of the Agile Manifesto – makes this point in the article below. He talks about the “corruption and devaluation of the word Agile”.
To quote from Dave’s article, he writes:
The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.
So I think it is time to retire the word “Agile.”
But he is only talking about the term “Agile” and the way that it has become used to sell courses and tools. He goes on to say:
I still firmly believe that sticking to the values and practices of the manifesto will help them in this endeavor.
The phrases on the left represent an ideal—given the choice between left and right, those who develop software with agility will favor the left.
He then continues by giving the following simple explanation of how to develop with agility:
What to do:
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
How to do it:
When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.
As you can see, the point that Dave Thomas is making is that the concept of “Agile” has been over-complicated and used as a “buzz word” to sell consultancy and tools when really it should stand for a set of simple principles that are used to facilitate agility of development.
With this in mind I have drawn up a handful of very high level points that I have found to be the most useful ideals to bear in mind when applying Agile development principles to your own business. These are not process based for the reasons I have explained above and are in no way a definitive guide. They are just a few things I have picked up along the way:
Identify and mitigate risk early
The basic point of agile is to develop working software quickly and then adapt it as you go to meet the feedback you get from your users. However, this only really works if you identify any necessary adaptations quickly and apply them as early as possible in order to avoid spending an excessive amount of time refactoring and redeveloping existing software to adapt it to the changing requirements. To avoid this you should always be thinking ahead towards any areas that you are not sure about or may cause a problem further down the line and try to address these as soon as possible. The 80/20 rule applies – do 20% of the work to achieve 80% of the results and then test to see if this works or needs to change.
Adapt agile to suit your needs
The first thing you need to do is establish what is important to your business. From there you can pick and choose the processes and tools that you feel support the way you develop your products and the goals of your business. These can be influenced by all of manner of factors. The important thing to remember is not to get bogged down in whether you are “doing Agile right?” In fact I would go as far as to say that if someone on your team says you are not doing agile right because you are not following a certain procedure or using a specific tool then they have completely missed the point of agile.
“Do Agile Right” is like saying “Do Orange Right.”
Try to include non development tasks in your Definition of Done
We all know how easy it is to develop a working solution and then realise that you really should have some supporting documentation to go with it – particularly when someone leaves who was solely responsible for a certain aspect of the product or a new developer joins the team and you spend half of your time explaining how everything works. However, once development is complete you then face the daunting task of retroactively going back and spending a lot of time writing everything up. Not to mention that this can be very hard to justify to the business when there are new features to be developed. Also time spent on non-development tasks often does not deliver any obvious short-term value to the business. Even the long term value can be hard to quantify!
With this in mind it is important to see documentation and any other non-development tasks that are important to your business as part of the development of a feature and to take the mindset that development is not complete until any accompanying documentation and test scripts have been written.
Development teams should focus on agility over following strict agile practices. I am not saying that you should not make use of any tools or processes. In fact I find they are an important part of software development and I have used various tools that I have found useful over the years. However, these are not essential to good agile development (particularly in small teams) and should be chosen to complement and improve the way your team organises itself. Ultimately the basic principles are all you really need to adhere to in order to achieve agility in software development.
[Chris is a Senior Front End Developer at SuperAwesome.]