Picture this scene from three years ago: Employing the corporately mandated processes, a software engineering team is delivering system updates about once every nine months. When their senior user suddenly demands the next delivery in twenty-two weeks-half the current cycle duration-the team realize that they must quickly change development practices. Mathew Bissett describes how Her Majesty's Government did precisely that-and much, much more. First, they reduced delivery cycles from unpredictable dates every nine months to predictable releases every six weeks. Then, they cut releases cycle time to once every week. By identifying and mitigating risks early in the work intake process, enforcing quality gates, executing multiple test levels concurrently-and more-they dramatically increased throughput with the same or better quality. Today, these new processes provide their teams the best balance of structure versus agility.
As if releasing a quality software project on time were not difficult enough, poor management dealing with planning, people, and process issues can be deadly to a project. Presenting a series of anti-pattern case studies, Ken Whitaker describes the most common deadly habits-and ways to avoid them. These seven killer habits are mishandling employee incentives; making key decisions by consensus; ignoring proven processes; delegating absolute control to a project manager; taking too long to negotiate a project's scope; releasing an "almost tested" product to market; and hiring someone who is not quite qualified-but liked by everyone. Whether you are an experienced manager struggling with some of these issues or a new software manager, you'll take away invaluable tips and techniques correcting these habits-or better yet, avoiding them altogether.
One principle architects employ when designing buildings is "form follows function." That is, the layout of a building should be based upon its intended function. In software, the same principle helps us create an integrated design that focuses on fulfilling the intent of the system. Ken Pugh explores congruency-the state in which all actions work toward a common goal. For example, as Ken sees it, if you form and promote integrated teams of developers, testers, and business analysts, then personnel evaluations should be focused on team results rather than on each individual’s performance. If you embrace the principle of delivering business value as quickly as possible, the entire organization should focus on that goal and not the more typical 100% resource utilization objective. If you choose to have agile teams, then they should be co-located for easy communication, rather than scattered across buildings or the world.
For the past couple of years, Dan North has been working with and studying teams who are dramatically more productive than any he's ever seen. In weeks they produce results that take other teams months. One of the central behaviors Dan has observed is their ability to embrace uncertainty, holding multiple contradictory opinions at the same time and deferring commitment until there is a good reason. Embracing uncertainty lies at the heart of agile delivery and is one of the primary reasons organizations struggle with agile adoption. We are desperately uncomfortable with uncertainty, so much so that we will replace it with anything-even things we know to be wrong. Dan claims we have turned our back on the original Agile Manifesto, and explains why understanding risk and embracing uncertainty are fundamental to agile delivery-and why we find it so scary.
Agile practices have proven to help software teams develop better software products while shortening delivery cycles to weeks and even days. To respond to the new challenges of cloud computing, mobility, big data, social media, and more, organizations need to extend these agile practices and principles beyond software engineering departments and into the broader organization. Adaptive leadership principles offer managers and development professionals the tools they need to accelerate the move toward agility throughout IT and the enterprise. Jim Highsmith presents the three dimensions of adaptive leadership and offers an integrated approach for helping you spread agile practices across your wider organization. Jim introduces the “riding paradox” and explores the elements of an exploring, engaging, and adaptive leadership style.
As engineers and doers, we make rational, well-thought-out decisions based on facts and figures. Or do we? Philippe Kruchten has identified not so rational strategies and tactics software people use while developing new, bold, and complex software-intensive systems. In addition to strategies such as divide-and-conquer, brainstorming, and reuse, Philippe has observed some strange tactics, biases, and reasoning fallacies. If not understood and managed, these “games”-intentional or not-can creep in and pervert the software development process. They go by simple, funny, and sometimes fancy names: anchoring, red herring, elephant in the room, argumentum verbosium, and others. Philippe shares an illustrated gallery of the games software people play and shows you how they combine to become subtle and elaborate political ploys.
Philippe Kruchten, Kruchten Engineering Services, Ltd.
How far can you take agile within an organization? Is it enough to just focus on agile development practices such as Scrum and XP or is something more needed? Agile is much more than just a development methodology. Beyond product development, it can become an organizational strategy for increased success. Skip Angel shares an example of one company's journey from no knowledge of agile to an organization of high agility. He answers many of your questions about transformation that can help your company on its journey to agility, especially how to get started. Skip describes the preconditions a company must be ready to accept-significant organizational changes and the major activities and events that happen during the transformation process. Agile changes organizations in terms of who they are, how they think, and what they can achieve.
While many industries have adopted agile, the medical device industry, which develops products for life-critical applications-where quality and reliability are clearly a top-priority, remains largely stuck under the “waterfall.” Medical device firms must comply with FDA regulations that overwhelmingly suggest a controlled, phase-gated approach to software development. Unfortunately, many companies and development organizations interpret FDA regulations to require a steep waterfall. Many industry long-timers incorrectly see agile as an undisciplined style of software development. Neeraj Mainkar demonstrates how those in regulated industries can overcome these and other hurdles. At Neuronetics, he helped implement key elements of agile while fully complying with FDA regulations.
To deliver high-value products, your agile team must reach a shared understanding of prioritized stakeholder needs. Collaborative techniques are best for this type of work, but not all agile teams use them or use them efficiently. Some rely too heavily on written user stories or story maps and fail to address complex topics or resolve requirements conflicts among stakeholders. Ellen Gottesdiener outlines how you can systematically collaborate about the product backlog in nimble, timely workshops that give your team an open venue for working together to make complicated decisions. Ellen explores collaborative techniques for backlog discovery and preparation. She teaches you to use the Seven Dimensions technique to make sure you capture all product needs.
Knowing the rules of chess doesn’t equip you with strategies to win the game-much less make you a chess master. In the same way, many Scrum teams and their organizations know the rules but never consider longer-term strategies for getting the most out of Scrum. Sadly, of the thousands of organizations using Scrum, only a small fraction realizes Scrum’s true potential. To help address this epidemic and offer teams and companies ways to get more out of Scrum, the Scrum Framework has been codified in the Scrum Guide 2011. Rob Maher explains what elements of Scrum were revised and why, and offers practical guidance on avoiding common missteps that plague failing Scrum teams and organizations. Rob describes the extension model which allows the Scrum Guide to be expanded to support related strategies and practices.