“We have to get it right before we start!” Sounds kind of waterfall-esque, doesn’t it? You’d think that the people saying this might be referring to getting their requirements right up front. But no! What they are referring to are the details of how they will apply agile not what they are going to build.
These are the same folks, by the way, who are completely sold on the fact that getting requirements correct/perfect at the beginning of their project, when they have the least information they will ever have about that project, is not a sensible thing to attempt. I find it more than a little ironic that the same people who will agree that it is not possible to get the requirements for a product correct up front, and therefore want to use agile for development, will in the next breath explain how they aren’t quite ready to start using agile because they haven’t worked out all of the details of their agile approach!
When I’m training and coaching, people often ask me questions that they believe are important to resolve before they begin working in an agile way. My answers are all meant to reassure them that they can—and should—begin applying agile without having all of the answers—they only need to decide enough up front to run the first reasonable experiment to collect data so they can inspect and adapt. Here are some examples of the questions and answers:
- Q. Should we have the development team members assign tasks to people during sprint planning or let team members dynamically select tasks during sprint execution?
- A. The default for many Scrum teams is that team members dynamically pull tasks during sprint execution. But hey, if you’re not sure which approach is better for your team, then in one sprint let team members assign the tasks during sprint planning and in another sprint don’t pre-assign them and let team members dynamically pull them. Why try to guess which approach would be better? Run both experiments and see which one works better for your team!
- Q. What is the complete set of criteria to include in our Definition of Ready to ensure that product backlog items are really ready to be pulled into a sprint so we have a reasonable chance of getting them done?
- A. I don’t know, and neither do you. Why not draw a reasonable line in the sand (make an initial decision which criteria to include and which to exclude) for Sprint One and see how well it works out. You’ll probably get it wrong (e.g., you bring 10 product backlog items into the sprint and you get three of them done). In Sprint Two, adjust the criteria and try it again. See if you are completing more work this sprint. My guess is that within a handful of sprints or less you will converge on a good Definition of Ready.
- Q. Could our ScrumMaster be the ScrumMaster for more than one Scrum team at the same time? What is the proper length for our sprints? How many product backlog items should we have in the ready state to ensure we won’t block the flow of work? Should we estimate tasks or not? Should we produce a particular progress chart (e.g., burndown, burnup, etc.)?
- A. Why don’t you run one or more experiments, each of which is bounded in length to the duration of a sprint, to collect the data that will help you determine what will work best in your environment?
By now you see the pattern! The I-have-to-have-the-perfect-answers-up-front type of thinking is poorly aligned with fundamental agile principles. When employing agile, you shouldn’t worry about getting things perfect up front. You can’t! And trying to be perfect up front will force you to guess at the expense of important learning that you will get only by applying agile and seeing what happens.
Agile is all about inspecting and adapting. So why try to be perfect up front when you can be agile! Whatever you think you know now about your use of agile, imagine how much more you will really know after you start and finish the next iteration!