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 processes work better if developers and customers have specific aptitudes and attitudes, such as the ability and willingness to handle rapid change. Members of an agile product team cannot always be selected to ensure that they have these capabilities. Developers may not appreciate the need for unit testing while customers may not be able to interact easily to create just-in-time requirements. In this interactive class, you first outline people issues you have faced.
What is agile software development all about? Why is it fundamentally different from other approaches and will it work for you and your organization? Join Andy Hunt, one of the seventeen original authors of the Agile Manifesto and a founder of the Agile Alliance, for his pragmatic answers to these and other questions. Examine the foundations of agile software development and learn what problems agility seeks to address. Don't be distracted by dogma-take some time to explore the core aspects of agile development.
Since Martin Fowler completed his now-classic work Refactoring: Improving the Design of Existing Code, few programming practices have been more effective-and more controversial-than refactoring. Refactoring is effective when you study and practice it diligently. It remains controversial because many development managers think developers should be adding features, not reworking old code. J. B.
Agile methods put a great deal of emphasis on trust, empowerment, and collaboration. Agile moves us away from command and control project management toward an approach designed to harness the passion, creativity, and enthusiasm of the team. A successful transition to agile project management hinges largely on how well traditional project managers are able to adopt new ways of thinking about project structure and control.
Leaders can stifle progress when they interfere with team processes. But as a leader, you don't want an on-track project to go over the cliff and deliver the wrong results either. There are times when leaders should stand back and let the team work and times when they should step up and lead. How do we know which is which? Pollyanna Pixton focuses on collaboration and teaches you how to step back by unleashing the talent in your organization and teams.
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.