You may be wondering if there is a need for another book on agile. We have dozens of books on Extreme Programming and Scrum. Areas such as retrospectives, Test Driven Development, and estimating have been covered well. It seems every subject has been thoroughly discussed. However, one area that still does not have a lot of coverage is the actual process of adopting agile. You may find all of the information you need related to agile practices, but you may have a hard time finding information on how to go from your existing process to an agile one.
The authors have created this book in the hope of providing more information on what it takes to move to a more agile process. We have taken all of our migration experiences and rolled them into this book to help you with your own agile adoption. To make the adoption steps even more tangible, we have created a case study that is an amalgamation of our experiences. As you follow the case study, you will be reviewing actual situations that we encountered during migrations and how the companies we worked with dealt with constraints and cultural change. Real company names are not used, but the events are real.
Our case study also helps you envision working with different personality types and experience levels during a migration to agile. We will introduce several personas at the start of the pilot project, and you will see how the personas react to the process and cultural changes of an agile environment.
The approach we outline in this book is based on five key observations we have made:
Moving to agile is not a straightforward process. Every organization has unique constraints it must address.
Adopting agile can be risky and even harmful if done incorrectly.
Many teams try to use popular agile practices before they are ready for them. They believe they “are not agile” if they are not using techniques such as Test Driven Development or Pair Programming.
Many teams rush to adopt agile practices without properly embracing the agile values and principles. They assume “that’s how we become agile.”
Many teams start from scratch when moving to agile, discarding legacy practices that may have been effective and valuable in their environment.
We address these five discoveries with the following approach.
First, we understand the realities of constraints within a company. We have witnessed agile constraints such as
Distributed teams
The need to support production operations in parallel with projects
Compliance and regulatory constraints
Limited employee experience
Limited customer availability
And many more
To support these realities we will walk you through a process of reviewing your existing process and performing an assessment/survey of your company culture and maturity. This process will allow you to identify many barriers before you begin your migration, and you can make an informed decision about which constraints to accept and which ones to challenge as you move to agile.
Second, we have witnessed the risks associated with moving to agile. We have seen product delivery jeopardized, and we have seen employees become upset with a change to the development process.
To minimize these risks we will guide you through a process that involves the development team in the migration. Any concerns the team has with the new process will be taken into account because the team will be involved in creating the new agile process for your company. Involving the team will also help you create an agile lifecycle that should flourish in your environment. Your team is closest to the work, and they will know how things work today and in which areas a change could introduce high risk.
Related to the third observation and the desire to use popular practices, the assessment tool we provide will help you determine which practices the team, company, and customer can support. We will not encourage you to pursue the most trendy or popular practices. Instead we will ask you to select practices that add value for your situation.
Concerning the fourth item and the desire to become agile overnight, we have seen many companies try to shotgun agile in, attempting to get through the pain as quickly as possible. While there are situations where this makes sense, it can be a risky approach. Instead we will walk you through an iterative process for bringing agile into your organization. We will guide you through developing and piloting an agile process that meets your needs, and we will provide a system for maintaining, improving, and sustaining the lifecycle over time.
Lastly, concerning starting from scratch, if you are a startup, or if your company is very dysfunctional, it may make sense to start from scratch and throw away everything you currently do. However, if you have significant experience with your company, you probably have some practices that add value, and these practices may continue to add value as you move to agile. In many cases it will not make sense to discard everything you do today.
Our hope is that we can show you how to make your team and organization become as agile as possible within your current constraints.
Roadmap
Chapter 1 discusses why agile is a better development process. The chapter also ties agile to the two most important factors for most companies: increasing revenue and lowering costs.
Chapter 2 introduces our case study and the circumstances that have added urgency to its projects. The chapter also provides an example of a company going from no agility, to medium-level agility, to high agility.
Chapter 3 discusses the ability for any company to increase its agility and how you can become agile within your constraints.
Chapter 4 kicks off our approach for becoming agile. We will walk you through a process of assessing your ability to use each agile practice.
Chapter 5 builds on the assessment from chapter 4. Now that you have an understanding of your ability to become agile, you will pursue executive support within your company. You will also follow along as our case study pursues executive support and obtains an executive sponsor.
Chapter 6 discusses the selection of the “core team.” This core team is made up of project team members and includes agile supporters, agile detractors, and people on the fence. Working with their coach, the core team will determine which agile practices to pilot.
Chapter 7 talks about the agile mindset and how managers need to shift to more of a coaching role as the team matures.
Chapter 8 focuses on designing a development process that works for a specific environment. Acme Media’s core team will document their existing process and compare it to an agile process. The core team will then document modifications to the existing process to make it more agile. This new process will be piloted on a test project.
Chapter 9 walks you through the process of identifying a pilot project to test your new, more agile process. We will provide guidelines for how to select a pilot project based on size, scope, and priority.
Chapter 10 starts the pilot project. Acme Media will analyze the pilot to verify it is feasible. The feasibility work answers two questions: (1) is the project technically possible? and (2) is there truly a market/need for this project?
Chapter 11 shows the selection of the project team members who will perform the pilot. The pilot team will go through an exercise of chartering and alignment to reach a clear understanding on the project benefits and objectives. Chartering will also expose the main features of the pilot.
Chapter 12 explains feature cards and how Acme Media learns to create the correct level of requirements throughout the project. Historically Acme Media has created detailed specifications before work begins. Feature cards will require a change in mindset.
Chapter 13 follows Acme Media as it more clearly defines and prioritizes features for the project. The features are prioritized by business value and risk.
Chapter 14 introduces Acme Media to a new approach on early estimation: estimating for relative size versus identifying tasks and trying to map out the project hour by hour. The work in this chapter is based on the story-point process that Mike Cohn promotes in his book Agile Estimating and Planning.
Chapter 15 leads Acme Media through the process of creating an overall release/project schedule. Iterations are identified, and the team compares capacity to estimates to determine what features will be initially targeted for each iteration.
Chapter 16 follows Acme Media through detailed iteration planning. The team will identify the tasks for each feature in iteration 1 and verify that they can commit to the features that were assigned during release planning. The team will also create a burndown chart to support daily meetings and transparency of iteration status.
Chapter 17 covers iteration 0, the time needed to get foundational pieces of the project in place before development begins. This includes environment preparation, finalization of funding, and negotiation of contracts with vendors or partners that may be needed for the project.
Chapter 18 follows Acme Media through the first iteration of development. The team will begin designing, coding, refining, testing, and delivering features in the 10 working days allocated for the iteration. The team will focus on early testing and integration of features to identify requirement gaps or technical issues as soon as possible.
Chapter 19 covers the different types of testing in an agile environment. These include unit, integration functional, exploratory, and usability testing. We also focus on identifying tests that can be automated to speed up the build process.
Chapter 20 is about adapting during and after an iteration. This chapter, more than any other, demonstrates what it is like to work in an agile environment and respond successfully to discoveries during a project. The chapter also discusses customer demonstrations and validating status via the measurement of working code.
Chapter 21 focuses on aggregating iterations and releasing them to a production environment. We discuss important areas such as determining when quality is good enough for releasing and validation of nonfunctional requirements.
Chapter 22 is about project retrospectives. We identify the common issues with retrospectives and walk you through a process that optimizes the use of everyone’s time. We also follow Acme Media through a retrospective and provide templates and guides that you can use during your retrospectives.
Chapter 23 is about “what’s next?” We review what Acme Media learned from its pilot and discuss what it takes to go from project-level agile adoption to enterprise-level adoption. We also introduce the Sidky Agile Measurement Index (SAMI). The SAMI highlights five agile value levels or steps and guides organizations in introducing the practices that satisfy each step.
About the graphics
Most of the photos and illustrations in this book were created by the authors or obtained via stock photos, unless otherwise noted. Several graphics and photos have been reduced to fit the format of this book. You can view and download many of the graphics in full size from the publisher’s website: www.manning.com/BecomingAgile.
Author Online
The purchase of Becoming Agile includes free access to a private forum run by Manning Publications where you can make comments about the book, ask technical questions, and receive help from the authors and other users. To access and subscribe to the forum, point your browser to www.manning.com/BecomingAgile or www.manning.com/smith. This page provides information on how to get on the forum once you are registered, what kind of help is available, and the rules of conduct in the forum.
Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the authors can take place. It’s not a commitment to any specific amount of participation on the part of the authors, whose contribution to the book’s forum remains voluntary (and unpaid). We suggest you try asking them some challenging questions, lest their interest stray!
The Author Online forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.
