The ‘What’ of Scientific Development
The key is that our hypotheses are not deliverables. They are ideas seeking validation. This twist has important ramifications for how we end and enter sprints.
At the end of a sprint, we can look at what we’ve done and for each hypothesis we can say: “yes” or “no”.
Our planning is about what we will learn, rather than what we will do.
“No” – We Didn’t Fail, the Hypothesis was Wrong
By focusing on what was learned, scientific development tries to make “failing” much safer by changing what it means to fail.
Today, failure is not delivering a solution. It sounds and feels like the team didn’t work hard enough, didn’t estimate accurately, or otherwise failed. This becomes a feedback loop that discourages risk taking and discovery. Ramifications for this feedback are obvious and very likely all around you. Concerns are about planning, estimation accuracy, faster execution, and more specialization.
With scientific development, ending a sprint where a hypothesis results in a “no” is merely disproving the hypothesis. The hypothesis was wrong. Our technique was likely fine. Our work ethic was fine. Our idea was the thing that was wrong.
In fact, in many ways this is a highly desirable outcome. For every “no”, we should have an in depth review of how we arrived at the hypothesis, how we tested it, and our results (code and all). This review will offer innumerable learning opportunities for those exploring the hypothesis while building the coaching skills of the team.
Despite that, when we arrive at a “no”, we should use our learning to create a new hypothesis, which we can test in a subsequent sprint.
The only outcome that does reflect poorly on the team’s performance, is when they don’t know the answer at the end of the sprint.
“Yes” – Doing to Learn > Learning to Do
With all this talk of proving a hypothesis and repeated hypothesis refining, you may be concerned that the team will spend all of it’s time thinking rather than doing.
Those are fair concerns and can happen. They can also happen when writing stories or even in a classic waterfall project.
Ultimately, it becomes a matter of facilitation. Proving a hypothesis is not a matter of citing a question on Stack Overflow and saying “yup, I saw it on there”. Proving a hypothesis means providing a working solution that definitively proves the hypothesis in the proper environment.
If it’s starting to look as though proving your “yes” or “no” can involve a great deal of work, then good. It can. That’s the point. Scientific development is not about doing less, it’s about optimizing the people rather than the work they’re doing.
Planning – A Different Conversation
Sprint planning would also take a subtle, yet important shift.
Most sprint planning looks at what needs to be done and ask who is best suited to do it.
When we’re looking at which hypotheses we want to test, the question is less about “who wants to get this done?”, and is more like “who wants to learn this?”.
That is a small, yet critical shift. The very nature of sprint planning could be pivoted from being a conversation about what we will do and turn it into a forum for helping people develop the skills they want to acquire. It could be the first step in unifying the act of work planning and team member growth.
Of course, the convention alone won’t be enough to completely unify these things, but that is not the point. It’s a tool to assist you in becoming professional learners and experimenters rather than coders.
It also takes learning and growth out of one-on-one and annual reviews and makes it part of the sprint process.
Because planning is a team activity, this also means that everyone on the team will know what each other are learning and how each other are growing. This makes it possible for the entire team to support each others’ professional growth, rather than leaving that to leaders.
In some ways, the team can’t help from doing that. If the team deeply reviews and offers feedback on all “no” results, then there is no escaping team members being perhaps the greatest asset to each others’ continued learning and development.
Read On
The ‘Why’ of Scientific Development