Scientific development is designed to mirror the unpredictability of the scientific method. Most organizations will have a hard time tolerating that. Others, like those in the pharmaceutical industry, may be able to embrace these ideas without difficulty.
The primary barrier to using this technique will be from your organization. If teams have great autonomy, are self sufficient (don’t need others to get their work done), and aren’t driven by near term ROI decisions, then this technique is a natural fit. That probably is not your team, nor any other within your organization.
However, you could still include a few hypotheses even if you work closely with many teams, must follow explicit standards, and have a scrutinized budget.
But we’re a small shop and need to meet client deadlines to get by
There’s a time to just get things done, but be mindful of that mode not becoming your only way of being. Perhaps you can try this technique, but on internal projects. Perhaps, you may even apply this to maintenance work as a way of critically reviewing how best to improve your products and services rather than just keeping them running or patching up bugs.
But we’re in a large enterprise and need to work with others on large projects
Be prudent. Be a good member of the extended team and do what is necessary to play nicely. However, that shouldn’t preclude the use of some hypotheses to ensure the team is growing and pushing themselves. Perhaps, there are even hypotheses related to your current project work whose answers may alter your trajectory.
We understand our work; we do it all the time. Why bother with a hypothesis?
That sure sounds like a good argument. It may even make you think that writing hypotheses would be a waste of that team’s time. Nothing could be further from the truth.
If the team feels that writing a hypothesis is a waste of time because they know the answer, then they’re wasting their own time. Doing the same thing they’ve done before won’t result in learning. For a team of skilled people, there is no greater waste than to spend weeks, or months, or years of their life keeping busy and not really learning. In this way, taking the time to write a hypothesis may feel like wasted minutes, but it might just spare them years of wasted opportunities.
What if they were forced to create a hypothesis? What would they start asking that would be testable, they do not know the answer to, and will be a growth opportunity? Maybe something like:
Can we put ourselves in a position to do unique value added work
By creating a utility that will allow our clients to do for themselves what we have traditionally done for them?
Can they? I don’t know. But they’re sure to learn a lot for the effort.
So, everyone should do this?
This technique (like any agile practice) is a tool that can offer certain advantages or help solve certain problems. If you don’t have those problems or don’t want those advantages, then look elsewhere.
Should my my team consider this?
Do you want a team that is collectively supporting each others’ growth? Do you want team members to see how what they’re doing today is building skills and knowledge for tomorrow?
If those sound like things you want, maybe it’s time to run an experiment.
Are there symptoms that should encourage me to try this?
Do you have tools for tracking team member growth that are independent of the work being done? Do people feel as though work is interfering with their growth & learning rather than work being the engine of growth & learning? Do people look back over the year and see all the stuff they did but are unsure if they’ve really grown or developed at all?
If those sound familiar, maybe it’s time to run an experiment. Try to formulate a hypothesis and put it to the test. You may just learn something.