Adopting an Agile Software Development Approach
Adopting an Agile Software Development Approach
A Case Study of Primavera Systems Enterprise
Introduction
Primavera Systems is a company that usually focuses on software development intending to offer real-time solutions to their clients. Notably, with time, people change their needs, which means that Primavera has to match those changes. This calls for new innovative approaches in every subsequent release to attain competitive advantage. Markedly, when customer needs are not meant, there is a high chance that they will turn to competitors, however loyal they might be. This was an eventuality that Primavera had already foreseen if they continued using the existing developmental approach. Generally, they were using a top-bottom approach where managerial team would give design layouts to the development team, which was required strictly follow them. This leads to similar unsatisfactory results in all their releases despite working overtime during the projects. As such, the enterprise decided to venture on agile software development, and they selected the Scrum approach since it was the most viable option.
Problems Prior to Adoption of Agile Strategies
Primavera enterprise had been in the software industry for quite some time and had successfully developed solutions to numerous client’s needs. However, as time went by, they started getting complaints from clients due to some missing functionalities in their software. Even though they noted these complaints, the development team was not in a position of addressing them since the management had the final say regarding what the final project should look like. As such, they would release subsequent software with similar bugs as the previous ones which made clients question their seriousness in responding to customer feedback. The development team was also exhausted from pushing themselves to the limits, working on overtime, and then at the end, they released software that was not appreciated.
The final nail was driven in March 2003 when they tirelessly worked in a project which they believed would awe the customers. They were very proud of themselves because they had delivered exactly what was on the layout plan, if not better. They even went to the extent of celebrating upon completion since they believed that the massive changes they had made in the software would surpass the expectations of their customers. Upon release, they realized they were wrong since most of the feedback was about complaints, customers claiming that the software had usability problems, quality issues, and some missing essential features. The development team was very frustrated and disappointed with the customers since they didn’t seem to appreciate the sacrifices they had made and the effort they had put towards the project. It is then that they realized that the problem was not with the clients; instead, it was a failure with their software development strategy. The team needed to adopt a strategy that acted on customer feedback ensuring that customer suggestions are incorporated in subsequent releases. This was when they decided to be agile.
Viability of Agile Techniques in solving the problems
Agile Software Development is a technique comprising several software development approaches under which the solutions and requirements evolve via a collaborative effort of cross-functional and self-organizing teams alongside their customers. The techniques advocates for continual improvement, early delivery, evolutionary development, and adaptive planning. Primavera system decided to settle for the Scrum approach mainly because it was the most feasible option in regards to the company’s policies. Also, Ken Schwaber, one of the Scrum creators, had ascertained that the approach would work and even offered to coach the development team. This approach would divide the development team into sub-teams, each with a product owner. Since the product owner would be from the marketing department, the sub-team will be adequately informed on the features to include in the product. The approach required them to work for 40 hours per weeks meaning that they would no longer have to work 18 hours a day. After every development sprint set at 30 days, the sub-team presents their progress, and an evaluation is made depending on market needs. If there are customer additions or bugs that need rectification, it is done in the next splint. This is like dividing the project into small milestones, ensuring the development team is sailing in the right direction. Markedly, it is easy to implement suggestions when they are delivered in small bits compared to a bulk of complaints and suggestions after project completion.
Challenges during Agile Adoption and how they were mitigated
The enterprise was making a huge gamble in trying to transition to agile methodologies since it was a complete sweep of the system. In case of failure, the company would both clients and finances. As such it was prudent to ensure that the transition was made in a very cautious mentality, especially when addressing the challenges. There were several challenges along the way, with the main one being the desire of development teams to showcase new accomplishments in every splint. As such, they would hurriedly write down the program, and in the bid to impress, the presented software would have bugs or lack some features due to inadequate and incomplete testing. Another challenge was focusing on short-term deliverables due to the project being divided into splint, and along the way, it was straightforward to lose track of the final goal. Finally, there was lack of accurate metrics in regards to the project completion dates which was a significant concern for the stakeholders. Markedly, even though they could easily keep track of the project’s progression, its flexible nature meant that it could take unforeseen turnaround during development, which could either shorten on lengthen completion time.
The good thing is that these challenges could quickly be mitigated ensuring a smooth transition. The development team was supposed to follow the few Scrum rules. A clear criterion of what a completed feature entailed ensured that the development team thoroughly worked on the project before presenting it at the end of the splint. Also, the teams were assisted when breaking down their work to ensure that it was deliverable within the set splint. Finally, to ensure that much of the time is not spent on rectifying bugs, the enterprise reemphasized its prior engineering practices, which ensured that the number of bugs introduced in the early development phases was minimal.
Why Agile Approach was productive than Traditional Methods
The agile approach uses an incremental pattern rather than the renowned waterfall method. Through these techniques, Primavera was able to attain transparency whereby clients were involved throughout the project development this way; they could know more about the features being added and also give their views. The approach also allows for change since the development team gets the opportunity to reprioritize and refine their product backlog. It is easy to change or introduce new backlog items in subsequent splint. As such, it only takes a few weeks to implement changes. Finally, this approach focuses on users, prioritising their needs when developing the software. As such, every feature improves the overall value of the software.
Business Development since Agile Approach
In the first nine months after adopting an agile approach, the enterprise recorded a 30 percent increase in the quality of products in relation to the defects reported by customers. Also, due to the reduced number of defects, the development team has enough time to focus on the next releases instead of working on existing bugs. One of the significant achievements is the reduced product release duration whereby, at one time, the development team was able to deliver two parallel projects within 14 weeks. This was far better than what they would achieve with the waterfall technique, and most probably, if they had used the waterfall technique to rum parallel projects, the chances are that they would be forced to consolidate them along the way. Considering that they finished the parallel projects 4 months earlier, they had extra time to focus on other business aspects improving economic growth.
Conclusion
In a nutshell, by shifting from waterfall to agile software development techniques, Primavera has managed to address the customer needs, hence releasing valuable and profitable products. The development team has also been given freedom of being more innovative, which has wholly diversified the releases in relation to the evolving client needs. The team also doesn’t have to strain for very many working hours, and in the end, their efforts are unappreciated. They currently work for a few hours, and the results are very appealing to the customers.
