Dean Leffingwell
gave a talk at Agile2009 about best practices for enterprises to scale agile.He talks about his experience consulting for a company wanting to apply agile at a large scale. There they took the extreme agile approach by throwing away all current practices and starting out fresh with pair programming and slowly adding items as deemed necessary. They started out with minimal tooling and some coaching. They had a commitment to Agile from top to bottom. At the end, the results showed reduced cycle time from 18 months to 4-5 months, productivity increased by 40% and defect density remained the same (meaning new development had lower defect rate than older development, since more was getting done).
Implementing agile involves enhanced project management practices (SCRUM) and enhanced software development practices (XP) along with modified social behavior (face to face communication).
Agile Focuses on developing value to the customer. Agile empower teams to more rapidly deliver quality software explicitly driven by intimate and immediate feedback.
Dean moves on to compare the agile cycle to the waterfall cycle and explains how agile delivers value faster by giving the iphone example. When the 1st version of the iphone was released, it retailed for about $600 and ran on a slow network, did not include apps and there wasn’t even an app store. Later newer, enhanced versions came along at a lower price.
Dean moves on to describe 7 team practices that scale and 7 enterprise practices.
7 team practices that scale:
- The define define/build/test team
- Mastering the iteration
- Two-levels of tracking and planning
- Smaller, more frequent releases
- Concurrent testing
- Continuous Integration
- Regular reflection and adaptation
Organizations have to move from function silos to cross functional teams of 5-9 members. Instead of having separate teams for product management, architecture, development, and QA, have many smaller teams each composed of developers, testers, product owner, tech lead, and scum master. In an enterprise of say 400, that makes about 57 teams. Each team is a self organizing team that can define, build and test something of interest/value. Teams will interface with architects as well as QA and Release management.
2. Mastering the iteration
Everyone has to buy into agile and there should be a commitment from top to bottom. Upper management usually accepts agile because it means faster delivery with fewer defects. Teams like agile because it empowers them. However, middle management is lost because they do not know how to contribute. And if they are not contributing then they are undermining, creating impediments, and waiting for the process to fail. Managers should have accountability, understand, promote, train and coach agile practices. A good approach is to let line managers promote, mentor and coach other teams that do not include their direct reports.
3. Two level planning and tracking.
There should be two levels of planning, one at the release level and one at the iteration level. The release cycle drives the iteration cycle which in turn provides feedback to adjust the release cycle.
The Release Cycle consists of Release planning, Release vision, and Release scope and boundaries. The releases should be at the system level with three to six months horizon and include a prioritized feature set.
The Iteration cycle consists of iteration planning, development and test, review and adapt. User stories are user for the iteration cycle.
4. Smaller more frequent releases
Releases should be shorter in the range of 60 to 120 days. They are defined by date, quality, and feature set. The scope is the variable, while date and quality are fixed. It is preferable to ship on a locked date. That is, fix the date and float the features. This drives quality, commitment and understanding per functionality. Product owners can prioritize, teams learn that dates are important, and teams can meet commitments.
5. Concurrent Testing and
6. Continuous Integration
Test automation is the rule, not the exception. The testing is a team effort where testers and developers are writing tests. Ensure that all code is tested and no credit is given to non tested code. The tests are written before or concurrently with the code.
7. Regular reflection and adaptation
Periodically, the entire team including owners and users reflect on the results of the process, learn from that examination and adapt the process and organization to produce better result. The team decides what is working well, what is not, and what thing to do differently next time.
Next Dean moved on to describe 7 Enterprise Practices:
- Intentional Architecture
- Lean requirements that scale
- Systems of Systems and the agile release train
- Managing highly distributed development
- Impact on customers and operation
- Changing the organization
- Measuring business performance
1. Intentional Architecture
The ability to refactor is limited by scale. Therefore, the team that codes the system should also design and test the system using the simplest architecture that can possibly work. If in doubt, code it out 1st. The system architecture is a role collaboration and there is no monopoly on innovation.
2. Requirements still matter in agile
Vision: Light vision concept. Preliminary datasheet. Draft press releases.
Road map: Management can contribute to it, but it is the team’s responsibility.
Just in time elaboration: This is where the real work is done in story elaboration and acceptance criteria development.
At scale not everything is a user story. You have:
Investment themes -> Epics -> Features (go into backlog) -> Stories -> User stories
3. Systems of systems and agile release train
Scaling agile requires managing inter-dependencies amongst team of developers. Only the team themselves can manage this complexity and commit to the schedule.
Systematic enterprise delivery requires an agile release train method.
Rolling wave enterprise release planning drives release train vision and execution
In the release train, dates are fixed. Intermediate milestones are established and enforced. Component functionality must flex (how much cargo can get on the train). All teams start and stop at the same time of week. All teams have the same iteration length and the same hardening period. There is always a system level team around that does things the other teams cannot do.
Unfortunately Dean ran out of time and did not cover the other items. You can find out more about Dean and scaling agile at http://scalingsoftwareagility.wordpress.com. This presentation is available on infoQ at http://www.infoq.com/presentations/scaling-best-practices
