With this article I want to shortly describe how my understanding of “Agile” evolved over the years. You will find this helpful if (1) you are unfamiliar to Agile, (2) if you heard of it, read through it but never experienced working with it and (3) if you are looking into introducing an Agile methodology or framework such as SCRUM, SAFe or Kanban in your workplace.
While studying my Computer Science bachelor I remember having a lecture on software development methodologies and frameworks. We started by discussing the waterfall approach. Most of my teachers used to work for the banking industry in the mid 90’s and were used to a waterfall like process. Months of upfront planning, legal documents and strict definitions. As a rule of thumb, they would state that up to 70% of the time would be invested in planning without ever producing functional software. At the moment it seemed pretty boring to me as it left no room for creativity, for self organization or to tap on opportunities that might emerge from building your product.
The lecture continued to Agile methodologies. It immediately caught my attention. First and foremost, when you hear the word “Agile” you think of ninjas, of wolverines, of Spider-Man. As I read through the Agile Manifesto and the Scrum Principles I felt that whoever wrote them was rebelling. I kept reading things like “respect” and “courage”. I think at the time it was exactly that: a bunch of really smart, committed and courageous fellas figuring out that software was art and stating it out loud.
Back then, to me all sounded like the kind of approach I would like to follow. As a student I misinterpreted the Agile ideas and wrongfully over simplified everything to something like:
- Agile -> Everything will be faster, we are ninjas!
- Individuals and interactions over processes and tools -> No process is needed and we are all friends.
- Working software over comprehensive documentation -> No documentation is needed. Let’s code until our fingers hurt.
- Customer collaboration over contract negotiation -> No contract is needed.
- Responding to change over following a plan -> No plan is needed. We will just wing it.
Fast forwarding 10 years, after many jobs in many industries I can say I get it and that none of my conceptions were right. This is how I see them now:
- Agile -> It is just a name.
- Individuals and interactions over processes and tools -> Processes and tools are developed to streamline a result, to make tasks easier and to reduce effort to a minimum. Still, any kind of organization, from small groups of developers to huge coorporations should be vigilant of their processes and tools. In all cases you want to make sure they keep adding value and making things easier.
- Working software over comprehensive documentation -> No matter how much you document a project, a working piece of software is king. This said, I want to emphasis that documentation IS CRITICAL but there is a sweet spot to it. No or few documentation will hurt communication inside and outside your team. Extensive documentation that is never going to be read by anyone makes no sense.
- Customer collaboration over contract negotiation -> Providing the means to fulfill a need is the most important thing about building software, or building any product for that matter. This should rule our interactions. Solving the problem is more important than figuring who is supposed to do what and who gets the blame when something goes wrong.
- Responding to change over following a plan -> Again and similar to documentation (planning is a kind of documentation) there is an ideal middle ground to planning. Do not get into a place were you plan too much; you might get “analysis paralysis”. You do not want to plan so little that you end up having no clue on what to do next.
I must admit that the evolution reflected above is the product of 10 years of personal/professional growth. Still this can be a shortcut to some of you that might be one the starting point or anywhere in between or even farther than where I am now. Regardless of your experience or the framework you choose to use, and whether you got it right on your first read or you had to take some years like I did, Agile is a concept that is best understood in practice. So go ahead and try it out for yourself.