From waterfall to agile | A developer's point of view

The transition from a traditional “waterfall” project development approach to an Agile cycle has been well documented both from the perspective of a client and as an organizational process shift. Approaching the same topic from a different perspective, I am Jerrod Long, the newest member of the production team here at VIA Studio.

Before joining VIA I was a developer in a traditional waterfall environment. Learning about the tenets and successes of an Agile development cycle intrigued me, which lead to research, which beget study. Finally, I decided I had to experience it for myself.

When the opportunity arose to to work with a development team in an Agile process I jumped at it. I knew going in that it would it a change in the manner in which projects were planned and executed, I did not know it would lead to fundamental changes in my development approach.

From concrete to educated conjecture

From the start of a waterfall project, the team tries to determine every minute detail of a project from a few meetings with the client and a lot of internal discussion. Trying to detail three months of execution across multiple departments and requirements inevitably fails in direction and execution.

Going into client meetings focused on trying to spec the technical details of a project leads to a linear line of decision making. The client mentions the need for regularly updated content and a developer hears a blog is a project requirement. A cause and effect type of relationship builds where upon hearing a need for the client, another feature is determined.

What does that have to do with development? In an Agile environment, the early planning is focused on learning instead of feature definition. This creates an environment where information drives decision making instead of trying to define what is needed at the start. We make informed decisions based on what we know now, with the caveat that the plan will change as we learn more.

The lack of a rigid structure may initially feel like a lack of planning to those unfamiliar with an Agile cycle, but that is not the case. Creating a MoSCoW document, listing the components a project Must, Should, Could and Won’t have, allows us at VIA and our clients to make decisions based on the most recent, and therefore relevant, information instead of rigidly adhering to a technical specification defined at a less informed time.

For instance, in a project we are currently developing, a feature has risen from the Could have list all the way to the top of the Must have list. In a more traditional waterfall approach, if a feature goes from low to high priority, problems can arise. Either budget, timeline, or quality will be effected in order to fit (force?) the newly prominent feature into the forefront of the project. In our Agile approach, we simply moved the development of the feature from near the end of the project to the beginning to ensure a properly planned and integrated solution.

From general to specific

One thing my previous, waterfall-oriented team left out of our project planning was a clear hierarchy of importance for each feature of the project. Although we were able to determine a slight hierarchy, all features were still considered project critical. To refer to the MoSCoW documentation from earlier, everything was on the must have list.

With all features considered project critical, a lack of clear direction as a developer can occur. You have your list of requirements but no real starting point, as they are all of the same importance level. This leads to obvious problems. Where do I start? What if a new feature gets added to the project? What if one of our ideas is not functionally possible given the project constraints?

We eliminate these problems by using our MoSCoW to determine our MVP, or minimum viable product. Determining this gives you a clear path to completion as a developer. Where do I start? Whatever feature holds the most prominence in the project. What do we do with a new feature? Determine its level of importance relative to the other requirements and place it in the MoSCoW. If the new feature is actually project critical and going to require a large amount of time, our team works with the client to determine the new project hierarchy. This approach not only allows the direction of the project to evolve our understanding of the end goal, but gives us here at VIA a clear set of directives on what to develop next.

I could have never imagined, before starting at VIA, that adapting to a new approach to project planning would have such a profound effect on my outlook of project development. The Agile approach alleviates stress and increases my level of productivity. I am greatly looking forward to continuing my growth here at VIA and the project development opportunities that will drive it.