Agile Development - Mitch Lacey & Associates, Inc.

Should each project have a sprint (or two) dedicated to fixing defects? How about a stabilization phase? After all, we need to reach the mythical code complete phase, right?

Defect management is one of the easiest things to forego on any agile project. After all, we have been conditioned to address our defects at the end of our projects. Failing to deal with these defects on an ongoing basis, though, results only in low-quality software and the need to “build quality into the system” during a defect-fixing phase or sprint.

So how should a team manage its defects? There are several techniques out there, but I have found one that I have successfully applied to a large majority of my projects. Before we take a look at it, let’s start with the story that led to this pattern.

Read the PDF and provide feedback!

Why This Book

The book What to Expect the First Year saved our marriage when our first child was born. In moments we felt we were going insane, that book helped us to realize that we were going through a normal process that parents have gone through for generations. We took comfort in the knowledge that the changes and feelings we were experiencing were not new to the world, just new to us. The book gave us a glimpse of the milestones and obstacles waiting around the next corner and anticipated our questions with enough clarity and examples to allow us to address our baby’s needs.

My first Agile project felt a bit like my first year as a father. Most of the time, I was lost and unsure about where to turn. What I needed was a What to Expect when You’re Adopting Agile book!

Since no such book existed at the time, my team and I muddled through as best we could. As the project champion, I built a team that was open to experimenting and evolving to Agile. We were determined to become better, and better we became. We read a new book every other week, and experimented with the concepts and ideas in that book. It was not easy; we made as many bad decisions as we made good ones. It took a lot of discipline and patience to work through our issues and team dysfunctions, but we did it.
We constantly asked ourselves, “Should we be progressing the way we are? What are we missing and what can we improve?”  What was missing was a book that was only one step ahead of where we were as a team.

These days, when coaching teams that are evolving to Agile, I always ask how their adoption is progressing. They inevitably reply with a long list of problems they are having. Without fail, their list mirrors the list of problems I encountered on my first Agile project. New teams struggle with building a release plan, identifying and prioritizing requirements and creating potentially releasable software within an iteration.

This book targets the crucial first year and puts it into perspective. Just like the parents who need reassurance that what they are experiencing is normal, this book will help reassure new agile adopters that what they are experiencing may be new to them, but is common to teams the world over. This book provides real-world stories, examples and exercises that an executive, manager or team member can use to survive the experience of evolving their organization to Agile principles & practices.

Table of Contents with links to downloadable draft chapters

Foundational

1. What is “Agile”?
2. Agile Philosophy? I thought I was building software.
3. How can I modify Agile to fit my unique business?
4. When is Agile right for me?
5. Is it always going to be this hard?
6. Am I going to see performance right out of the gate

Teaming

1. How in the world can we possibly deliver a working piece of software in a month, or less?
2. I don’t like what I’m finding in this; can we quit and go back to waterfall?
3. We are a new team and all we do is nag, nag, nag. Will this ever end?
4. What is the teams (was my) role in working with the Product Owner?
5. People keep showing up late to the daily standup, what do we do?
6. I arrive to work at 7 a.m. and the team shows up at 11 a.m., what can we do to get on the same page?
7. Am I the one driving the project? (or who is driving the project)
8. We are afraid to say “no to more work” when the addition will cause us to work beyond a sustainable pace.
9. Should I gather all stories up front or just what is needed by the team?
10. How do I communicate what the team has committed to for a Sprint or iteration?
11. We do not have a collocated team space, what do we do?

Mechanics

1. How do I manage documentation in Agile projects?
2. We are going to use Scrum; who should be the ScrumMaster?
3. What is velocity and why do I care?
4. How long should an iteration (or Sprint) be?
5. We’ve not completed anything this iteration (or Sprint) should we extend it?
6. What happens if the Product Owner stops maintaining the Product Backlog?
7. Is it OK for the architect, or development leads, to build the iteration backlogs? (how does the sprint/iteration backlog get built)
8. Do I have to do release planning in Agile?
9. What is sustainable pace?
10. Our meetings last forever because we can’t decide; what are some techniques to come to a decision quickly?
11. Adding the Fourth Question to the Daily Standup
12. Running a Productive Daily Standup Meeting
    
13. How do we know we are getting value?
14. When does the team estimate the Product Backlog?
15. What do we do if we have stories that are not estimated in the iteration planning meeting?
16. How do we plan for sustained engineering problems (live service outages) in our backlogs?
17. What do we do if we need to carry task items and stories over from the previous iteration?
18. Our customer is not as involved as we would like, what do we do?

Engineering

1. What is collective ownership?
2. I like requirements. What is all this story stuff?
3. How do we know when we are done?
4. I’m a developer, I don’t write tests. That work is for testers. I write code.
5. What role does the customer play?
6. Tracer bullets? Are we at war?
7. What are some considerations to think about when we start pairing?
8. What do we do with new work discovered during the iteration?
9. Do we need to automate our tests?
10. What is TDD and why do I care?
11. What is continuous integration? How do I do it?
12. How do I start coding if I don’t have a design?
13. How do we manage defects in an Agile project?