FIVE: Losing the Forest for the Trees

The Challenge: In the early stages of a new Agile project, all is good. Your team is working on user stories, test cases, building features, and happily coding along. The vision and plan has (hopefully) been established and everyone’s excited about being outrageously successful. You’ve also comfortably tackled some of the early platform and architecture efforts. Now if you’ve already solved the first four challenges discussed, this challenge – Losing the Forest for the Trees – will be much less of a challenge. But as Agile hums along, the backlog increases, new ideas come into the mix, bugs stack up, and the development team starts getting tired and frustrated. Progress appears to be slowing down since more time is spent on bugs, design changes, and minor enhancements. At this point it seems easier to focus on what can get done over what should or must get done. You may start wedging in small features and incremental tweaks into sprints while bigger, more challenging – and more valuable – problems can’t be addressed since these bigger efforts don’t allow room to fix bugs and finish features. Decisions get tougher and frustrations set in. Your management team may even start thinking that Agile isn’t for you since the plan is not being delivered upon.

The Solution: As one of my client’s executives put it (and I’m sure he borrowed it from somewhere), “You need to keep the main thing, the main thing.” At this point it’s more important than ever to go back to the basics – clarify the vision, listen to real customer input, and focus on what the “main thing” is. What are the features, user stories, use cases, and other attributes that you MUST get right to be successful in the marketplace? As your solution gets close to delivery Agile can’t be a philosophical software development process, but a business process for delivering greater value to customers and competitive offerings to the marketplace. Use your Agile skills to make the tough decisions to cut less important features that aren’t complete, ignore seemingly critical (but not important) bugs and re-energize the team on those product attributes that your customers care about most. These tough decisions obviously can’t wait until the final pre-launch, but must consistently be made through the entire development process. While nothing provides more satisfaction than a complete product that does everything you want it to do, when the schedule conflicts with completeness (and it always will), err on delivering a solid solution that does less. Then, get it into the hands of real customers, learn, iterate and succeed.

Read part 1, 2, 3, 4 or download “The Five Challenges to Agile Planning” whitepaper.