CSC/ECE 517 Fall 2009/wiki3 7 f1
This wikipedia article focuses on how Agile software development methodology can be complemented by other design methodologies. Section 1 gives a brief overview of Agile. Section 2 highlights the advantage of agile over traditional models, like the waterfall model. Section 3 highlights why it might not be possible to introduce all of the agile practices at the same time. Section 4 takes up a few design methodologies and focuses on how they build on agile and complement it.
Introduction
To keep pace with ever-increasing customer demands on software functionality and time-to-market expectations, software developers have had to evolve the way they develop code to be both faster and higher quality. As part of this trend, the Waterfall method of software development began to give way in the late 1990s to a more lightweight method of software development: Agile.
Simply put, Agile software development is an approach that provides flexibility to accommodate continuous change throughout the software development cycle. It stresses rapid delivery of working software, empowerment of developers, and emphasizes collaboration between developers and the rest of the team, including business people.
Agile contrasts with the still-popular Waterfall development approach, which is front-end loaded with comprehensive scope and requirements definitions, and which employs clear, consecutive hand-offs from requirements definition to design to coding and then to quality assurance. In contrast, Agile incorporates a continuous stream of requirements gathering that continues throughout development. Business people are involved early and often throughout the release cycle, ensuring that the software being developed meets the true needs of both the end-user and the business. Change to the requirements and to the overall feature set is expected to occur as outside opportunities or threats arise.
In short, Agile fully embraces change and Agile teams are structured in such a way that they can receive and act on constant feedback provided by the build process, by other developers, from QA, and from business stakeholders.
Focus of Agile Methodologies
Agile is based upon a number of guiding principles that all Agile teams follow. For the purposes of this discussion, three principles – or values – are of particular interest:
- Quality software development
- Iterative flexibility
- Continuous improvement
Quality Software Development
The primary focus of Agile development is to enable the development of quality software that satisfies a customer need – i.e. provides a functioning feature or capability – within a specific period of time (typically no more than a few weeks) called an “iteration”. In theory, a product developed in an Agile environment could be market-ready after each iteration. Delivering a series of market-ready products, each in just weeks, demands that a rigorous quality process be built into the Agile development cycle. Each iteration must be fully developed: tested, defect-free, and complete with documentation.
Iterative Flexibility
With a focus on speed and nimbleness, Agile is open to changes that inevitably arise throughout the development cycle. The iterative process is flexible, based on an understanding that original requirements may (or will likely) need to change due to customer demand, market conditions, or other reasons. Because business users are involved throughout the process, and because each iteration is short, new requirements can be introduced and prioritized very quickly.
Continuous Improvement
An Agile environment provides developers with an opportunity to learn new skills and to exercise greater autonomy to do their jobs. The iterative framework is empowering because it enables continuous improvement, with testing/quality assurance occurring as part of the iterative process, rather than only periodically or at the end of a long process when it is often difficult or not cost effective to fix coding defects or to incorporate lessons learned along the way. Agile also makes the testing and Quality Assurance process transparent to the developers who originate the code, further contributing to their learning and facilitating future improvements and coding efficiencies.
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.
Example Scenarios- Newer methodologies complementing agile
We have explored a few examples below to see how agile is complemented by other methodologies.
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 cost 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.
Scrum is currently one of the most popular agile methods. It is a light-weight project management approach. Scrum as an agile method provides a framework that can be applied to other methods and approaches. Any process needs guidelines to support people actually doing the work. Processes such as the Unified Process spend lots of time describing techniques such as Use Cases, model driven development and architecture centric design. To offset this, scrum lifecycle can help provide a clear set of light weight management techniques that enable the team to effectively work together, deliver work and interact with the business. This method includes some details on techniques such as pair programming, user stories and testdriven development.
To further understand how Agile methods help complement other design methodologies, consider a case in point:
Agile design methodology working with Contextual Design methodology
Contextual Design is a user-centered design method that provides techniques covering the entire front end of systems design, from figuring out who your users are and how they work through designing the detailed user interface and functionality of the system.
Agile methods need to be used in tandem with Contextual Design methodology. Contextual Design methodology can help provide a fair idea as to the scope of the system, decisions regarding whether tasks will be streamlined through the introduction of technology or replaced entirely by automated system, and how this will affect the overall buisness. These design questions are also known as systems analysis or requirements analysis and aren’t addressed by agile methods, but help complete the picture about the project.
Contextual Design methodology provides Contextual Inquiry, work modeling, consolidation and affinity building, and visioning to support a variety of activities. This helps understand how people work, but does not focus on clear separation of responsibilities of the development process. And the latter is where Agile methods help tremendously. Developers write code and design the implementation of systems and agile methods help focus the engineers on doing this better.
Consider the case of a user interface (UI) design, which must be assembled into coherent, transparent screens that support the user’s work in the new system. Regardless of where UI design is situated organizationally, a successful agile development project depends on the skill being available, even if it does not explicitly assign such a role. Because the UI is the interface between the user and the system’s function, the only way to test the system is through the UI. Effective UI design is a prerequisite for agile methods to work, but the methodology provides no separate focus or testing.
Contextual Design methodology recognizes and resources UI design as a separate discipline—which fits the agile approach of focusing the developers on developing code. This provides requirements for UI design and the paper mockups permit the UI to be considered and tested on its own, independent of the developer’s underlying implementation.
Summary
In summary, Agile methods provide a strong set of social engineering concepts that will improve the way in which development teams work. Organizations must complement agility with both a lifecycle and a set of engineering practices that enable organizations to both better manage the collection of agile projects, but also ensure consistency and repeatability within those projects. Software development lifecycles should avoid being overly prescriptive, focusing instead on the essential states that a project must go through and report progress against.
References
- XP 2006 Website
- Agile Development Conference
- Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy
- Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams- Grigori Melnik, Frank Maurer
- Rolling the DICE for agile software projects- Bartlomiej Ziolkowski, Geoffrey Drake
- Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects- Scott Harris, Mike Cohn
- An Agile User-Centered Method: Rapid Contextual Design by Hugh Beyer1, Karen Holtzblatt1, Lisa Baker2
- Being Agile in a Non-Agile World By David West