Friday, February 27, 2015

How to Handle Unknown in Agile

"Unknown unknown" is inherent in today’s business dynamic, if it weren't, what you are doing would not be agile.
There are known known, known unknown, unknown unknown, either running an Agile project or managing a business as a whole, the philosophy is the same: to implement business strategy and goals by managing risk effectively. Tactically, it is important to understand what it is that you don’t yet understand. In Agile practice, have you tried to quantify your uncertainty or unknowns? If so how did you do it?

Put some focus on quantifying the unknowns in a story. Uncertainty is an obvious driver in how long it takes to complete a story. Finding a good way to identify uncertainty and quantify it to the team is more of a challenge. One way is to estimate in story points and round up... The larger a task is, the more unknowns there will be and the more likely your estimates are short. To get around with the uncertainty because of not understanding the requirements well, you are attempting “User Story Mapping” with lot of pictures and diagrams. The story mapping is very important for creating a shared understanding among the team members to reduce this uncertainty. Where the rubber hits the road is with story pointing. More often, you will find yourselves to be horribly inaccurate when pointing stories with an unknown amount of uncertainty.

Up-front Analysis: Such analytics helps out a lot of what you started off not knowing. It was dependent on up-front requirements. It was expensive, though at the time you didn't know how cheap the overall cost of the alternative was. And no matter how much analysis you did up-front, there were still things that you didn't discover until later; still new requirements uncovered, and what was probably worse, about a quarter of the stuff you gathered requirements for, expended effort analyzing, and if they are not carefully designed and built, rarely if ever got used. Diagnose the cause of the uncertainty to see whether it is because of not understanding the requirements well or because of the unknowns around the technical implementation. For the unknowns around the technical implementation, you can perform small spikes to evaluate different approaches. Unknowns are also reduced by an engaged team in planning: The more people on your team participating, the more things they will spot or call out.

Each degree of freedom is an unknown: The more you build in, the bigger the scope which is beyond estimability, so the only sensible strategy is to not permit more than a few per story before breaking up the story or digging into spikes prior to implementation. Well-sliced stories limit the degrees of freedom, either you'll be up for known unknowns or you purposefully hit on an "unknown unknown". In the first cases, you can minimize the information gap through exploratory design techniques; certain "known unknowns" can be addressed through a simple spike story. Things like, How does this new interface work? or which of these two methods works better? In the second case, you must spike to turn the unknown unknown into a set of known unknowns, which you can then handle adequately. In the "unknown unknowns" where a user story simply explodes. In these cases, late story decomposition is practical, also identify a value slice that the team can reasonably complete and call that a story. The remaining work can be deferred as a spike and a separate user story.

The focus of quantifying the unknown should be focused on communication and collaboration. There is always a risk of delving in "HOW" when you try to slice it too thin or user story mapping or name any other technique to reduce the risk of unknown. There is also a problem of quantifying an estimate of a story with story points where in it becomes the single parameter driving your whole planning conversation. On that thought quantifying the unknown also will just add to the whole problem. The more "loose ends" the team permits within a story, the higher the risk of encountering an unknown Unknown somewhere down the road. Hence, if you only tend to quantify the uncertainty, guesstimates and story points to get a dummy feeling of being in control. These numbers and the discussions around the numbers, gets the team off track. If the focus is kept on collaborating, learning fast, communicating and course correcting, the team becomes much more productive.

"Unknown unknown" is inherent in today’s business dynamic, if it weren't, what you are doing would not be agile. That doesn't mean you can't learn from the unexpected things that did arise; you may get an ever-improving list of things to keep an eye out for next time. There’s no easier way to quantify the degree of unknown, businesses just have to experiment, learn, practice, practice and practice.


Post a Comment