Agile Development in the Real World 1st ed. Edition

The author is an experienced (and certified) project manager of agile projects (p. xxi). He uses Morris and Giraldi’s (2011) division of project work into two “regions”.• Region 1 focuses on the core of the technical work and the primary focus of agile practices. It is covered primarily in Part 3 (the last half of the book).• Region 2 focuses on what is necessary to get a project approved and out-the-door with a successful result. It is defined by the organizational culture, structure, politics, etc., and is covered in Parts 1 and 2 (the first half of the book).The author answers the question "Who should read this book?" in the Introduction (pp. xxv-xxviii). by describing different reading/skimming paths through the book for three types of readers: (1) project managers, (2) upper management, and (3) technical team members. The book is information dense because it covers Agile project levels from the highest overview down to the deep details. The book includes icon-marked side notes containing key points and recommendations, examples, warnings, etc.The chapters are ordered in the activity sequence of a real project, from beginning to end. Consequently, the book could be skimmed in parts as an overview or read in detail as a 'hand-holding' guide while working through an agile project.The two Tables of Contents do not present a good view of what is in the book: the first is too shallow (lists only the chapter titles), and the second is too deep (lists almost every page).The following summary outline makes it easier to identify the contents of the chapters.PART 1: Getting Started (Chapters 1 - 3)1. Evolution of Project Management – Puts agile project management in a historical context and compares agile with traditional approaches to software development.2. The Birth of a Project: Portfolio Management – Why and how to select a project and to get it sponsored and approved with a project manager assigned to the project.3. Project Startup – What you need to do to get a project started on track. Defines the documentation required to comply with the agile axiom “barely sufficient documentation.” The focus is on what the business team (e.g., project manager, business stakeholders, and others as needed) are to do before the technical team is in place.PART 2: Iteration 0 (Chapters 4 - 7)4. Preparing the Project – Creating the technical team and refining its agile practices, defining high-level architecture, infrastructure, support tools, the functionality process (e.g., validation and traceability), and enough system functionality for Iteration 0. Refine and manage expectations for scope, time, cost and quality.5. Architecture: Product Foundation – Provides a general architectural strategy with the goal of easy changes and minimal maintenance.6. Infrastructure: Supporting the Project – The four support environments (requirements, development, testing, and staging) are related in a process diagram for the project. He also discusses the external production environment and the project environment. Then he discusses the tools needed within the environments.7. Initial Requirements: Defining the Product – This is the next step of “progressive elaboration” (achieving a greater level of detail as the project evolves). The focus is eliciting high-level requirements from subject-matter experts (SMEs), and then decomposing them by elaborating their details and prioritizing the results.PART 3: Iteration 1 to N [This is the second half of the book, with Chapters 8 - 12.]8. Overview of an Agile Iteration – This chapter provides a description of the iteration process, tasks and what is produced for the team as a whole. It defines the four “threads” of work as requirements, development, testing, and project management. These relate back to the environments identified in Chapter 6, and each is discussed in detail in one of the following chapters.NOTE: Chapter 8 also includes a list of 17 “boxes” that identify and describe a specific activity that happens during an agile iteration (e.g., Code and run integration tests). These box numbers are referred back to in each of the four role-oriented chapters that complete the book.9. Requirements Thread – Provides an in-depth look at what is done to elicit detailed requirements and convert them to input for the developers. In some teams this is the role of the Business Analyst. In other teams, the work is done by people who are working under other role names (such as Product Owner in projects using the Scrum process).10. Development Thread – The role of “developer” in an agile project includes several different technical specializations. This chapter provides a heuristic or guidelines for a developer during an iteration.11. Testing Thread – There are different kinds of tests and testers for an agile team. This chapter provides a heuristic or guidelines for a developer during an iteration.12. Project Management Thread – This discusses the two roles of an agile project manager: one that is similar to traditional project management, and one that is specific to inside iterations.Each chapter contains a “PMI Parallels” section that (a) compares agile to traditional practices, and (b) relates agile practices to the 10 Bodies of Knowledge in the PMBOK, 2013 (Project Management Book of Knowledge).In summary, this book is useful for a wide range of readers. On one hand, it provides a detailed step-by-step process for a project manager or members of the technical team. On the other hand, it is also a good source of information for business team members, ranging from someone deciding whether to sponsor a project to someone who is detailing requirements for input to the developers writing code.Disclosure: I had input into the book before it was published, and I was provided a review copy.