Many companies are embracing Agile software development methodologies for the benefits they offer versus sequential or waterfall development. The promise of Agile is to enable application development teams to focus on delivering higher quality software faster and to collaborate closely with the business to ensure that the software meets expected business requirements.
In short, an Agile approach to software development enables organizations to become more productive by increasing the response time to changing business priorities, reducing the amount of rework and lowering business risk by identifying defects earlier in the application delivery life cycle. However, to realize the full promise of Agile, organizations need to move beyond the mindset that it is a developer-centric practice. All key stakeholders in the software life cycle must embrace and become part of the Agile delivery process.
Fully embracing Agile
Agile is most effective when its practices are applied at every stage of the application delivery process, beyond just development. Completing the code faster doesn’t get the application to market quicker or with higher quality if key stakeholders in the organization-business analysts, quality assurance (QA) engineers, project managers, etc.-continue to follow waterfall practices and timelines. Every stakeholder involved in the delivery of an application must be included in the Agile methodology to ensure that teams are aligned on the project objectives, processes and timeline.
As organizations move towards adopting Agile processes, many suffer from piecemeal adoption. In some cases, developers move into sprint-like iterations, but the work of business analysts and testers are left in their old, sequential places in the project plan. This problem of part-waterfall and part-Agile within a single project is common enough to have earned its own moniker: “scrummerfall.” (The joke being that projects fail twice as fast as they would have with waterfall alone.)
There are three key questions that can help you determine if you’ve fallen into the “scrummerfall” trap. First, ask yourself, “Are my Agile projects discovering code defects earlier in the life cycle than my traditional projects?” With Agile, you should always surface issues sooner. Second, ask yourself, “Am I seeing fewer defects in finished products when I compare my Agile projects with non-Agile projects?” Agile should improve the quality of a software project while decreasing the costs of fixes. Third, ask yourself, “Are business stakeholders generally more satisfied with Agile projects?” Agile should help business and IT better communicate expectations.
Agile Principles and Traditional IT Best Practices
Agile principles and traditional IT best practices
One reason organizations are slow to fully embrace Agile is the fear that it will promote more bad habits. It’s a justifiable fear. However, embracing the benefits of Agile such as flexibility and responsiveness does not mean that traditional IT goals such as consistency and thoroughness will need to be abandoned. The truth is that these goals are mutually supportive. Consider a few other key areas where “traditional” IT objectives help to further Agile goals:
1. Speed and quality
To meet sprint deadlines, Agile development teams often short-circuit the testing effort. However, this undermines the goal of discovering defects early in the development cycle-perhaps the primary benefit of iterative over sequential methods.
To overcome this, organizations should balance speed and quality through the use of test automation tools to validate the functional, performance and security requirements of the application during each development iteration. Automation allows you to increase test coverage while still keeping the project moving in sprint time.
2. Flexibility and consistency
Unlike traditional methods that often rely on cumbersome, obsolete project plans, Agile encourages teams to be flexible and responsive to change. Unfortunately, this can sometimes lead teams to abandon formal project management altogether. This results in loss of visibility to progress, particularly when teams continue to use sequential methods and planning standards.
Organizations can find the right balance by using a solution that helps manage Agile methods (user story definition and management, release, sprint and backlog management, and burn up and burn down charts, etc.) as well as non-Agile methods. This helps provide visibility into the progress across all projects, regardless of the development methodology.
3. Entrepreneurial and economies of scale
Agile encourages smaller teams to work with greater autonomy. These are good objectives, but they can trend toward limited cross-team collaboration and higher duplication of effort. To preserve cross-team collaboration, delivery teams should utilize a common repository to streamline the sharing and reuse of project assets and artifacts (user stories, tests, components, known defects, etc.).
How to Determine When to Use Agile
How to determine when to use Agile
Finding the right balance requires a new approach to developing applications. It requires stepping back and reassessing your tools, processes and, potentially, your organizational structure. The following are three things you should consider to determine if Agile is right for your application projects:
1. Automate Agile processes
Organizations should leverage an integrated management and automation solution that will allow all stakeholders to be actively involved in the Agile delivery process. Having a centralized system in place will help foster collaboration and develop stronger communication among developers, testers and business analysts. Additionally, an integrated management solution will help increase project visibility and progress throughout the delivery phase of an application.
2. Begin with a pilot projects
Agile should be adopted in steps. Start with a pilot project comprising of a small team of business analysts, developers and testers. Determine what works and identify areas of inefficiencies, then work to correct them before scaling to additional projects.
3. Use Agile where it makes sense
Remember that not all projects should leverage Agile methodologies. In cases where business requirements will not change throughout the application delivery process, it would be best to use the waterfall methodology instead.
Tracy DeDore is a 24-year veteran of HP. Tracy currently drives Agile initiatives at HP. She has held a variety of software-related roles including software programming, second-level technical software support and product marketing. She can be reached at [email protected].