by: Ryan Martens
“If you want to teach people a new way of thinking, don’t bother to teach them. Instead, give them a tool, the use of which will lead to a new way of thinking.”
– Buckminster Fuller, American inventor, author and visionary
What Are Agile Methods?
Agile is an organizational change tool that can lead to positive changes in your projects and programs. It is a very simple and different strategy for project management than critical path and waterfall.
The “iron triangles” shown here depict the constraints that any project must wrestle with. Waterfall software development is measured by conformance to the plan. The essential disciplines of waterfall require you to get the plan right and make the phase hand-offs of documents effective. If you get it right, waterfall can be very efficient and successful, but never early.
Agile software development is driven and measured by its ability to deliver results to the vision and value. And like waterfall, Agile requires certain disciplines to be successful. With Agile, the essential disciplines require crisp and effective cross-functional collaboration and a commitment to delivering working code in the face of small fixed resources and fixed time boxes, known as iterations. As a result, Agile projects can deliver early – as soon as the vision and value are realized.
For projects where the risks are high and the project definition is evolving, Agile’s simple empirical method delivers consistently better results, faster and with less total cost. For projects where the technical, execution and funding risks are low and the definition is well known, the waterfall process can be more time- and resource-efficient – provided you plan, you hand-off documents well, and the definition does not change during the project.
Agile is a feedback-driven paradigm for managing the design and delivery of creative, innovative, risky and complex projects. Its principles are contained in the Agile Manifesto . Its best practices include:
• Run one- to four-week iterations that deliver working, tested increments of functionality
• Make releases to customers smaller and more frequent
• Maintain the system in a state that always runs and passes automated tests
• Organize around cross-functional component teams (define, test, code & build)
• Work projects serially from a regularly evaluated and prioritized backlog
• Inspect and adapt the process and product every cycle
The Agile software development process is well depicted by the Scrum model of working on the highest priority items in concentric time-boxes including daily, iteration, release, roadmap, and vision. Organizing for Agile methods requires working in cross-functional teams of resources required to produce a complete releasable solution. This typically means people who can define, develop, test and package a component of the system. Leadership of Agile teams requires servant leadership skills. Technology to support Agile facilitates collaboration, prioritization, visibility and lightweight signaling.
How Do Teams Adopt or Trial Agile?
A vast majority of teams get started with Agile software development by adopting it on one team first. To start a pilot team, follow these on an in-flight project or new project:
1. Get the team together and get agreement to try Agile methods.
2. Declare an iteration time box, for example two weeks from this coming Monday and schedule a demo with stakeholders for the end of the iteration.
3. Prepare your top five highest priority items to get done in the two-week period. This list of items includes for each a description of the item using a story template (“For system role, provide the capability to deliver benefit”) as well as the one to three acceptances tests necessary to declare these items done.
4. Have an iteration planning meeting for about four hours wherein you task estimate these five items and discuss, with the whole team, the designs necessary to get items done-done in the two week window. (Done-done is coded, tested, user accepted and integrated into the systems.)
5. In the planning meeting, estimate your capacity in the two-week window in hours of productive time. (Typically no more than 50 percent of the wall time to available new Agile team.)
6. Use your capacity to reprioritize and shape the five items to fit into the capacity-constrained iteration. Do not ask the team to do more than the available capacity.
7. End the planning meeting by have the team come to consensus and commit to delivering some portion of the five items in working, demonstrable code at the end of two weeks.
8. Run the iteration and steer it using a daily 15-minute stand-up meeting taught in Scrum training .
9. After the iteration ends, hold the demo to get stakeholder and customer feedback on the delivered software.
10. Hold a review meeting with the team to figure out what went well and what you want to change. Ask the team if they want to keep doing Agile development or go back.
What Are the Next Steps?
There is big footnote on Agile: “It’s simple, but it changes everything.” Because the time boxes are short, it is easy to measure progress and expose issues. Agile exposes “issues” quickly and effectively. You need to be ready to work in very open and visible environment. In addition, you need to be prepared for feedback and reflection. If your team collaborates well and has the discipline to work the highest priority items in small chunks, you will not be disappointed.
Finally, if you need to think about how Agile software development can cooperate with your current waterfall world, review Michele Sliger’s Agile 2006 presentation, “The Agile/Waterfall Cooperative” .
About The Author
Ryan Martens has helped hundreds of organizations transition from traditional development processes to Agile methods and is an elected board member to the Agile Alliance, a non-profit organization that supports Agile software development. Access additional resources on transitioning to Agile at http://www.rallydev.com/agile_knowledge.jsp.
Article courtesy of Ryan Martens, ArticleCity.Com