book

Becoming Agile

Name: Becoming Agile
ISBN: 9781933988252

by Greg Smith, Ahmed Sidky

May 2009

Beginner

408 pages

11h 4m

English

Manning Publications

Read now

Unlock full access

Copyright
Foreword
Preface
Acknowledgments
About this book
RoadmapAbout the graphicsAuthor Online
About the cover illustration
I. Agile fundamentals and a supporting case study
1. Moving to agile
1.1. Is Agile just another process?1.1.1. The Agile Manifesto and related values1.1.2. The agile principles1.1.3. The agile practices1.2. A paradigm shift from a plan-driven mentality1.3. Agile and the bottom line1.4. How this book will help you become more agile1.5. Key points to remember1.6. Looking ahead
2. The story of Acme Media
2.1. Case study background and circumstances2.2. About the Acme Media teams2.3. About the individuals2.4. What does it look like when a team "becomes agile"?2.4.1. The existing process2.4.2. A process with more agility2.4.3. The ultimate process2.5. Key points to remember2.6. Looking ahead
II. Getting started

3. Are you ready for agile?
3.1. What areas will you become more agile in?3.1.1. Increasing customer involvement3.1.2. Improving prioritization of features3.1.3. Increasing team buy-in and involvement3.1.4. Clarifying priorities and reminding everyone of the consequences of changing them3.1.5. Adapting to change during development3.1.6. Better understanding the project's status3.1.7. More efficient planning and estimating3.1.8. Continuous risk management3.1.9. Delivering the project needed at the end3.1.10. Achieving the right level of project structure3.2. The different flavors of agile3.2.1. Scrum3.2.2. Extreme Programming3.3. Create your own flavor to become agile within your constraints3.3.1. Your goal: reach the right level of agility for your organization3.3.2. Characteristics that make agile easier to adopt3.3.3. Roadblocks that others have overcome3.4. Key points to remember3.5. Looking ahead
4. The fitness test: all about readiness assessments
4.1. The importance of readiness assessments4.2. Reducing the risks of agile adoption using assessments4.3. Increasing productivity during transitions4.4. Getting executive buy-in for agile adoption using readiness assessments4.5. Conducting readiness assessments4.5.1. Readiness-assessment tables4.5.2. Finding out the results4.6. Key points4.7. Looking ahead
5. The importance of obtaining executive support
5.1. Why should we pursue agile?5.2. The cost of migrating5.3. The risks in migrating5.4. Rewards for the executives5.5. Communicating frequently with your executive team5.6. The role of the sponsor5.7. Following Acme Media as the company obtains a sponsor5.8. Key points5.9. Looking forward
6. Improving buy-in by creating a core team
6.1. Who should be in the core team?6.2. Choosing the core team at Acme Media6.3. The kickoff meeting6.3.1. Tough questions6.3.2. Your role in the migration6.4. Key points6.5. Looking forward
7. The mindset of an agile leader
7.1. The role of an agile coach7.1.1. Attributes of a good coach7.1.2. Training and mentoring the core team7.2. Agile management: more shepherding, less directing7.2.1. Soft skills7.2.2. Working with other managers7.2.3. Working with stakeholders7.2.4. Demonstrating value7.2.5. Leading the team to ownership7.3. Creating a team with an agile mindset7.3.1. Culture and roles7.3.2. Characteristics that influence individual performance7.4. Key points7.5. Looking forward
8. Injecting agility into your current process
8.1. Understanding your current process8.1.1. Documenting the existing process with Acme Media8.1.2. Deciding what to keep: identifying existing valuable practices8.1.3. Another potential tool: documenting a perfect process8.2. Enhancing the existing process8.2.1. Deciding what to change at Acme Media8.2.2. Feasibility phase8.2.3. Planning phase8.2.4. Development phase8.2.5. Adapt phase8.2.6. Deployment phase8.3. Key points8.4. Looking forward
9. Selecting a pilot project
9.1. Characteristics of a good pilot9.1.1. A project you can complete in 2 to 8 weeks9.1.2. A medium-priority project9.1.3. A project that hits all phases and areas9.1.4. No external customers9.2. Evaluating projects at Acme Media9.2.1. Request backlog9.2.2. Selecting a pilot project: an example9.3. Key points9.4. Looking forward
III. Kicking off
10. Feasibility: is this project viable?
10.1. Feasibility in the big picture10.2. Selecting a feasibility team10.2.1. Selecting feasibility team members at Acme Media10.3. Introducing the known requirements to the feasibility team10.3.1. What does a feasibility investigation look like?10.3.2. Analyzing an idea with the Feasibility Discussion Guide10.3.3. Feedback from the Acme Media feasibility team10.3.4. Modifying the idea during feasibility analysis10.3.5. Reacting to the feedback10.3.6. Team review of the modified concept10.3.7. Regrouping after technical analysis10.3.8. Summarizing the feasibility work10.4. The go/no go decision10.5. Alternate feasibility paths10.5.1. What people are talking about10.5.2. Feasibility for risk management vs. go/no go10.6. Key points10.7. Looking forward
11. Aligning the pilot team with the project
11.1. Identifying the pilot team11.2. Preparing the pilot team11.2.1. Ensure everyone is trained on agile11.2.2. Providing a mechanism for feedback11.3. Envisioning the product11.3.1. Creating an elevator statement11.3.2. Introduce the team to the features11.3.3. Common understanding of the features11.4. The tradeoff matrix11.5. Project worksheet11.5.1. Team members11.5.2. Objective statement11.5.3. Issues and risks11.5.4. Technical considerations11.5.5. Stakeholders11.5.6. User/customer benefits11.5.7. Highlights11.5.8. Major milestones11.5.9. Elevator statement11.6. Key points11.7. Looking forward
IV. Populating the product backlog
12. Feature cards: a tool for "just enough" planning
12.1. The structure of a feature card12.1.1. The right amount and type of information12.1.2. Additional feature-card benefits12.2. A team approach to creating feature cards12.2.1. Creating a feature card at Acme Media12.2.2. Reviewing the feature cards as a team12.3. Feature cards compared to...12.3.1. User stories12.3.2. Use cases12.3.3. Functional specifications12.4. Limitations in using feature cards12.4.1. Project complexity12.4.2. The customer isn't available12.4.3. Compliance and traceability12.5. Hard-copy cards vs. electronic cards12.6. Key points12.7. Looking forward
13. Prioritizing the backlog
13.1. The art of prioritizing, sequencing, and grouping features13.2. Prioritizing the backlog at Acme Media13.2.1. Prioritizing by value13.2.2. Evaluating risk13.2.3. Grouping related features13.3. Other ways to prioritize features13.3.1. What about technical features?13.4. Key points13.5. Looking forward
14. Estimating at the right level with the right people
14.1. Contrasting traditional and agile estimation techniques14.2. The importance of whole-team estimation14.3. A step toward agility: estimating size, not effort14.3.1. Using story points for quick estimation14.3.2. Planning poker14.4. Estimating story points at Acme Media14.5. Key points14.6. Looking forward
V. Enough information for scheduling
15. Release planning: envisioning the overall schedule
15.1. Defining the pieces of a release plan15.1.1. Iteration 0 length15.1.2. Development iteration length15.1.3. How long do you need between iterations?15.1.4. Determining the overall timeline15.2. Completing the release plan by assigning features to iterations15.2.1. Assigning features to iterations at Acme Media15.3. Communicating the release plan with a kickoff meeting15.4. Key points15.5. Looking forward
16. Iteration planning: the nitty-gritty details
16.1. Clearly defining the goals: what is "feature complete"?16.2. Using feature modeling to identify and estimate tasks16.2.1. Outlining the workflow for a feature16.2.2. Discovering new features16.2.3. Outlining the screens for a feature16.2.4. Adding details to a screen by considering user interaction16.2.5. Is modeling worth it?16.3. Identifying and estimating tasks16.4. Determining the hours available in an iteration16.5. Bringing estimates and capacity together to complete the plan16.6. Making status visible16.6.1. Visibility within an iteration16.6.2. Tracking release status16.6.3. Finding tools that work for you16.7. Key points16.8. Looking forward
VI. Building the product
17. Start your engines: iteration 0
17.1. Initial vision for the architecture17.2. Completing contracts with third parties17.3. Preparing environments and support tools17.4. Obtaining funding17.5. Finalizing and dedicating the project team17.6. Cheating: starting the work early17.7. Key points17.8. Looking forward
18. Delivering working software
18.1. Supporting the agile principles during development and testing18.1.1. Satisfy the customer through early and continuous delivery of valuable software18.1.2. Have business people and developers work together daily throughout the project18.1.3. Whenever possible, communicate face to face18.1.4. Pay attention to technical excellence and good design18.1.5. Focus on simplicity and the art of maximizing the amount of work not done18.1.6. Welcome changing requirements, even late in development18.1.7. Test early, and test often18.1.8. Continuously integrate code changes18.1.9. Obtain customer feedback as early as possible18.1.10. Minimize team distractions during development iterations18.2. Where to begin?18.2.1. Sequence within an iteration18.2.2. Making assignments18.3. Completing a feature18.3.1. What the work looks like18.3.2. Other considerations for development iterations18.4. Key points18.5. Looking forward
19. Testing: did you do it right?
19.1. Unit testing19.2. Integration testing19.3. Functional testing19.4. Exploratory testing19.5. Test automation19.6. Key points19.7. Looking forward
VII. Embracing change
20. Adapting: reacting positively to change
20.1. Common reasons for adapting20.1.1. Feature is larger than expected20.1.2. Customer refinement of requirements20.1.3. The business need changes20.1.4. A technical constraint is discovered20.1.5. A team member is unavailable20.1.6. A third party doesn't deliver20.1.7. Team throughput is lower than expected20.2. Adapting during an iteration20.3. Three ways Acme Media adapted during its first iteration20.3.1. A change in feature scope20.3.2. An issue with performance20.3.3. Underestimating the registration need20.4. Adapting at the end of an iteration20.4.1. Demonstrating and gathering feedback20.4.2. Re-evaluating priorities: what are your options?20.4.3. Reviewing team performance and velocity20.4.4. Re-planning and reacting20.5. How Acme Media adapts during adapt week20.5.1. Reviewing the work completed20.5.2. Demonstrating the work20.5.3. Personality types and demonstrations20.5.4. Demonstrating incomplete features20.6. User Acceptance Testing20.6.1. Acme Media's UAT approach20.6.2. Output from Acme Media's UAT20.7. Changes in the business climate20.8. Reviewing the findings and revising the plan for the next iteration20.8.1. Evaluating team velocity20.8.2. New work identified during the iteration20.8.3. Features originally slated for iteration 220.9. Key points20.10. Looking forward
21. Delivery: bringing it all together
21.1. When to release21.1.1. To support a constraint21.1.2. To meet a predetermined schedule21.1.3. When there is enough value21.1.4. To test the product21.2. Final testing21.2.1. What about quality level?21.2.2. Completing functional/usability testing21.2.3. Completing the user acceptance process21.2.4. Validation of nonfunctional requirements21.3. Preparing support groups and processes21.3.1. The running maintenance and support worksheet21.3.2. Finalizing help materials and support processes21.3.3. Enabling system monitoring, and creating an escalation process21.3.4. Enabling maintenance and background processes21.4. Communication and training21.5. Ready to release21.5.1. Deciding to go live21.5.2. Planning the deployment steps21.5.3. Deployment considerations21.5.4. Creating a deployment and backout plan21.5.5. Reducing risk with a pilot21.6. Enough planning; let's deploy21.6.1. Celebrate!21.7. Key points21.8. Looking forward
22. The retrospective: working together to improve
22.1. Setting expectations for the retrospective22.2. Time to digest: a survey in advance22.3. Conducting the retrospective meeting22.4. What to expect during the meeting22.5. Converting the feedback into action22.6. Key points22.7. Looking forward
VIII. Moving forward
23. Extending the new process across your company
23.1. Common findings after a pilot23.1.1. Slower than the old process23.1.2. Confusion about the process23.1.3. Team polarization23.1.4. Starting to feel agile23.2. What the Acme Media team learned from their pilot23.2.1. Embracing change to deliver customer value23.2.2. Customer involvement and feedback23.2.3. Planning and delivering software frequently23.2.4. Technical excellence23.2.5. Human-centric practices23.3. Next steps23.3.1. Spanning the chasm23.3.2. Using the SAMI23.3.3. Agile practices23.4. Key points23.5. Conclusion
A. Readiness assessment tables by practice
B. Agile concepts from a phase perspective
B.1. Overview of the phasesB.2. Feasibility: define and validate your visionB.3. Planning: speculate and create a living planB.4. Development: exploration with a scheduleB.5. Adapt: react to new informationB.6. Deployment: deliver, train, revisit, and close the project
C. Agile process overview in text
C.1. Feasibility phaseC.2. Planning phaseC.3. Development phaseC.4. Delivery phase
D. Example: determining process and document needs for a project
E. Quantitative feedback on the SAMI
Resources

Content preview from Becoming Agile

Part V. Enough information for scheduling

When chapter 14 concluded, Acme Media had a prioritized and estimated product backlog. In this section we will take the backlog and assign the features to iterations, which will allow us to provide our first pass at a release schedule.

In the following two chapters we will discuss how to create an overall release plan and how that plan is enriched before each iteration begins. We will also discuss obtaining team commitment for the iteration by involving the members in the detailed iteration planning process.

You may recall one of the main agile principles, responding to change over following a plan. This is especially true when it comes to creating release and iteration plans. We do create plans, but we ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781933988252Publisher Support Publisher Website

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Becoming Agile

by Greg Smith, Ahmed Sidky

Part V. Enough information for scheduling

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.