The debate of agile-based methodologies versus waterfall-based methodologies is one that has been raging for what seems like forever. With the evolution of network management into a software-like, programmable discipline it will soon find itself front and center with an audience that has never had to care about it before. Are we there yet? Not quite, but the time to learn about this and make some key decisions is BEFORE you get there.
Old school development shops will swear by the waterfall approach. This means a series of very specific phases that each must end, or be very near the end, before the next phase begins. Most will be familiar with the “Discover > Define > Design > Develop > Test > Deploy” path, or something very similar to it…words may vary in naming each step. Looking at an example diagram below it becomes blatantly obvious where this approach gets its name:
The shortcomings of this approach boil down to one major issue. It is simply not very flexible, meaning that it is highly vulnerable to a change in requirements or scope…especially once you are substantially down the road to a finished product. Change can, and will, “break” waterfall-based projects.
It seems logical that the answer to this inflexibility would be named “Agile”.
In an Agile approach the goal is to do things in a very iterative manner, consuming a small set of requirements at a time and producing subsets of feature/functionality very quickly for delivery to the customer. A typical representation of Agile is shown here:
It is always a goal for an Agile-based project to deliver value over time versus the “big bang” approach of Waterfall-based projects that attempt to deliver a huge chunk of value at the very end of the project.
Now, this blog isn’t trying to teach the details of either Agile-based or Waterfall-based project management, but some level setting of each approach seemed necessary. This disclaimer is to calm those that will point out how much I glossed over what Agile really is…those details will come in a blog about the Itential Methodology. Instead, I aim to make a few points as to why this all matters to begin with:
- First point, the world in general is not static. Very rarely can you define a set of requirements that are going to take 6 months (or more) to complete and not have something change along the way to invalidate at least part of what you build. This is true regardless of industry, but especially so in technology domains such as network management. You must be able to consume changes and adjust to the impact of those changes.
- Second point, adoption of an Agile-based approach is not something you do halfway. A lesson learned at Itential is that a project is either Agile or it is Waterfall. Any attempt to appease those people stuck in the waterfall mindset is asking for trouble. The result of relaxing the methodology is not pretty…for the customer, the partner, or us. Once again, if you are playing at Agile by maintaining your waterfall mindset you are just outright fooling yourself.
- Third point, Agile-based management of projects requires participation from everyone. A critical component for success is constant, accurate communication between all parties. This communication must be timely, whether that means a daily SCRUM/standup or the creation of a real-time Kanban board that all members of the team can see at all times, everyone has to be on the same page. Changes must be known immediately so that they can be analyzed and incorporated into the plan. Issues must be known immediately to ensure timely resolution. Communication must be 360 degrees in nature, meaning any project participant must be able to raise concerns in such a way that one person/entity is not a bottleneck for resolution. It is amazing how often this last item is an issue.
In conclusion, and to answer the question that is the title of this blog post, yes…methodology matters.
Networks, Services, and Applications are evolving and the way we manage them must evolve as well. We can’t keep doing it the way we always have.
This evolution has turned the dial to 11 on the changes assaulting us on a daily basis. We cannot continue to use a methodology that is broken by change. We must evolve to consume this change, as fast as it can be thrown at us, and thrive on it…not be destroyed by it.
We cannot continue to fool ourselves by trying to evolve halfway. We’ll discuss more in another blog post about the Itential Methodology, but the bottom line is be Agile or fail…