Why I love a good proof of concept
A few years ago I learned to take all the risky stuff and package it up into neat little packages called proof of concepts (POC). It's been (work) life changing. Your team might call this a Spike or whatever else their hearts desire. The goal is the same: reduce uncertainty to minimize risks.
First, imagine a world where we jump straight into our tasks:
long running tasks
tasks spilling across cycles / sprints
defensive estimations
pushback against those estimations
optimistic estimations that the team can't live up to
exhaustion
repeat - with less motivation and reduced confidence
That's not a healthy way to deal with uncertainty, right? No one is satisfied in this situation and there is definitely resentment in the air. So what can we do instead?
We could go all out, like Share Up method does, and make sure risks become the central point of conversation by making them the first tasks to tackle in every single initiative.
But that might be quite a heavy change in your team to change to a different organizational system so instead, why not get into the habit of highlighting uncertainties as they appear and then allocating time to explore those uncertainties in a controlled manner.
When do we need POCs
Let's start with a rough definition:
an experiment
to prove a concept (duh)
in a small amount of time (usually a few days max)
disposable (it's an experiment after all, not the real deal)
Basically, when you have no clue how long you will need to accomplish something or if you are uncertain about the approach, it's time for a POC.
Sentences that scream POC to me:
we need to make a change that will affect every single service we've built
we want to try this cool new framework that promises better developer experience
we need to add a dropzone feature to let people drag n drop files into our app
we hate our tech stack but we don't have enough information to pitch any alternatives
we know it will be a horrible pain to implement X - we could try these two things
we should stitch something together quickly before we agree to work on this
there is this cool new service we want to integrate
Once you've reached the conclusion that a topic is drenched in uncertainty, you need to outline the scope of your proof of concept. What do you aim to prove? How? Within what time frame? What would be considered a success? Do we need to find alternatives if this approach fails or do we stop pursuing this topic?
What POCs can do for you
Writing and then performing these tasks diligently can be a huge asset when it's time for performance reviews. You end up helping the entire team by:
protecting developers from committing to very risky tasks
help bring more predictability to the roadmap
anticipate risks
think about architecture early
document benefits and drawbacks of approaches
I believe if you want to prove that you are senior material, or rise even higher in the ranks, you are setting yourself up for success. After all, what we expect from experienced people is to bring stability to the table, and that's exactly what you can do by managing risks and tension in the team at the same time.
Thinking in Experiments
Having an approach centered around experiments does not come naturally to many people. If you have an academic background, maybe, but for many of us, it feels a lot more natural to say "sure we can, let's give it a shot".
Luckily, we learn very quickly from failure and pain, so it won't be long before you get the strong urge to look for a healthier approach.
What we end up doing, is separating the "what" from the "how". The delivery from the preparation and experimentation. All the "how" task needs to accomplish is to sufficiently define the scope of the "what" tasks. And it gets to do that, without the time pressure of having to deliver on any requirements. It needs to document the results of the experiment.
Keep it practical and lean
It's important to note that these tasks should have tangible results. There should be a pull request or a codesandbox that serves as proof and often as the example for the implementation.
This is different from an RFC (Request for Change) which can include examples, but doesn't have to.
At the same time, you should aim to remove everything irrelevant from the equation whenever possible. For example, if you can answer your question within a code sandbox, implement it there. It will be a much faster and serve as better documentation, than working in the real application.
However, if the uncertainty lies is integrating something into an existing application, you need to figure out how to implement as little as possible, while tackling as much as possible risk.
This may sound daunting, but keep in mind, that you are doing this as a team and you nobody can anticipate all risks. Every bit of uncertainty you handle upfront is a win!