Agile Adoption Patterns: A Roadmap to Organizational Success
by Amr Elssamadisy
Links: Safari Books Online, Amazon
Learning is the bottleneck
Learning the bottleneck of software engineering. Agile teams succeed by accelerating the learning process by using Cycle processes.
...
Communication methods: Self-organizing team, co-located team, cross-functional team, pair programming, information radiators (i.e. charts and wall posters), evocative documents, stand-up meetings.
Business Value
Key Business Values
- Reduce time to market - release early, release often. Provide customers with something that can provide a return on investment right away.
- Increase product utility
- Increase Quality
- Increase flexibility/agility
- Transparency/visibility
- Reduced cost - reduced waste.
Smells (when things go wrong)
Business smells (visible to the customer)
- unacceptable quality
- new features take too long
- features remain unused by the customer
- software is not useful
- software is too expensive to develop
- conflict – customers, testers, developers
- customer asks for too much up front.
Process smells (only visible to the development team)
- direct customer input is unrealistic and unattainable.
- management surprised - lack of visibility
- multitasking - developer's assigned to multiple projects
- missed deadlines multiple times
- hundreds of bugs in the issue tracker - low priority bugs are never addressed
- prolonged hardening phase at the end of the project - iterations have not succeeded in delivering tested, working, software at each stage.
- infrequent integration - takes too long, is too painful. integration waits until the end.
Feedback Practices
- Iteration (sprint) - a constant time box, with specific acceptance criteria (done state). Typically 1-6 weeks in length. Should begin with a kickoff meeting and end with customer review, testing, and integration into the current version of the system (demo and retrospective). Closed to functionality - no change of scope or requirements during the iteration cycle. Iterations vs. incremental development - in the latter, there is no time box. Misses the opportunity to create a team rhythm and make planning easier based on fixed chunks of time.
- Kickoff meeting - at the beginning of each iterations; all team members, including customers; develop the backlog for the iteration. Customers should be prepared in advance with requirements.
- Backlog - a prioritized list of requirements. Allows for negotiation of scope within available time to deliver the most valuable features. Graphical representations: burn-up chart and burn-down chart. Use vertical slices of functionality to create backlog items.
- Planning Poker - estimation technique for an iteration. Teams (usually not to exceed 10 people), including all developers, analysts, database people, etc. estimate each requirement in the 3-5 minute "round". Each estimator is given a deck of cards with a range of estimates for amount of work required. Moderator reads a scenario, and estimators privately select a card. High and low estimators explain why and discussion and rounds continue until estimates converge. Usually should take no more than three rounds.
- Stand-up meeting - a daily meeting that lasts no more than 15 minutes containing all team members; the self-organizing team exchanges progress information about the current iteration.
- Done state - goal for the iteration. Should follow S.M.A.R.T principles (specific, measurable, achievable, relevant, and timely)
- Demo - for the customer and all stakeholders at the end of each iteration and release.
- Retrospective - Review meeting after each iteration and release. Focuses on people and techniques, whereas the demo focuses on the product.
- Release often - release as frequently to customers as practical without inconveniencing them.
- Co-located team
- Self-organizing team
- Cross-functional team - Members have the expertise to take a requirement to finished product through the entire process. Requires collective code ownership and pair programming to increase knowledge transfer and reduce expert bottlenecks.
- Customer part of the team - "Customer proxy" member of team if not practical.
- Evocative documents - external memory of conversations, people, time, places. Requires context and reconstruction for those not part of the conversation, but easier to develop and more useful than traditional documents.
- User story - an evocative document for requirements, a "promise for conversation" of more detailed requirements.
- Use case - high-level business work flows that can be directly translated to requirements.
- Information radiator - whiteboards, flip charts, and other large objects that "radiate" information every time someone sees it.
Technical practices
- Automated Developer tests
- Test-last development
- Test-first development
- Refactoring
- Continuous integration
- Simple design
- Functional tests
- Collective code ownership
- Pair programming