A successful Agile development process has the potential to transform a waterfall development organization from slow, mammoth releases to quick iterative release cycle. Once an organization has a firm grip on Agile basics, moving from a yearly release cycle to a weekly build-release cycle is not unusual.
Making 50 quick releases instead of one big one has several advantages. The development team is able to release value faster by getting important features in early releases. They’re also able to change directions quickly when the requirements turn out to be wrong or misunderstood, rather than working for a year toward the wrong goals. While these advantages are important, they’re not easy to realize.
Many project managers struggle with the basics of the Agile methodology as they move from an established development process such as waterfall toward using more Agile methods. If you have questions, you’re not alone.
Here are some of the answers to the more frequent questions we’ve been getting about Agile development basics.
- Agile methodologies advocate a “barely sufficient” or lean approach to avoid waste and increase responsiveness to change.
- Work is divided into small chunks to manage complexity and get early feedback. Releases are usually delivered in one to three months.
- Plans, requirements, design, code, and tests are evolved incrementally through multiple passes or iterations rather than a single “waterfall” pass with lockdowns on each. Iterations are of fixed length and fixed scope to maximize feedback and retain stability.
- All core team members are co-located(with the customer) in an open “bullpen or work cell” to facilitate face-to-face communication and rich interactions.
- Desired features are defined at a high level and prioritized by customers in a release plan or feature backlog. Developers provide level of effort estimates, and customers decide business priorities.
- Team members self-organize by continuously completing tasks, collaboratively from the backlogs without top-down management control.
- Pairing:Developers (and others) perform all production work in groups to collaboratively construct, share knowledge and enhance quality.
- Test-Driven Development:Developers write tests before they write code and evolve the code to meet the tests. Tests specify, rather than validate the code.
- Features and tasks are tracked within an interaction, they count as complete only when 100% done. There is no concept of partial completion.
- All aspects of work, including processes, are kept simple, lean(low on waste), and adaptable to maximize customer value and accommodate change.