Agile development: Adopt gradually or dive in
Agile is designed to drive collaboration, transparency, and quality within product and software development lifecycles, but it isn't always the right answer for every organization. In fact, the signers of the Manifesto will tell you that, while there is value in examining what agile is, there is just as much value in examining what it is not.
It is not a silver bullet, nor is it necessarily the cheapest option. It's a just a framework to align delivery teams to deliver working software more collaboratively and with better quality.
With agile there are tremendous benefits from the business and the development perspectives: you can generate positive results for IT, and at the same time, get to market faster and increase your competitive differentiation. But how do you decide if introducing agile gradually (known as an agile adoption), or implementing agile across your organization (known as an agile transformation) is right for you
A good place to start is by examining your company's product development or project management culture. If your organization has demonstrated success using the predictive, traditional waterfall development methodology, there may be real value in continuing to assemble your teams, work on discovery, generate detailed requirements, design the solution, develop the code, test the code, and then deploy it to your production environment. In other words, if your organization's SDLC isn't broken, then for goodness' sake don't fix it!
If your organization is susceptible to waterfall's limitations, however, agile may be a more viable option. Some business leaders become frustrated with the tremendous investment of the delivery teams' time at the front-end of projects as they work to make analysis and development decisions about a product they may know very little about. After all, agile argues, why spend so much time defining a product when you know the least about it
Adages aside, if not handled correctly, the project may be subject to costly late-stage rework, as project needs shift. This also leads to the delivery of a product the business thinks it wants and not what it needs.
Agile leverages team uncertainty and lets team members do what they do best: visualize a solution, engage the right people, and build a potentially shippable product. In this sense agile turns the more traditional ways of developing software development model upside down by: 1) favoring collaboration between the development team and the client over costly time spent working through contract language and requirements, and 2) focusing on engaging individuals and fostering interactions over processes and tools.
Another decision indicator is your organization's process maturity. If your enterprise is process-driven and you're thinking of adopting an agile software development approach, you may want to consider how it will be implemented at the ground level. For instance, departing from process and moving project managers from waterfall to agile may seem as if you are asking them to abandon process and "relinquish control" and this isn't an easy proposition for some process-driven PMs to stomach. It takes considerable change management and coaching before people can really see the benefits of an adoption or transformation.
A third consideration lies in what may happen post-adoption or post-transformation. While the foundation of agile is quite powerful, it makes sense to understand the common pitfalls companies experience in a transition. Consider the following:
* Fixing both the hours and scope This restricts the teams' ability to be agile and gives the business what they asked for, not what they need. In waterfall, project managers are comfortable using change requests to adjust their hours and scope of work. Agile somewhat departs from this change approach, as teams are encouraged to respond to change by constantly adding to their backlogs (read: requirement sets), rather than adding to scope and schedule. While the requirements may change in agile the schedule always remains the same.
* Scheduling all of the sprints/tasks in advance The desire to plan every requirement, task and story, in every sprint, up front, is a natural tendency of first-time agile project managers. Resist the temptation! Trying to schedule all tasks in advance prevents the teams from truly self-actualizing, impedes their ability to find their true velocity and sets unrealistic expectations for delivery.
* Dictating the velocity of development across all teams -- Each agile team will have its own velocity, its own challenges and its own speed. Teams get faster as they go, so managers should not try to compare velocities between teams and work efforts. Let the teams learn and adopt at their own pace (with the correct amount of coaching, of course).
* Feeling like an acceptance of agile is a loss of control If agile is implemented correctly and scaled appropriately, leaders at the project, program, and portfolio levels will have a better understanding of the work in progress on a daily basis, know exactly what is left to complete, and know the same day if something is slipping.
* Excluding your QA testers on the sprint planning/execution processes Having QA as part of the team planning sets the direction for the test plan and defines what "done" means. This requires organizations to engage their testers much earlier in the process, which is a departure from a waterfall approach where testers come in toward the end. While involving testers is a great idea, in theory, it can be rather difficult to implement in practice, as test/QA resources in waterfall projects are typically budgeted for (and allocated) toward the end of the project. Make sure your teams and your test leads understand the implications of a move to agile before you engage in complex resource capacity discussions!
Based on a review of the suggested cultural factors above, what should organizations also consider when deciding whether to adopt agile or transform completely We've established that it's not easy to change the level of control that waterfall project managers have using the waterfall approach. Agile is, in fact, a leap of faith; however, organizations that take the leap typically have a better grasp of daily work progress post-landing. Managers know if a project is slipping and, in some cases, may actually have stronger project management capabilities than they had with the more predictive waterfall approach.
Another consideration is quality. According to IT research firm Standish Group, companies using an agile development approach report an average of 63% improvement in quality. Companies that improve on defect rates while building the right product, instead of one that may not necessarily be what the business is looking for, will drive true, sustainable value back to the business. Finally, as quality and value improve, teams can have complete transparency into what's being delivered and foster much better dialogue between the business and IT.
Benefits aside, full transformations to agile are not necessarily required for long-term company success. In fact, organizations can choose to use agile for some initiatives, but have projects that need to stay with the waterfall approach.
So when faced with the decision to adopt agile or transform, consider your culture and your appetite for change. Measure the teams' desire to gain improvements in quality and deliver better outcomes. Understand how much the business is willing to prioritize improving time to market and driving competitive advantage. Finally, analyze your current state for both customer engagement (customer satisfaction) and employee engagement (happier employees) and decide whether adoption, transformation or maintaining a waterfall approach is what's right for your team.
Walser is a Client Services Executive with AIM Consulting and has over 17 years of experience in leading continuous improvement, software development and transformational strategy projects.