In the local and national software community, Storage OS and Syneto have a reputation of excellence in applying agile techniques. At various community events, I am frequently talking about how we develop software, how we plan features, and how we collaborate in general to provide the best possible product. There is, however, one thing attendees keep telling me which is surprising me every time.
It is easy to do agile when you start a project from zero and know what to do.
I find this observation, or conclusion if you wish, wrong for two reasons.
First of all, we are not prodigies. We did not read a book in half an hour and miraculously became experts in agile practices from TDD to Pair Programming, and from Scrum to Lean and Kanban. We started transitioning from a classical waterfall software management to agile about 5-6 years ago . It didn’t happen in a week or in a month. It happened, slowly, throughout the years. When we started, there was no Storage OS, we were working on Syneto’s UTM project. We learned to be agile mostly on that legacy project. And while we had the basics covered when we started Storage OS, we had to learn a lot along the way.
The second error in the above statement is about being easier to do something new and in the right way from the start. First of all, there is no universally right or wrong way to do software. If you do your best to write the most performant, beautiful, functional, and easy to understand code based on your current knowledge, then that is the right way to do it. Ah! You will discover, in six months or a year, that the way you think has changed dramatically, that there are better ways to do things and your new right way to do it is very different … no problem, refactor. Apply what’s knew to the old code you already know. Apply TDD to refactor a module whose business functionality you already understand. Use pair programming to extend a legacy extension for your application. Plan the next feature on a Kanban board. It is always easier to modify something you understand by applying a new technique. It is much harder to both try to understand a new technique (or several), and at the same time try to figure out what the business side wants your application to do, and how you could implement it. Do only one thing at a time, no more, whenever you can.