CSC/ECE 517 Fall 2011/ch6 6e ch

Agile Methodology

Agile methodology is a repetitive and incremental process of managing projects where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams and is majorly used in software development. Implementing this methodology benefits the team by having them respond dynamically to the unpredictability of building software through incremental and iterative work called sprints. These sprints provide project managers with several opportunities to evaluate and change the project accordingly during its life cycle as well as keeping the customer informed and involved in development process.

History of Agile

Dr. Winston Royce presented a paper in 1970 entitled “Managing the Development of Large Software Systems” which provided an outline on sequential development. In essence, his presentation described that any project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that a new phase can begin only when the previous phase has been completed. Therefore the software developers first gather the complete requirements for the project and then complete the design process, then write all of the code, and so on. There is little or no communication between the specialized groups that complete each phase of work. In the late 1970's and throughout the 1980's, phased program planning started being used by several Japanese companies for new product development. This method took the waterfall method and overlapped the phases which meant each phase would begin, in order, but continue to be revisited throughout the project until the project reached the final phase where they would be finished in sequence in a short space of time. This led to just-in-time manufacturing and eventually agile software development. The term "agile software development" emerged from a gathering of industry thought-leaders in Snowbird, UT in 2001. The term was first used in this manner and published in the now Agile Manifesto.

Why Agile

The Agile development methodology provides many opportunities for developers and project managers to revisit the direction of a project throughout its development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must be able to present a considerable increment in work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as “iterative” and “incremental.” In waterfall model the development teams only have one chance to get each aspect of a project right which can be a potential disadvantage. In an agile methodology, every aspect of development starting from requirements, design to testing is continually revisited throughout the lifecycle making changes as and when necessary. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction. Because this data is based on historically accurate information, much more predictable and realistic project projections can be made available for improving business decision making.

Using the Agile methodology the teams can start working on the requirement as and when they are available. It does not force them to wait until the customer had given them the final draft of the requirements. And since the teams work cycle is two weeks it gives the customer a lot of opportunities to calibrate releases for success in the real world. It can also be said that the agile methodologies help companies build the right product just like how the customers want it to be. Instead of having to commit to a piece of software which has not been written yet, the development team can now be sure writing a software that caters to the exact needs of the customer and in turn developing and delivering a competitive product to the market. At its core, agile development practices focus on the rapid delivery of business value in the form of working, tested software.

Are agile methodologies a fad?

Agile has been certainly a trend word these days. In fact, every project’s development process has been influenced and evaluated to see if it can adapt to agile development process. Much of it success owes to the fact that it is more adaptive and thrive on change, even to the point of changing themselves. Given the precarious nature of the markets, business requirements are changing constantly and agile is very effective in this context. This model strives to add as much as business value to the product. With this as key driving principle, it led to the success of many projects. This is why Agile word not is a fad.

Further, If we look at underlying elements of Agile process; Collaboration, Lean development, Iterate, Visualize are smart practices. Though the credit goes to Agile process for incorporating them otherwise they are common practices, knowingly or unknowingly we have been using them from considerable time. All these practices emphasize the fact that customer has much finer-grained control over the software development process. At every iteration they get both to check progress and to alter the direction of the software development. This leads to much closer relationship with the software developers, a true business partnership.

Does this mean above practices can be applied independently and still achieve same result? Yes, In fact, the methods foster the notion of “Inspect & Adapt” as a core principle. However, you also need to be mindful of the experience of the team and the relational nature of the practices. Many agile coaches recommend that new agile teams adopt all of Scrum or all of XP’s practices and learn them well before they try composing practices on their own.

However, It is observed that many teams that are not fully acquainted with Agile methodology, happened to be many, have fundamentally diluted agile practices by pulling them apart and consider individual practices as options. For instance, many teams do not consider having a daily stand-up, a backlog, a time-boxed iteration and an iteration review to be an effective agile implementation. They don’t even consider self-directed and x-functional teams, pairing, full transparency, customer inclusion, quality practices, teamwork & collaboration, and retrospectives as important or necessary. They iterate for a short while and then fail. Immediately they blame it on “Agile,” implying that the approach doesn’t work. While nothing could be further from the truth, they simply don’t understand that. The point is agility is not simply a set of practices that can be individually applied. Instead, it’s a holistic set of related practices that work together to reinforce the core tenets of agile teams.

Agile methodologies are certainly not a fad they have been and are still continuing to be one of the best development paradigms. The Agile manifesto just celebrated its tenth anniversary. Scrum was first used and shared in 1993. XP was formed in 1999. Lean principles were established well before those time-frames. So the practices, while potentially being practiced with youthful enthusiasm, are not temporary. They’ve also crossed over into the mainstream. And they are certainly not a craze. For example, the esteemed PMI is now introducing an agile certification. So, they’d are not mere fad anymore.

Has their effectiveness really outstripped earlier "heavier weight" methodologies?

Apparently, on the surface, it appears that agile is the only way that promises success for the projects. However, the success of agile depends on many factors and, as long as these are valid the agile methodology can be adopted. In fact, one of the key criteria is constant engagement of customer in the process. If that does not happen then agile methodology is bound to fail and traditional methods are the alternative. Clearly, we can see that agile methodologies have some limitations. In the rest of this section we go through the key criteria's that are necessary and for a project to adopt Agile methodology and therefore Heavy weight methodologies excel. We finally show some of the statistics on the effectiveness of both the methodologies.

First of all, Agile methodologies are so fundamentally people-oriented, it's essential that team should be enthusiastic and capable enough to work in an intense environment, and continuously engaging with customers. However, if the team is reluctant then imposing agile methodology severely impacts the process. Further, it's valuable to also have customers (those who need the software) who want to work in this kind of collaborative way. If customers don't collaborate, then you won't see the full advantages of an adaptive process. Having said that, customers who are unaware this process when approached really understand the benefits of it and start engaging in the process.

However, Agile methods can't be used on large projects. The problem with agile is it has very significant potential for rework based on the increased likelihood for poor design decisions being made early in the development, when the breadth and depth of the solution is not well understood. It is believed that this risk is mitigated by adopting sound, thorough planning techniques that expose the breadth and depth to the team up front, allowing them to make intelligent decisions regarding the sprints and intelligent decisions about design that reduce the risk of rework. The agile concepts have much to commend them - as articulated in the post - but seem to lack (to me, at least), the necessary preliminary rigor in planning to reduce the potential risk. So, it is observed that Agile excels only if the projects are small and medium sized.

Finally, it’s primarily comes down to the people and customers. If the people and customers involved aren't interested in the kind of intense collaboration that agile working requires, then it's going to be a big struggle to get them to work with it. In particular, one should never try to impose agile working on a team that doesn't want to try it. And for most project, agile methods have really helped them in achieving success. The following survey results summarize the same.

Survey results conducted by Ambysoft clearly show that success rate of Agile is high compared to traditional heavy weight methods.

Agile success stories

In this section, we will go over some of the major success stories of projects adopting Agile methodology and finally summarize the overall success rate of the agile process.

Betaport

Beatport is a product similar to iTunes but catered to DJ’s very popular music DJ mixing software. It was a developed by geographically distributor team spreading across India and customers in Davin, Berlin and London. They adopted Agile process and it took them 20 months, divided in four stages. It involved keeping a small release cycle, hiring an agile experienced product owner, involving all the stakeholders and stay focusing on enterprise architecture to ensure they are always aligned with company goals.

BMC Software

BMC Software team followed few principles as part of adopting their teams to Agile process. After that, BMC Productivity Index improved to 27 from what was an average of 6 to 16 in other software types. The principles included.

• Leadership and social contract with the team.

• Know-how - used Rally with a 50/50 spend on professional services and coaching while the other 50% was used for Rally’s application – this combination was critical to go as fast as we did.

• Flexibility - have to take the adoption incrementally and iteratively.

• Patience - cannot Agile the Agile – as it is changing the software, the process and the organizational structure.

Pearson eCollege online learning software

Pearson eCollege online learning software started working on Scrum for the last two years with teams in Denver and Sri Lanka. Initially, they were following waterfall model with huge business requirement document and they slowly started moving to Agile and within four releases they were able deliver quality builds from that day. They used continuous integration server and because of which bugs got reduced drastically as they were notified in early stages of development. They had only one release for staging and production.

It then dramatically increased the speed of the team and clear visibility has allowed them to react at each two week iteration with strict prioritization. As a result, they were not delivering the wrong or unwanted features.

In general, surveys reveal that about 55 percent of the projects which adopted Agile have been successful.

References

Agile software development
Agile Methodology Website
2011 IT Project Success Rates Survey Results
Deciding What Kind of Projects are Most Suited for Agile
The New Methodology

Further Reading

Agile Methodology
An investigation into the effectiveness of agile software development with a highly distributed workforce at DigitalCommons@Pace
5 Stories of Agile Success at AGILEBLOG