Agile Software Process and the Thoughts of SELISE CTO
HR: What first comes in your mind when you think about the Agile Software Development Process? A process with uncertainty, risk and insecurities or a process with flexibility, communicability and transparency?
SN: Well, according to some recent surveys, over the past few years agile process is gaining increasing popularity as the best approach to develop software in a more efficient and effective way. Many people agree that Agile is the utmost way to develop software, but there are also many other people who say it doesn’t work. The truth, of course, falls between the two extremes and depends very much on the situation you are in.
Shah Ali Newaj, Chief Technical Officer (CTO) of SELISE, expressed his thoughts and views with us while he was recently interviewed regarding the fast-evolving and contentious issue of agile software process. Lets have a look at what opinions he shared concerning the facts of agile software development process :
HR: Why Do you think that Agile Process is the best practice for software development?
SN: Well, let’s check the alternatives first. All over the world, people are developing software for a long time. And for a long time, software process such as Waterfall, RUP and others have been used besides Agile. In the nineties, one kind of revolution started in software which brought in a set of concepts that would deal with the risks and the challenges that the traditional software process have faced over decades. These challenges were mostly of the kind that all these traditional processes would use software as in an engineering term.
Now in these traditional processes software engineering is perceived as a very quantifiable, measurable, and estimable approach as any other engineering process but later, the industry found out that software is indeed not an engineering process. It is more of a creative and a non-deterministic way of doing things. For this reason, the traditional processes have been completely unable to handle such indeterminacy. And that is where the agile process came up and says, ” hey! Software is a craft and it’s not engineering. Yeah it has some engineering pertinent but mostly it’s about creativity and people who build the software, they actually matter.” In engineering, the person who is working in a engineering process does not really matter that much because you can replace him with another person or another machine and still the result would be the same. But in software development, if you bring in one guy and replace him with another, the result of the look, or feel or behavior of the software could completely change because of the person – this is an important point.
The second point is that the software is more of a thing that requires changes whereas in engineering, changes are not very prominent. In software, when people see things, their idea starts to evolve and software processes somehow has to be able to adjust to these changes. So, this is where the traditional software process lacks.
And then, the final point is, the software process has to be dealt in a way that people can collaborate with each other. Traditional software process forces the customer to sign off contracts, have the delivery based on that contract. But agile software process allows the customers and the developers to collaborate with each other and define what needs to be built, and deliver that. So, these are the specific reasons for why we are using agile as a software development model rather than the traditional approaches.
HR: What is your thought about the adaptability of this process?
SN:Firstly- It requires a change of mindset. People who have worked with traditional processes and suddenly when they switch to agile; the first thing that stuck in their mind is “Where is my specification document? Has it been signed?” or like ” No way, I am not going to accept change!”
The first thing about Agile is it’s philosophical. You have to understand the philosophy, you have to get infected with it in your mind, you have to be in that world then when you are inside that world, you will see that lots of new doors and windows will start opening and that it will allow you to build software in a different way but in a better way as well.So those issues about adaptability, people do not feel comfortable when they start but when they really go into it, they feel much better and they can do things in a better way.
HR: Well, how can a company follow this process in their projects?
SN:First, the company has to decide. It has to be done all the way from the developers, from the guys who is coding to the very top management – all have to agree to do it in this way. And every person has to be very convinced and motivated that they really want to do their production in such a way. Once they are convinced, there are lots of resources available out there, which you can go and read. There are very standardized processes that can be picked and start implementing it but you have to be very careful because you simply cannot say that “ok, I am going agile and take scrum and I will do exactly by the book word scrum says.” That never works!
Each company is different. They are made of different people. So, you can take one standard agile process but you cannot simply do it by prescription. It’s more like you have to customize your agile process with the spirit, with the people; with the mind of your team, and that is the only way to do it. You cannot say that ” Well, we had an agile training and now we are agile” – It’s not like that. It’s about the practice.How you do things, what challenges you face and how you mitigate those challenges. That is the process of adapting. It’s the natural process. Well, it has to be. I would say, it is kind of biological. Inside your company, it has to be biologically evolve.
HR: Have you faced any challenges while following this process?
SN: Yes surely! Actually, you can say, there are two different kinds of challenges. One kind of challenge is inside your team like to convince them to move into agile, to deal with this new approach of development etc. Sometime people feel insecure with this process. If somebody is not capable, probably he was hiding something in his pocket. And now with agile, everything come out.So, that is some kind of challenge inside the team but that can be overcome if you have the right kind of people in your team.
The second kind of challenge is dealing with the customer. Because in many cases, customers are not very agile. It’s because they may have been working with companies with traditional processes or they themselves could be a company with traditional processes and when you tell them that “Hey we got a company, we work with agile processes and they are not very comfortable” they say, “okay, we want a 400 pages requirements specifications, software design document” and so on. But we do not have those documents. We really don’t build them. We build smaller documents, we go and change those documents and build it up over the time. So, for companies, who really want to work with us, they have to also take some philosophical ideas from agile and build some kind of capacity in their house to work with us. So, that is another challenge to convince the customer to operate in such a way.
HR: What kind of values does it add to the whole software development project?
SN: It adds a lot of values actually. The first value it adds is the transparency. The customer can have a look at the software from the very first day it has been built. And then we work in very small sprints, limited releases, two weeks is one sprint and then we have release after each 3 month, and after each sprint, customer will have a demo from our side, they can see what we are building. The customer can drive the whole process; they can say what they want and what they don’t. This information can be absorbed by the team and team can change their plan according to the need of the customer. So, I think, that is of a huge value from customer side.And this is some kind of flexibility for a customer to ramp up or ramp down, speed up or slow down- this kind of flexibility the customer can have. We have also different kind of flexibility such as the team can decide what work they want to do; they can estimate the workload and thus their life become better. The developers work with us here- enjoy better life because of the reduced work pressure and there is always very clear communication with the client.
HR: So, are there any wrong perceptions about this process?
SN: There is a comic that I remember. The program manager comes to the CEO and says “we have a project and that requires three more people.” And then the CEO says, “No no… go and use some agile process.” Then the program manager says, “But agile process does not say that you can do more work with less people.” Then the CEO says,”Then find some other process that does.”
So, yes, there are some wrong perceptions. Some people think, it’s like a silver bullet. And thus, some people think if software is failing, they can just bring Agile. But Agile is not a silver bullet. Agile does not solve your entire problem. If you do not have the right kind of people, if you do not have the right kind of capacity on the customer side, if you are not very committed to do such deep integration between development and the business side, then agile fails. Agile processes can only be succeed, when everybody- the customer side and the development side are very committed and they all have brilliant people – only then it can succeed. It is not a very rigorous process, it is quite loose, its quite chaotic, but the idea is to contain the chaos in a way that inside that container, the whole software process is very fluent, very communicative so that the built software becomes very strong.
HR: Is there any specific way to follow this process or different companies use it in different way?
SN: Agile is an umbrella term. Inside Agile, there are very specific processes such as scrum, Extreme Programming XP, Feature driven development (FDD) and so on. So, these processes, each of them have been talking about quite specific kind of a way how to do them. They have very clear artifacts that you should produce while in work. The companies usually pick one of these specific processes and adapt it to their own needs. So, I would say companies can take standard process inside agile but it will never be that two different companies following the same process such as scrum but doing everything exactly the same way.