Becoming Agile

Becoming Agile

by Greg Smith, Ahmed Sidky
Released May 2009
Publisher(s): Manning Publications
ISBN: 9781933988252

Read it now on the O’Reilly learning platform with a 10-day free trial.

O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Book description

Agile principles have been a breath of fresh air to many development teams stuck in the middle of a rigid, process-driven environment. Unfortunately, it's not so easy to bring Agile into an existing organization with established people and practices. Becoming Agile shows you practical techniques and strategies to move from your existing process to an Agile process without starting from scratch.



About the Technology


About the Book

Many books discuss Agile from a theoretical or academic perspective. Becoming Agile takes a different approach and focuses on explaining Agile from a ground-level point-of-view. Author Greg Smith, a certified ScrumMaster with dozens of Agile projects under his belt, presents Agile principles in the context of a case study that flows throughout the book.

Becoming Agile focuses on the importance of adapting Agile principles to the realities of your environment. While Agile purists have often discouraged a "partial-Agile" approach, the reality is that in many shops a "purist" approach simply isn't a viable option. Over the last few years, Agile authorities have begun to discover that the best deployments of Agile are often customized to the specific situation of a given company.

As well, Becoming Agile addresses the cultural realities of deploying Agile and how to deal with the needs of executives, managers, and the development team during migration. The author discusses employee motivation and establishing incentives that reward support of Agile techniques.

Becoming Agile will show you how to create a custom Agile process that supports the realities of your environment. The process will minimize risk as you transition to Agile iteratively, allowing time for your culture and processes to acclimate to Agile principles.



What's Inside
  • How to migrate to Agile
  • How to get your team to buy into the change
  • How to scale and sustain your new Agile process
  • How to create an Agile process that works for your company
  • How to use Agile in special situations
  • How to iteratively build up your Agile process and culture


About the Reader


About the Authors

Greg Smith is a certified ScrumMaster and a Senior Project Manager. Greg is also an instructor of Agile Project Management at Bellevue Community College. Greg has over 20 years of experience as a development manager, project manager, business analyst, and product manager. He has worked for large conglomerates, tiny start-ups, and medium size companies including: Philips Electronics, R.R. Donnelley, Oh Boy! Oberto, and the Seattle Times New Media group. Greg helps companies create a custom agile process that supports the realities of their environment. Greg's focus has been on iteratively migrating a company to agile and actively involving the development team in the process. This background has given him insight into what it takes to sustain an agile culture and process over time.

Dr. Ahmed Sidky guides organizations during their transition to agile software development. His research includes a value-based agile measurement index, known as the Sidky Agile Measurement Index, and a process framework for the adoption of agile practices. Dr. Sidky developed Dr. Agile (www.dragile.com), an online readiness assessment tool that helps guide organizations aspiring to adopt agile practices. He has worked as a software developer at some of the largest software firms in the Middle East and holds a Masters degree in Software Engineering from Virginia Tech (USA) with a research focus on Requirements Engineering and a doctorate in Agile Software Development Methodologies and Process Improvement. Dr. Sidky is a frequent speaker at international agile conferences.



Quotes
A thoughtful, practical set of steps ... to become agile.
- Mary Poppendieck, author of the Foreword

Makes agility rhyme with reality.
- Valentin Crettaz, Consulthys

This book is a necessity for teams looking to become agile...
- Randy Miller, Microsoft

The first book I can give to anyone on an agile team, regardless of their role.
- Paul King, ASERT

A 5-star guide.
- Robert Dempsey, Atlantic Dominion Solutions

Table of contents

  1. Copyright
  2. Foreword
  3. Preface
  4. Acknowledgments
  5. About this book
    1. Roadmap
    2. About the graphics
    3. Author Online
  6. About the cover illustration
  7. I. Agile fundamentals and a supporting case study
    1. 1. Moving to agile
      1. 1.1. Is Agile just another process?
        1. 1.1.1. The Agile Manifesto and related values
        2. 1.1.2. The agile principles
        3. 1.1.3. The agile practices
      2. 1.2. A paradigm shift from a plan-driven mentality
      3. 1.3. Agile and the bottom line
      4. 1.4. How this book will help you become more agile
      5. 1.5. Key points to remember
      6. 1.6. Looking ahead
    2. 2. The story of Acme Media
      1. 2.1. Case study background and circumstances
      2. 2.2. About the Acme Media teams
      3. 2.3. About the individuals
      4. 2.4. What does it look like when a team "becomes agile"?
        1. 2.4.1. The existing process
        2. 2.4.2. A process with more agility
        3. 2.4.3. The ultimate process
      5. 2.5. Key points to remember
      6. 2.6. Looking ahead
  8. II. Getting started
    1. 3. Are you ready for agile?
      1. 3.1. What areas will you become more agile in?
        1. 3.1.1. Increasing customer involvement
        2. 3.1.2. Improving prioritization of features
        3. 3.1.3. Increasing team buy-in and involvement
        4. 3.1.4. Clarifying priorities and reminding everyone of the consequences of changing them
        5. 3.1.5. Adapting to change during development
        6. 3.1.6. Better understanding the project's status
        7. 3.1.7. More efficient planning and estimating
        8. 3.1.8. Continuous risk management
        9. 3.1.9. Delivering the project needed at the end
        10. 3.1.10. Achieving the right level of project structure
      2. 3.2. The different flavors of agile
        1. 3.2.1. Scrum
        2. 3.2.2. Extreme Programming
      3. 3.3. Create your own flavor to become agile within your constraints
        1. 3.3.1. Your goal: reach the right level of agility for your organization
        2. 3.3.2. Characteristics that make agile easier to adopt
        3. 3.3.3. Roadblocks that others have overcome
      4. 3.4. Key points to remember
      5. 3.5. Looking ahead
    2. 4. The fitness test: all about readiness assessments
      1. 4.1. The importance of readiness assessments
      2. 4.2. Reducing the risks of agile adoption using assessments
      3. 4.3. Increasing productivity during transitions
      4. 4.4. Getting executive buy-in for agile adoption using readiness assessments
      5. 4.5. Conducting readiness assessments
        1. 4.5.1. Readiness-assessment tables
        2. 4.5.2. Finding out the results
      6. 4.6. Key points
      7. 4.7. Looking ahead
    3. 5. The importance of obtaining executive support
      1. 5.1. Why should we pursue agile?
      2. 5.2. The cost of migrating
      3. 5.3. The risks in migrating
      4. 5.4. Rewards for the executives
      5. 5.5. Communicating frequently with your executive team
      6. 5.6. The role of the sponsor
      7. 5.7. Following Acme Media as the company obtains a sponsor
      8. 5.8. Key points
      9. 5.9. Looking forward
    4. 6. Improving buy-in by creating a core team
      1. 6.1. Who should be in the core team?
      2. 6.2. Choosing the core team at Acme Media
      3. 6.3. The kickoff meeting
        1. 6.3.1. Tough questions
        2. 6.3.2. Your role in the migration
      4. 6.4. Key points
      5. 6.5. Looking forward
    5. 7. The mindset of an agile leader
      1. 7.1. The role of an agile coach
        1. 7.1.1. Attributes of a good coach
        2. 7.1.2. Training and mentoring the core team
      2. 7.2. Agile management: more shepherding, less directing
        1. 7.2.1. Soft skills
        2. 7.2.2. Working with other managers
        3. 7.2.3. Working with stakeholders
        4. 7.2.4. Demonstrating value
        5. 7.2.5. Leading the team to ownership
      3. 7.3. Creating a team with an agile mindset
        1. 7.3.1. Culture and roles
        2. 7.3.2. Characteristics that influence individual performance
      4. 7.4. Key points
      5. 7.5. Looking forward
    6. 8. Injecting agility into your current process
      1. 8.1. Understanding your current process
        1. 8.1.1. Documenting the existing process with Acme Media
        2. 8.1.2. Deciding what to keep: identifying existing valuable practices
        3. 8.1.3. Another potential tool: documenting a perfect process
      2. 8.2. Enhancing the existing process
        1. 8.2.1. Deciding what to change at Acme Media
        2. 8.2.2. Feasibility phase
        3. 8.2.3. Planning phase
        4. 8.2.4. Development phase
        5. 8.2.5. Adapt phase
        6. 8.2.6. Deployment phase
      3. 8.3. Key points
      4. 8.4. Looking forward
    7. 9. Selecting a pilot project
      1. 9.1. Characteristics of a good pilot
        1. 9.1.1. A project you can complete in 2 to 8 weeks
        2. 9.1.2. A medium-priority project
        3. 9.1.3. A project that hits all phases and areas
        4. 9.1.4. No external customers
      2. 9.2. Evaluating projects at Acme Media
        1. 9.2.1. Request backlog
        2. 9.2.2. Selecting a pilot project: an example
      3. 9.3. Key points
      4. 9.4. Looking forward
  9. III. Kicking off
    1. 10. Feasibility: is this project viable?
      1. 10.1. Feasibility in the big picture
      2. 10.2. Selecting a feasibility team
        1. 10.2.1. Selecting feasibility team members at Acme Media
      3. 10.3. Introducing the known requirements to the feasibility team
        1. 10.3.1. What does a feasibility investigation look like?
        2. 10.3.2. Analyzing an idea with the Feasibility Discussion Guide
        3. 10.3.3. Feedback from the Acme Media feasibility team
        4. 10.3.4. Modifying the idea during feasibility analysis
        5. 10.3.5. Reacting to the feedback
        6. 10.3.6. Team review of the modified concept
        7. 10.3.7. Regrouping after technical analysis
        8. 10.3.8. Summarizing the feasibility work
      4. 10.4. The go/no go decision
      5. 10.5. Alternate feasibility paths
        1. 10.5.1. What people are talking about
        2. 10.5.2. Feasibility for risk management vs. go/no go
      6. 10.6. Key points
      7. 10.7. Looking forward
    2. 11. Aligning the pilot team with the project
      1. 11.1. Identifying the pilot team
      2. 11.2. Preparing the pilot team
        1. 11.2.1. Ensure everyone is trained on agile
        2. 11.2.2. Providing a mechanism for feedback
      3. 11.3. Envisioning the product
        1. 11.3.1. Creating an elevator statement
        2. 11.3.2. Introduce the team to the features
        3. 11.3.3. Common understanding of the features
      4. 11.4. The tradeoff matrix
      5. 11.5. Project worksheet
        1. 11.5.1. Team members
        2. 11.5.2. Objective statement
        3. 11.5.3. Issues and risks
        4. 11.5.4. Technical considerations
        5. 11.5.5. Stakeholders
        6. 11.5.6. User/customer benefits
        7. 11.5.7. Highlights
        8. 11.5.8. Major milestones
        9. 11.5.9. Elevator statement
      6. 11.6. Key points
      7. 11.7. Looking forward
  10. IV. Populating the product backlog
    1. 12. Feature cards: a tool for "just enough" planning
      1. 12.1. The structure of a feature card
        1. 12.1.1. The right amount and type of information
        2. 12.1.2. Additional feature-card benefits
      2. 12.2. A team approach to creating feature cards
        1. 12.2.1. Creating a feature card at Acme Media
        2. 12.2.2. Reviewing the feature cards as a team
      3. 12.3. Feature cards compared to...
        1. 12.3.1. User stories
        2. 12.3.2. Use cases
        3. 12.3.3. Functional specifications
      4. 12.4. Limitations in using feature cards
        1. 12.4.1. Project complexity
        2. 12.4.2. The customer isn't available
        3. 12.4.3. Compliance and traceability
      5. 12.5. Hard-copy cards vs. electronic cards
      6. 12.6. Key points
      7. 12.7. Looking forward
    2. 13. Prioritizing the backlog
      1. 13.1. The art of prioritizing, sequencing, and grouping features
      2. 13.2. Prioritizing the backlog at Acme Media
        1. 13.2.1. Prioritizing by value
        2. 13.2.2. Evaluating risk
        3. 13.2.3. Grouping related features
      3. 13.3. Other ways to prioritize features
        1. 13.3.1. What about technical features?
      4. 13.4. Key points
      5. 13.5. Looking forward
    3. 14. Estimating at the right level with the right people
      1. 14.1. Contrasting traditional and agile estimation techniques
      2. 14.2. The importance of whole-team estimation
      3. 14.3. A step toward agility: estimating size, not effort
        1. 14.3.1. Using story points for quick estimation
        2. 14.3.2. Planning poker
      4. 14.4. Estimating story points at Acme Media
      5. 14.5. Key points
      6. 14.6. Looking forward
  11. V. Enough information for scheduling
    1. 15. Release planning: envisioning the overall schedule
      1. 15.1. Defining the pieces of a release plan
        1. 15.1.1. Iteration 0 length
        2. 15.1.2. Development iteration length
        3. 15.1.3. How long do you need between iterations?
        4. 15.1.4. Determining the overall timeline
      2. 15.2. Completing the release plan by assigning features to iterations
        1. 15.2.1. Assigning features to iterations at Acme Media
      3. 15.3. Communicating the release plan with a kickoff meeting
      4. 15.4. Key points
      5. 15.5. Looking forward
    2. 16. Iteration planning: the nitty-gritty details
      1. 16.1. Clearly defining the goals: what is "feature complete"?
      2. 16.2. Using feature modeling to identify and estimate tasks
        1. 16.2.1. Outlining the workflow for a feature
        2. 16.2.2. Discovering new features
        3. 16.2.3. Outlining the screens for a feature
        4. 16.2.4. Adding details to a screen by considering user interaction
        5. 16.2.5. Is modeling worth it?
      3. 16.3. Identifying and estimating tasks
      4. 16.4. Determining the hours available in an iteration
      5. 16.5. Bringing estimates and capacity together to complete the plan
      6. 16.6. Making status visible
        1. 16.6.1. Visibility within an iteration
        2. 16.6.2. Tracking release status
        3. 16.6.3. Finding tools that work for you
      7. 16.7. Key points
      8. 16.8. Looking forward
  12. VI. Building the product
    1. 17. Start your engines: iteration 0
      1. 17.1. Initial vision for the architecture
      2. 17.2. Completing contracts with third parties
      3. 17.3. Preparing environments and support tools
      4. 17.4. Obtaining funding
      5. 17.5. Finalizing and dedicating the project team
      6. 17.6. Cheating: starting the work early
      7. 17.7. Key points
      8. 17.8. Looking forward
    2. 18. Delivering working software
      1. 18.1. Supporting the agile principles during development and testing
        1. 18.1.1. Satisfy the customer through early and continuous delivery of valuable software
        2. 18.1.2. Have business people and developers work together daily throughout the project
        3. 18.1.3. Whenever possible, communicate face to face
        4. 18.1.4. Pay attention to technical excellence and good design
        5. 18.1.5. Focus on simplicity and the art of maximizing the amount of work not done
        6. 18.1.6. Welcome changing requirements, even late in development
        7. 18.1.7. Test early, and test often
        8. 18.1.8. Continuously integrate code changes
        9. 18.1.9. Obtain customer feedback as early as possible
        10. 18.1.10. Minimize team distractions during development iterations
      2. 18.2. Where to begin?
        1. 18.2.1. Sequence within an iteration
        2. 18.2.2. Making assignments
      3. 18.3. Completing a feature
        1. 18.3.1. What the work looks like
        2. 18.3.2. Other considerations for development iterations
      4. 18.4. Key points
      5. 18.5. Looking forward
    3. 19. Testing: did you do it right?
      1. 19.1. Unit testing
      2. 19.2. Integration testing
      3. 19.3. Functional testing
      4. 19.4. Exploratory testing
      5. 19.5. Test automation
      6. 19.6. Key points
      7. 19.7. Looking forward
  13. VII. Embracing change
    1. 20. Adapting: reacting positively to change
      1. 20.1. Common reasons for adapting
        1. 20.1.1. Feature is larger than expected
        2. 20.1.2. Customer refinement of requirements
        3. 20.1.3. The business need changes
        4. 20.1.4. A technical constraint is discovered
        5. 20.1.5. A team member is unavailable
        6. 20.1.6. A third party doesn't deliver
        7. 20.1.7. Team throughput is lower than expected
      2. 20.2. Adapting during an iteration
      3. 20.3. Three ways Acme Media adapted during its first iteration
        1. 20.3.1. A change in feature scope
        2. 20.3.2. An issue with performance
        3. 20.3.3. Underestimating the registration need
      4. 20.4. Adapting at the end of an iteration
        1. 20.4.1. Demonstrating and gathering feedback
        2. 20.4.2. Re-evaluating priorities: what are your options?
        3. 20.4.3. Reviewing team performance and velocity
        4. 20.4.4. Re-planning and reacting
      5. 20.5. How Acme Media adapts during adapt week
        1. 20.5.1. Reviewing the work completed
        2. 20.5.2. Demonstrating the work
        3. 20.5.3. Personality types and demonstrations
        4. 20.5.4. Demonstrating incomplete features
      6. 20.6. User Acceptance Testing
        1. 20.6.1. Acme Media's UAT approach
        2. 20.6.2. Output from Acme Media's UAT
      7. 20.7. Changes in the business climate
      8. 20.8. Reviewing the findings and revising the plan for the next iteration
        1. 20.8.1. Evaluating team velocity
        2. 20.8.2. New work identified during the iteration
        3. 20.8.3. Features originally slated for iteration 2
      9. 20.9. Key points
      10. 20.10. Looking forward
    2. 21. Delivery: bringing it all together
      1. 21.1. When to release
        1. 21.1.1. To support a constraint
        2. 21.1.2. To meet a predetermined schedule
        3. 21.1.3. When there is enough value
        4. 21.1.4. To test the product
      2. 21.2. Final testing
        1. 21.2.1. What about quality level?
        2. 21.2.2. Completing functional/usability testing
        3. 21.2.3. Completing the user acceptance process
        4. 21.2.4. Validation of nonfunctional requirements
      3. 21.3. Preparing support groups and processes
        1. 21.3.1. The running maintenance and support worksheet
        2. 21.3.2. Finalizing help materials and support processes
        3. 21.3.3. Enabling system monitoring, and creating an escalation process
        4. 21.3.4. Enabling maintenance and background processes
      4. 21.4. Communication and training
      5. 21.5. Ready to release
        1. 21.5.1. Deciding to go live
        2. 21.5.2. Planning the deployment steps
        3. 21.5.3. Deployment considerations
        4. 21.5.4. Creating a deployment and backout plan
        5. 21.5.5. Reducing risk with a pilot
      6. 21.6. Enough planning; let's deploy
        1. 21.6.1. Celebrate!
      7. 21.7. Key points
      8. 21.8. Looking forward
    3. 22. The retrospective: working together to improve
      1. 22.1. Setting expectations for the retrospective
      2. 22.2. Time to digest: a survey in advance
      3. 22.3. Conducting the retrospective meeting
      4. 22.4. What to expect during the meeting
      5. 22.5. Converting the feedback into action
      6. 22.6. Key points
      7. 22.7. Looking forward
  14. VIII. Moving forward
    1. 23. Extending the new process across your company
      1. 23.1. Common findings after a pilot
        1. 23.1.1. Slower than the old process
        2. 23.1.2. Confusion about the process
        3. 23.1.3. Team polarization
        4. 23.1.4. Starting to feel agile
      2. 23.2. What the Acme Media team learned from their pilot
        1. 23.2.1. Embracing change to deliver customer value
        2. 23.2.2. Customer involvement and feedback
        3. 23.2.3. Planning and delivering software frequently
        4. 23.2.4. Technical excellence
        5. 23.2.5. Human-centric practices
      3. 23.3. Next steps
        1. 23.3.1. Spanning the chasm
        2. 23.3.2. Using the SAMI
        3. 23.3.3. Agile practices
      4. 23.4. Key points
      5. 23.5. Conclusion
  15. A. Readiness assessment tables by practice
  16. B. Agile concepts from a phase perspective
    1. B.1. Overview of the phases
    2. B.2. Feasibility: define and validate your vision
    3. B.3. Planning: speculate and create a living plan
    4. B.4. Development: exploration with a schedule
    5. B.5. Adapt: react to new information
    6. B.6. Deployment: deliver, train, revisit, and close the project
  17. C. Agile process overview in text
    1. C.1. Feasibility phase
    2. C.2. Planning phase
    3. C.3. Development phase
    4. C.4. Delivery phase
  18. D. Example: determining process and document needs for a project
  19. E. Quantitative feedback on the SAMI
  20. Resources

Product information

  • Title: Becoming Agile
  • Author(s): Greg Smith, Ahmed Sidky
  • Release date: May 2009
  • Publisher(s): Manning Publications
  • ISBN: 9781933988252