Menu
As before in this series, we will tackle this question with the aim to talk to non-technical decision makers. When about to decide on spending money on the development of a piece of software, you may wonder how this is going to happen and why on earth so many people spend time and energy talking about a thing named “Agile”.
So, let’s start with the beginning:
In essence, a process is the scripted list of action ones need to go through in order to achieve a specific goal. So, cooking pancakes follows a process that can be described in a “recipe”. Changing your car engine oil should be done following a specific set of actions. Some process are particularly light and flexible (i.e. few rules that could be executed in various orders without having a negative impact on the end result), others are extremely rigid and heavy. Quite naturally, we tend to dislike heavy and rigid processes. Now, if I am asked if a rigid process to make sure the plane I am about to travel with is in good condition is a good thing, I’ll surely answer “yes”. Usually, the more dangerous the action, the more rigid the process is. For life threatening activities, humans have developed very serious and rigid processes. We dislike heavy processes, but we dislike dying even more. A proper process in place is offering the benefit of safety without to reinvent everything from scratch. The person in charge of my plane security is going through a pre-defined list that guaranties he/she will not forget any step. I am safer like this!
In short: A process is a list of steps one needs to go through to achieve a specific goal. Humans have mostly developed processes to reduce risk.
Just like any other process, a Software Development Process is describing what steps the team must go through in order to achieve the desired result: a working piece of software.
UNLIKE the process for checking the plane, a software development process cannot be a linear list of actions. If you have read the previous articles in this series, you know that there are much more activities than meets the eyes. Let’s have a brief look:
Presented in this order, it may look as a linear list of actions. In fact, there was/is a well known process that is linear: Waterfall. With this process, we more or less take the list of tasks above and perform them one by one until completion. Once each task is completed, one moves forward to the next task. If this looks easy on the paper, in reality it really does not work well. Very few projects are compatible with this approach. This is why new Processes have been invented, described and applied in time. To cut a long story short, the latest type of “Process” is now named Agile.
Agile was born after decades of failures and software development suffering. It basically starts from the realization that software development is hardly predictable and surely not linear. The objective is to reduce risk by adapting the project to the reality of life and life is full of unknown. As we admit from day one that we cannot know everything, we’d better prepare for change. To prepare for change is being “Agile”. So, if during the course of the project a new law is voted (in the banking world, this is not a rare thing at all) and it has an impact on the project, we’ll be ready to integrate the new constraints into the project.
The Agile adopters are extremely reluctant to call this even a Process. But for the sake of simplicity, you can safely put Agile in the Process box, if you consider Process as a documented strategy to achieve a specific goal.
For the record, there is something called the Agile Manifesto that describes the motivations for this approach. It is summarized in 4 values:
…and 12 Principles:
There are many flavours of Agile like: Scrum, eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), and a gazillion of various adaptations of Scrum. One does not have to put all these methodologies in opposition. It is often the case in the IT world to fight about what is the best practice. I think that any dogmatic approach is suspicious. I do not see how one can be a dogmatic practitioner of Agile Principles. It sounds very much antinomic to me.
If you are a decision maker with no specific technical background you may wonder what to conclude about that. The conclusion is that your project team, in order to succeed will have to perform a huge number of tasks. You will want the team to get organized (follow some sort of process) while remaining flexible and adaptable (Agile). I suggest that you have a conversation with the team about the “Process” of choice and how they intend to deliver the project. The more you understand their organization, the better you can help them deliver to you and the better they will be able to deliver what you need.
Unlike what some think, a Process is not a pain in the neck but a compass to help you travel in the land of Software Development. Pick your compass and travel safely!
Contact us for more information.
This article is #4 of a series on Software Development for Non-Technical Decision makers. This series contains or will contain:
Liemur provides Software Development Services within UK and with its nearshore branch in Budapest.
Contact us for more information.