Tales from a Developer’s Life – Waterfall vs. Agile

The New Project – Happily Ever After

For a developer, there is nothing more exciting than getting a new project to work on. There is probably a common misunderstanding that being a software developer is a routine, monotonous job where you perform the same activities day to day. My personal view on being a developer is more like being an artist; it requires inspiration and the experience is never the same. We start a project from just an idea, we like to work in solitude, we often get upset about what we create as it is never perfect and we need a muse that drives us and makes us deliver that final piece of software. I cherish that first stage when we put so much thought into the design and the technologies we can use. There is always an opportunity for us to learn something new, not only on technology but also domain wise. Working for a consulting company has given me the opportunity to learn a lot about different businesses, companies and corporate cultures. You see, a developer is like a chameleon; we need to adapt and understand the business, the needs, and the expectations of the final user so that this will carry over to the software we are building. We have to study and adapt to the requirements, as the only thing that truly matters is the customer satisfaction. These first days of a new project are the most exciting and full of inspiration as to what can be achieved. This idea of a software is now growing and forming. There is nothing that can stop us now, we are on a roll and we will deliver!

The Implementation – Gloom and Doom

It sounded like I was telling the end of the fairy tale in the ‘happily ever after’ chapter. So one might wonder why the gloom and doom all of a sudden. The excitement, the drive, the commitment are all good building blocks for a successful software development, but are they enough?

So we have started our development and everything is going great. We have the requirements down, the technologies we use are rocking, we are learning new things, but … things somehow still can go wrong. What has been our typical development cycle (often referred to as waterfall) seems to have fallen short especially for lengthier projects. There is the assumption that all the requirements will be gathered up front. We will be developing for say couple of months, then the software is demoed to the user, they test it and … well imagine Niagara Falls roaring and falling on you. The customer is unhappy, the software is not what they were expecting, and some of the requirements were misunderstood. Oh by the way, we have also missed requirements and some of the functionality is failing, and on and on. Frustration is building up; the management goes back and forth with the customer as to what is/was in scope and what not. They need us to make all these ‘cosmetic’ changes; deadlines are pressing on us; and we end up overworked and overstressed.

The Implementation – Magic Stream

So is there a silver bullet to all that? Probably not, however here is what we have learned.

1. Requirements will change and that is a definite statement. Yes, the client’s ideas and expectations are as fluent as water. Different currents make them change direction. It could be the market today, new budgets, ideas that have just occurred. Something that was extremely important at the beginning of the project is now for whatever reason not important at all.
2. Since I am a developer please forgive me this one line of code:
   1. if (#1 (above) == true)
      1. How can we develop successful software without being in constant touch with our customer who by the way is the source for the product?
3. We need to know where the current is taking us otherwise we will end up on the other end of the waterfall and it is never easy to muscle the project out at this point.

Obviously something in our development cycle needed to change so we started to adopt the agile development approach. First of all, we established a 15 min Scrum meeting every day rather than the once a week endless status meeting. This way we never lose touch within the team. This also ensures obstacles and questions are resolved quickly. We started following 1 or 2 week sprints, depending on the project. The work for the sprint is backlogged in advance based on the input from the customer of what is most valuable and important. Since this is a relatively short period of time, changes are less likely to occur at this point. The team gets together for a planning meeting and we clarify the requirements and agree upon the estimates. The development proceeds, and at the end of the sprint we have a sprint review meeting where we demo the completed features to the client. This is priceless because we get valuable feedback, things to change, things to add, something they don’t like or find clunky. This could shift the direction completely for the next sprint (deadline).

Remember the waterfall dropping on us previously? Well think of this as more of a stream now, and we can very well handle a stream. You know what, we can even change directions at this point. In fact, we review our performance for the sprint and decide on what we have done well and what we can improve. We continue repeating this process with an intended goal of continuous improvement so that we can deliver a steady flow of valuable information to the customer featured in each sprint.

The Morale

The point? With Agile, the customer, who is the soul of the product, would never lose touch. The software, at the end of the day, will be the customer’s creation as much as it is the developers. They get involved rather than being passive. They get more insight into the development process and understand the workload. They get familiar with the software and they get trained in the process. They get to test small modules much earlier than the dreaded deadline. Because of all this, the customer will appreciate the final result.

As developers and especially for a consulting company, we have to deal with various projects. Agile is not the miracle pill for everything; however we do have the knowledge and flexibility to choose either development methodology approach depending on the better fit. Does Agile present us with challenges? Certainly, but that’s for another blog.

In the end, customers and developers (being a software consulting company or the individual programmers) are shooting for the same goal – working, functional, and user-friendly software. The biggest gratification for us as developers is having the software used, knowing that it is in the hands of the end user, and that it helps with daily routines, automations, and in general is making somebody’s life/work easier.