For us, a rockstar developer here of course is not the super crazy guy who blows up the stage and defies the rules but the cool guy who with his extreme talent gets things done just like snapping your finger. A rockstar developer doesn’t picture himself as a “megastar” or “idol”. He is someone with proven excellence and advanced knowledge, is reliable and can work under huge pressure along with the team. You can see him participating in different spheres of the software community and often stand out with his own work and contributions. He is someone you can definitely respect and look up to. According to the article “Top Ten Traits of a Rockstar Software Engineer” on Read Write Web, the top ten qualities in a rockstar are:

SELISE Rockstars

1. Loves To Code
2. Gets Things Done
3. Continuously Refactors Code
4. Uses Design Patterns
5. Writes Tests
6. Leverages Existing Code
7. Focuses On Usability
8. Writes Maintainable Code
9. Can Code In Any Language
10. Knows Basic Computer Science

What does a Rockstar possess? Fame, ego, talent, unbelievable passion and maybe brilliance to the point where they self destruct. But the question is when did programmers also start to share the same qualities? Well as the demand for technology professionals went extremely high it became a race of exposing yourself and showing off. This race with time gave many successful programmers the sense and virtual fame of a rockstar and as a result they became in charge of their destiny. Without any doubt these are the people we want onboard with us. Here at SELISE we consider two things in a rockstar developer: talent and passion. We tend to believe no one can just become a rockstar by reading books because being a rockstar comes with not only analytical brilliance but also with passion that you either got or you don’t.

When we choose our rockstars, we strongly emphasize on his or her substantial domain knowledge and experiences. We always look for a wild combination where the guy has talent, passion, creativity and the bravery to expose his work and ideas. So we follow a strategic way to recruit the rockstar developers since they are vital to our each and every project. Compared with other software firms we ensure that abilities and talents are properly utilized here at SELISE to get a result that is truly rewarding! One of the things that we are very conscious about is providing a flexible environment where rockstar developers can exert their optimum level of creativity. To keep them updated about modern technology and what happens on the client end, we give them proper training, send them to onsite visits at different clients all over the world. From the initial stage of a project they get full freedom to discuss issues and concerns with our clients. At SELISE we provide state of the art facilities and benefits going beyond industry standards.

So that’s the answer to the widely raised question among our competitors “Why Do They Rock So Hard?”

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.

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.

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.