Managers at many levels are often afraid to let go of the reins for fear of losing control of the project (and their position of power). V. Lee Henson explains the benefits of letting go and outlines the expectations of a responsible, empowered agile team. Through presentation of multiple real-world scenarios and years of project management experience, Lee will show that often our own human nature is the greatest impediment to being a better manager.
Agile Development Practices 2008
Whether you've been agile for a while or are thinking about it, you have one thing in common with every other software team I've encountered. You have too much work to do. One way to organize your work is with a project portfolio. But if your portfolio is an "as desired" portfolio, you still haven't solved the problem of too much work. Fortunately, taking a lean approach to managing the portfolio helps make those problems of "desired" and "too much work" transparent.
Many software development organizations work within the bounds of contractual agreements where the limitations imposed by the "Iron Triangle" of fixed timelines, budgets, and scope challenge their ability to embrace change and focus on value delivery. Agile practitioners often comment that agile contracting is a difficult problem, but proven solutions are rarely presented.
Agile development requires architects and architecture, but the current user story-centric approach ignores the qualities of systems, instead overly focusing on features and functions. Sadly, developers who depend primarily on stories miss enormous value-creation opportunities for stakeholders. Developers often think system qualities (non-functional requirements) are someone else's responsibility to define. Even when defined, these qualities are typically not quantified, instead specified with vague terms such as "faster" and "better".
A prevailing myth in the software industry is that business analysis requires a bloated requirements elicitation and documentation process. Although the Business Analysis Body of Knowledge (BABOK) is considered to be process agnostic, many business analysts create heavy requirements when they follow this document's guidelines. Bob Hartman busts this myth by explaining how to use generally accepted practices from the BABOK in an agile way.
Often, examples of agile successes are presented in the context of small, software-only development teams. Michael Kirby describes what it took to deploy agile development techniques in a large, embedded software development organization. Michael describes the successes-and some of the failures-of deploying agile development in Xerox's Production Printer Development Team.
Whether you are working on a new development effort or the next release of an existing system, you are probably required to make a compelling business case for the proposed work to clear an approval committee's "go/no-go" process. As an approval prerequisite, many organizations require big up-front planning and estimating resulting in a "complete" project plan including dates, costs, and resources. However, a key aspect of agility is an incremental, just-in-time approach to planning and estimating.
Agile projects and traditional projects are tracked differently. The key difference is that agile projects track outcomes; traditional projects track activities. Project managers who are new to agile are often unsure which measures are relevant to which stakeholders and how to interpret them, and how agile metrics tie back to some of the more familiar forms of project reporting.
Agile development has become mainstream in the past few years, and for thousands of companies around the world, it has succeeded in reducing risk and delivering more value for less money. Yet, with the emphasis on pleasing the customer, and the philosophy of doing the simplest thing that could possibly work, there's one area where agile development has fallen short of more traditional methodologies-creating highly usable software.
"Are you done yet?" The answer to this question may sink your career, your team, and your project. If you respond with a "yes," you may be forced to take on additional work you can't handle. If you say "no," you may be branded as someone who can't get things done. Mitch Lacey notes that this innocent question is asked countless times on almost every software project. Establishing an upfront, common understanding of "done" can save teams and businesses countless hours of rework, process-thrash, unclear communication, and hidden work.