CSC/ECE 517 Fall 2009/wiki3 7 f1

This wikipedia article focuses on how Agile software development methodology can complement other design methodologies. Section 1 highlights the advantage of agile over traditional models, like the waterfall model. Section 2 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 3 takes up a few design methodologies and focuses on how agile complements them.

Agile vs Traditional Methodologies

The agile manifesto focuses on

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

Advantages of the agile method

• Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

• Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

• Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.

• Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

• However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

Challenges in Applying Agile Methodologies

• [3] researches about the challenges in applying agile and concludes by introducing a set of new and modified development practices, which will help in developing a large agile project. One of the aspects common to many agile development methodologies is that the entire team (business analysts, developers, and testers) collaborate very heavily. With a large project, this type of collaboration is difficult at best. Teams tend to break up into subteams for better communication. The downside to subteams is the possibility that the subteams build stove-piped sub-systems if communication is insufficient among the teams. Problems of consistency and duplication may go undiscovered. Of course, there are other practices that help alleviate these problems such as rotating team members among the subteams, having an overall design document, etc. The different subteams may result in a non-homogeneous and inconsistent architecture.

• Many of the solutions agile methods promote, draw on a limited set of techniques for managing organizations and understanding customers. [7] focuses on incorporating customer-centered techniques such as Contextual Design to provide additional solutions to the real problems recognized by agile methods. These solutions work in combination with agile methods’ strengths resulting in a process that incorporates the customer voice, provides room for UI and user interaction design, and can address significantly large projects.

Study of a few Design methodologies and How Agile Complements Them

Separating Design from Engineering

Much of the distinctiveness (and much of the value) of agile methods comes from the clear separation of responsibilities they bring to the development process. Developers write code and design the implementation of systems—that is what they are good at. They are not good at understanding how people work, creating effective and intuitive user interfaces, or making an interface usable.

The great strength of agile methods is that they focus the engineers on doing what engineers do best. The weakness of agile methods is that they give little guidance in figuring out what to tell the engineers to do.

Core Team: Possible agile solutions would be to start with a core team which builds out a simple business case in a test-driven manner. This first phase will build out enough of most of the architecture. With a small team, a full agile methodology works without modification. When a significant portion of the architecture is built, it is time to divide the project by growing the development team and splitting up into smaller subteams to grow the project into a fully functional software system.

Role of an architect: While there is no traditional architect role in most agile development methodologies, in large teams, it is often beneficial to reintroduce a modified version of this role. The architect is a member of the team with significant design and development talent and experience and he has to understand the ‘whole’ application code-base. The architect is hands-on and pairs with others on the team frequently and will be a participant in many agile modeling design sessions on the whiteboard. This helps keep away redundancies.

Continuous Integration: While each sub-team will have their own build running, agile methodology suggests having a 'brain' team that will have to create a master build that builds all sub-teams code and/or deploy their binary files. The master build will run frequently by pulling down the last successful builds for sub projects, compile and deploy the whole project and run the tests. In case of failure the brain team has to identify the problem and resolve it or take it to the responsible sub team to resolve it.

Refactoring: In large projects Refactoring sometimes becomes very expensive process and may take a month to be done. Some design ahead may be done to save expensive major refactoring later. For the conquer team when it’s still early on the project, to avoid large complicated refactoring some extra time should be spent for designing for future known requirements. Having the overall picture of use cases will make it easier to predict future requirements and create a design that will handle them. This design ahead is allowed only during the conquer phase of the project and will only apply to core systems, frameworks and similar subsystems of the system which may be more expensive to be re-factored.

Tests: To reduce the coast of refactoring, the team may depend on functional tests more than unit tests. Functional tests test the functionality of the system and in general do not depend on the system design. Unit tests should still be created for test driven development and for critical pieces of the system that may cause the system to break. Tests that are created after the development and tests created for reported bugs should be functional tests. Having less unit tests will lead to more time spent in debugging issues and functional tests cannot pin point problems but having a better design through constant refactoring will reduce the development time much more than the extra time being spent in debugging issues. Functional test should be documented in each test to describe the test scenario, expected results and differences between test scenarios.

These are some of the recommended practices that will help mediate some of the problems in applying agile design methodologies to projects. There are also some difficulties with applying these practices such as with the master build, with communication between teams, with extreme designing to get useless frameworks, and care should be taken to avoid them.

References

1. XP 2006 Website
2. Agile Development Conference
3. Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
4. Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
5. Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
6. Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
7. An Agile User-Centered Method: Rapid Contextual Design- Hugh Beyer, Karen Holtzblatt, Lisa Baker