I have always asked myself during the period of my studies: Are agile methodologies good for software projects? My answer is “Yes”, they are good but not enough. And then I asked myself why they are not enough? What I have seen in the last 10 years shows that just following the agile methodology does not solve all problems. Let’s take a closer look in the three fundamental goals of agile software development to move forward into the future mentioned in Michael Dubakov’s post “The future of agile development”. Every other company in the market wants to „Build the right software” which is also the ultimate goal to generate revenue by catering their users with what they want to see and use. Most of the companies following scrum methodology have done reasonably good and has also generated huge public interest. To understand the needs of its customers, they have created a feedback cycle where the customers are also involved directly or indirectly. These interactions with the customers provide valuable information and many of them are golden opportunities to improve.
The second goal which arises is „Do it the right way”. Often when you create the right software, the job is half done and if it is not done the right way your mission is not complete. Users might be able to solve their problems but with an in-stable software which might crash now and then. When software is poorly coded it is very ambiguous, it might look good on the user interface and also might prove helpful but a reality check could reveal it is a train-wreck which could rattle anytime.
Most of the software companies have already implemented a methodology with a goal to test ideas first and check its viability, which also highlighted the third goal of agile software development: “Need for speed”. Normally these test ideas are transformed into working software with very few unit tests and a lame architecture/framework in the need to launch the idea to a targeted audience as fast as possible and prove that the product concept is viable. Eventually, when the product concept works, the whole software block is rewritten right from scratch, keeping in mind the architecture, framework, scalability, and performance with lots of unit tests which might take a few more sprints. So this shows that „Do it the right way” is time-consuming and sometimes fails to catch up with the needs of the users.
When projects are getting complex, the speed drops due to the various factors attached to “Do it the right way” and this speed factor is very important for any competitive company. It is necessary to create software fast so that the firm can test the product concept and its viability. Once this is done the company gets a second chance to try various options to tune it to the user’s behavior and also “Do it the right way”. If a firm does slow work, there would be no second chance and probably would fall to the competition in the market.
Therefore, agile development process should “Build the right software” with the “Need for speed” and “Do it the right way”. Thus we have a development process with clear goals which should guarantee success (hypothetically). But the question that arises in my mind now is: How do we keep all these three goals in sync?
The circles in the above figure depict how the three goals would overlap each other and also show some pros and cons. It also shows the ideal situation for software development. When “Build the right software” overlaps “Need for speed” without taking “Do it the right way” into consideration it would work for trying out new product concepts. But it would also mean putting off problems to a later date if the product concept is viable. This could be expensive at times.
When “Build the right software” overlaps “Do it the right way” without taking “Need for speed” into consideration it would mean that the company is likely to hit the jackpot if it has no competition. But the firm could completely miss out on market opportunities if the product concept is viable due to slow speed or the company would make huge losses if the product is not accepted in the market.
When “Do it the right way” overlaps “Need for speed” without taking “Build the right software” into consideration meaning the company will have a wrong product in the market which no one needs. The company could learn from the market reaction and understand what went wrong and make fast changes. Ideally, this situation should never happen if the product team has done its homework.