I love agile development, but I have become very disillusioned with the current state of ‘agile’ software. Now that ‘Agile’ has become so main stream, it has become a buzzword for managers: are you ‘agile’? Now don’t get me wrong, I believe that the current trend towards agile in the management world is great, but it has little to do with what we developers understand as agile. Our ideas of agile have almost nothing in common. Sure we both agree on using sprints as the unit of work and most of us use story points and velocity to estimate project duration. We also both agree that daily scrums (or standups) are fundamental and that we should have a ‘shippable’ product at the end of each sprint.
Most managers, however, still do not understand the fundamental principle of agile development: Red, Green, Refactor. I once had a manager who was a very outspoken advocate of agile software development. He told the team on numerous occasions that if we ever had to refactor, then we didn’t do enough up-front design work and that we were bad at our jobs.
Now I’m a strong believer in up-front specifications and design. If you don’t write a spec and decide on an architecture up front then you are asking for trouble. But, the key here is that we are agile. We aren’t stupid, we’re agile. We know that no matter how much effort you put into the spec and the architecture up-front, you will always encounter unexpected difficulties. This is the heart of agile, and most managers and other higher ups simply can’t understand this. After all, managers make plans, that’s what they’re good at. What they don’t understand is that planning is also an agile process, just like development. It’s not a one-time affair, done at the beginning of a project. Plans should be as agile as the code. Whether it’s code or specifications, things will (and must) evolve to meet ever changing needs.
I know all the software engineers reading this are probably outraged by the comment regarding the teams coding and design abilities (and you have every right to be), but let’s look at this from the managers perspective. As a manager I need to be able to estimate everything so that I can create a schedule and then make the dates for my deliverables. If, as a manager, I hear the word ‘refactor’, I get scared. I get very scared. I automatically assume that my engineers are idiots and didn’t do enough design work and I start enforcing up front design sessions and FTR’s and formal ICD’s and start padding the schedule.
As developers we know we can get it done on time and with high quality, but part of that process is ‘refactoring’. Refactoring does not mean re-writing the code. It doesn’t mean that we introduce more bugs (although it’s not out of the question). And, most importantly, it doesn’t usually mean a cost increase. The point of refactoring is to make new development easier. We refactor in order to make new functionality fit with current functionality or simply to make the code more understandable. According to Martin Fowler, refactoring is ‘a disciplined technique for restructuring an existing body of code, altering it’s internal structure without altering it’s external behavior’. While not every refactoring goes as planned, for the most part we’re pretty good at refactoring. The problem always comes when we accidentally create a few bugs during the process. While refactoring is supposed to ‘not alter external behavior’, we’re only human and it’s unlikely that we don’t cause at least one bug with our refactoring. This is what management sees. What they don’t see is the countless hours fixing new bugs and working new functionality into the existing code without refactoring. We as developers need to be more diplomatic when we talk about ‘refactoring’ and communicate exactly what we mean. Lumping everything into the ‘refactoring’ bucket doesn’t do anyone any good. While it is never going to stop managers from accusing us of indolence, it will go a long way toward building mutual trust.
The other important issue I’ve had with ‘agile’ managers is their definition of scope. Every member of the project (developers, designers, business, marketing, etc.) wants to make the product the best it can be and developers are no exception to the rule (in fact we usually want our products to be perfect more than anyone else. After all, they are our babies and we don’t want to let them out in the world until they are ready and at least 18). Agile managers tend to not understand what ‘scope’ means. I’ve had managers who would not let us change a field name on the UI because it was a ‘scope’ increase (even though every self respecting developer would argue against it) and yet defining performance criteria a month before the release date was not considered a scope increase (the performance requirements were never defined, but our code can handle 2000 items in the UI without a slow down, right?). Communication is key to avoiding these issues. Just as developers needs to communicate ‘refactoring’ more effectively, managers need to communicate the business issues more effectively to the developers.
What I’m trying to say is that an ‘agile’ manager needs to be just that, agile. You can have agile management without agile development and agile development without agile management. The best scenario, however, is when both parties are agile and understand each others needs. Agile managers need to make agile plans and agile developers need to have agile code. When both sides understand each other, then ‘agile’ can really work and open communication is the key.
iseonsoftware 