There can be debates whether the Agile Software Development processes have become mainstream or not, but most of the software development houses are trying to adopt the Agile practices. Yet, coming from academia or, say, a less agile environment, such practices can be misunderstood.
In this post, I am going to tell how I have become an avid agile practitioner and what has helped in that glorious journey. My journey started in December 2011 when I finished my Master’s got my first full time job as a Software Developer at Cloudreach Limited. Of course, I had a couple of internships under my belt, and was running this blog, but I clearly didn’t have any experience of working in a team on commercial software. I must admit though I was still interested not only programming languages and technologies, but also in processes. Yet, I only had, say, some textbook knowledge, and was slightly scared to write tests before code. I remember though that while working on some university project I was saying to myself that I must write some unit tests, or otherwise, my code would become a buggy mess.
The times they are a changing. Now, I can’t allow myself to write a piece of code without writing a test first. So, I’ll try to list the thing which have helped to become comfortable to Agile, and which I have noticed on my journey.
First of all, I would hardly be able to embrace Agile without the help of my more experienced colleagues. Thank you guys! Of course, one can read books, and various online resources, but it’s crucial to be able to ask someone a question, and check whether you are on a right track or not. In total, I was assisted in the following ways:
The last, but not the least, be open to new things. People can be naturally resistant to changes, and it’s essential to keep that in mind when thinking about the customer, yet, yourself should not be discouraged from doing something in a new way.
Just recently I came across an article which said that Scrum had achieved its solid position today mainly due to its simplicity. Thinking retrospectively, I would say that this is indeed true. Moreover, this is one of the factors that has helped to adopt the agile quite easily.
Moreover, things like daily stand-ups and sprint retrospectives allow you to know what everyone is doing, and have your say if something does not go very well.
Writing tests before code might sound strange at first, but it’s indeed worth doing that. It not only makes your code more reliable, but also dramatically improves its maintainability. Indeed, the book that assisted me in embracing TDD was called ‘Growing Object-Oriented Software Guided By Tests’. There is a popular argument against TDD which says that it slows down development. In fact, it speeds it up. Try writing a complex application that interacts with a few external system with no tests – it will fail to work at first, and you will struggle to debug it.
Finally, don’t focus on testing method per se, put emphasis on testing behaviour of your application and its parts. Adopt Behaviour-Driven Development, and pair it with Outside-in Development.
I also gave a talk in Glasgow, UK, and wrote a blog post about Outside-In Behaviour Driven Development.
Indeed, you can work with a programming language whose limitation doesn’t allow for having a generic mocking framework. Is it a reason not to use mock objects in your tests? Not all! After all, it doesn’t take a lot of time to write mock objects by hand. Once again, the benefits of doing that will hugely outweigh that little time you spend on it.
There is no better way to ensure that you understand a concept than explaining it to someone else. Feel free to tell about your Agile successes to fellow developers. Don’t be afraid to blog, and speak at public events. You will not only improve your understanding of the Agile methodology, but spread the word about it. Needless to say, it will also help you to build up your professional reputation.
Having called myself ‘an avid Agile practitioner’ in the beginning of the article, I believe there are still tons to be learnt. After all, we should try to learn something every day.
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way. My personal thoughts tend to change, hence the articles in this blog might not provide an accurate reflection of my present standpoint.
© Mike Borozdin