- Individuals and interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiations
- Responding to change over following a plan – [The Agile Manifesto] 
To gain a better understanding of the advantages, considerations, and risks of changing from a traditional waterfall development process to Agile, this article will address the following questions.
- What is the difference between traditional and Agile methods?
- How do other companies use Agile and is adoption widespread?
- How to make a decision to try Agile in your organization?
- What are the key considerations / risks of making a change to Agile?
The easiest way to understand the basics of Agile Development is to compare it to a more traditional development methodology such as Waterfall. Waterfall is a structured, linear process and relies on extensive planning. In real timeline terms, a Waterfall project might begin with requirements gathering over a period of weeks or even months before proceeding to design, coding, testing, and eventual release. Progress is measured in terms of deliverables, artifacts, documentation and specifications.
In contrast, Agile seeks to take a basic business request and convert that into a description of the overall project objectives and actual backlog of work. This business request is at a general level and not a definition of requirements! Add a few more things and you are ready to get started. The team must agree on the length of time, called an iteration or sprint, that you will be developing features. A typical iteration is usually 2-3 weeks. From there, the main focus is elaborating the work or “stories” for that first iteration and defining the acceptance criteria for completion or “definition of done” for that work. The “definition of done” determines when to declare victory, or sometimes defeat. Admitting defeat is not always a bad thing! With Agile, you want your failures to come early so you can make corrections and still meet your larger goals.
With the iteration length, stories and “definition of done” in hand, an Agile team should be able to begin iteration #1. At this point, the project moves forward iteratively, planning the next phase of development just prior to the work being performed. Essentially, the design, code, and test activities could be occurring in parallel with two or more iterations.
To prepare for the next round, or iteration, the team starts by answering the following questions:
- Will there be working software to release at the end of the iteration #1?
- Did the work meet the “definition of done” and can it be released?
- Did the work meet the specific definition of the iteration but fail to satisfy the overall business request?
- What was learned and how do those lessons get incorporated into the next iteration?
By providing fast feedback, adapting to changes, “just-in-time planning” and using knowledge gained for immediate incorporation into the next set of stories, the team is ready to start on the next iteration.
Define, develop, test, and deliver. Progress is measured by providing working software to the customer. Wash, rinse, repeat until the business request is satisfied.
How are other companies using Agile and how much?
Agile originated in the early 90’s, so the overall concept is not new. Gartner Research considers Agile to be a mainstream, mature and proven set of development methods. Forrester Research surveyed nearly 1,300 IT professionals and found that 35% of respondents stated that Agile most closely reflects their own development process. Some Agile adoption forecasts are as high as 80%. In the development world, Agile continues to play a much larger role in many organizations than just a few years ago. Agile has many devoted fans who feel that it’s an all-or-nothing proposition, following to the letter the many rules and axioms that come with being Agile. (See the Agile Manifesto1)
Then again, other evidence suggests Agile is not really “everywhere”. Gartner estimates it accounts for less than 15% of software developed by application development firms. Then how can a person reconcile those numbers (35% Agile like) yet only 15% of the output from application development software firms was done under Agile? As with many things, the answer lies somewhere in the middle.
Research, anecdotal evidence, and common sense suggest that Agile adoption is not actually static and most projects are best served by being “Agile-like”. As managers and developers gain a sense for what Agile can do, the solution often is a mix of Agile principles, such as fast feedback and working software, applied to more traditional development life cycles.
People like hybrids in life (see: 8 pound tomatoes, Flex Fuel cars, Swiss Army knives) because they tend to play to strengths, are more flexible and have greater efficiency. Agile is no different. Although not supported by the Gartner estimate, Agile is here to stay. The future appears to be a hybrid of continued adoption of Agile methodology and best practice techniques to provide working solutions and software for clients and customers in less time and with lower cost.
Of course there is no single decisive factor that will tell you if you should try Agile. However, there are some common characteristics to look for in your current project(s) that can be evaluated to determine a good place for an Agile test run in your organization.
If one or more of these challenging scenarios match up with the current state of one of your projects, then it may be time for a test run with Agile.
What are the key considerations / risks of making a change to Agile?
Once the decision has been made to give Agile a try, it’s time to get tactical, choose a project, and apply the methodology. To determine what kind of information is needed before you can start; ask some basic questions – Who, What and How.
Once the basics have been planned and resources are identified, there are other aspects to be considered such as organizing the team by defining roles and responsibilities, writing business requirements or “stories”, and documenting changes to meet compliance requirements.
Congratulations! You’ve done your homework and believe it’s time to try an Agile project. A great way to increase the chances of success with your first foray is to engage a person or persons with experience to get things rolling. That person could be someone internal to your organization with Agile experience or an external consultant with direct experience starting a new development methodology, such as Agile. Regardless, this “Agile Sherpa” should be able to provide leadership with the ambiguous nature of project initiation and guidance to the team on a daily basis.
The expert should be able to help the organization achieve success by:
- Ensuring the organization understands the fundamentals of Agile and has the mechanisms in place to enable the success of an Agile project
- Identifying and mitigating risk across people, process and technology
- Providing leadership in defining major Agile project decisions (such as iteration length, definition of work unit, definition of done) for the project and ensuring that the decisions are adhered to throughout the life of the project
- Collaborating with the organization to achieve acceptance and understanding of the Agile process throughout their organization
- Leveraging years of practical project experience to provide value across the project lifecycle
Now that you’ve learned a little about Agile, the things to consider before beginning an Agile project, and the potential risks that can occur along the way, it’s up to you and your stakeholders to decide if now is the right time to put a toe in Agile waters. (Or maybe cannonball in!) Bottom line is that your organization is unique and so are the challenges, which can only be discovered by getting wet. So…it’s time: Dip a toe or cannonball?
Powered by Facebook Comments