My friend is going through an Agile transition. His backlog (to do list) is mostly converted to small pieces of functionality that the customer will use. There are a few old items from before the transition that are listed as pieces of work for behind-the-scenes. They describe work on individual components that need to interact to create something bigger the customer will see. I was unable to see if his dismay at the problem was warranted or not. I asked him four questions.
What is the risk?
Normally, having component based activities causes the team(s) to work in more of a waterfall way. We need to do X, Y, and Z before we get customer feedback instead of smaller, and therefore faster, pieces. What is the risk? What if the components don’t interface? What if it delays other work? How does a delay in any of these components impact other things? What number can you put on it?
What is the waste?
Now that we’re implementing something that will take a while to get feedback about, what happens if the customer doesn’t like it? What is the waste? What is the probability that you are doing the wrong thing? How can you tell? What is the failure rate of similar features? What number can you put on this?
Note: I have stopped at this stage before. The numbers were too small to fuss about.
How can you get others to see this?
Assuming the previous questions show you that you have a big problem, how can you share it? How can you get others to see this? It will be a good check on your numbers. How do you avoid being talked out of your figures and still show a truth?
What experiment can you try?
Now that you have numbers, you have probably made many assumptions. How can you evaluate the assumptions. What experiment can you try? What if you could get part of the solution in front of the customer early? Can you validate the interfaces? Can you create dummy components to allow early testing?
Just four questions to check your gut reaction, no answers.
