Many people talk about “going back to normal.” We aren’t going to return to normal. That old normal is gone, at least for a year, if not longer. (I suspect we will cycle between remote work and office work for the foreseeable future.)
What we can do is discover a new normal.
Discovery requires different skills than delivery. Discovery requires short experiments where we can learn something, maybe every day.
I think about the various risks for discovery and delivery. You might need to manage your delivery risks before you can manage to free time for the discovery risks.
Delivery Focuses on Technical Risks
Delivery focuses on the risks of how to deliver, not what to deliver.
When we focus on delivery, we know what we need to do. We might have technical risks for how we do it. We might need clarification, but the work itself doesn’t change much. (You might like the Balance Innovation, Commitment, & Feedback Loops series.)
In my experience, we assume much more certainty for the requirements and schedule than we should. That leads to people using agile approaches to focus on delivery. They (try to) predict a quarter’s worth of work across the organization. They predict a couple of weeks of work in a team (with varying degrees of success).
If you want predictability for schedule, try these ideas (and more in Predicting the Unpredictable):
- Ask each team to measure its new cycle time now that they are dispersed. I suggested various ideas for how to create a remote environment and measure cycle time in 7 Tool Tips for Your Newly Distributed or Remote Team.
- Managers: please measure your decision cycle time as in Long Decision Wait Times and Unearth Your Project’s Delays. The longer you take to decide anything, the more pressure you put on the team.
- Reduce the team’s WIP to one item and make every deliverable as small as you can. I like one-day deliverables.
Now, you have data about what it takes for a team to deliver. You can use that data to manage your discovery risks.
Discovery Focuses on Requirements (Market/Customer) Risks
I like to create real experiments. We can use the Build-Measure-Learn loop or the experimental loop:
- Write down your hypothesis
- Write down the data that will help you discover if the hypothesis is correct. Create a system to measure that data.
- Decide on how long the experiment should run (timebox)
- Measure the results
- After you gather the results, what does the data tell you?
- Decide: Continue, change, stop the experiment?
You might have hypotheses about your market, your customers, or how your current product(s) can offer value. Write them down.
What if you have 50 experiments to run? Rank them, preferably by value. You can use the same ranking as you would for features in a feature set or for the project portfolio. As a shortcut, ask this question:
How much do we want to invest in this experiment before we move to the next experiment?
Why ask about investment instead of trying for a prediction of cost or time? Because if you’re reinventing your company, you don’t need to predict anything. You don’t have the time to predict what the team might deliver. You can predict how much time or money or number of teams you want to invest.
Now, you can rank.
Who Should Discover?
Normally, I like to ask the teams who deliver the product to also do the discovery. That might not work now. If you have already-promised work, the delivery team might need to do that.
However, if you’re accustomed to using corporate architects or some other way of cascading discovery down to teams, rethink that structure in your quest to discover and create your new normal.
The more people and time before you create and run an experiment, the longer it will take for you to create your new normal. (I have many suggestions in Agile and Lean Program Management for how to organize multiple cooperative and collaborative teams without a ton of bureaucracy.)
Trust the people you hired to work.
How You Might Discover
When I’m in discovery mode, I have these assumptions
- Speed of discovery and delivery matters. That means each team has to limit its WIP. And, finish one small thing every day so everyone can see visible progress.
- We probably don’t need “all” of it, regardless of where we are. (See how little thinking.)
- We need to stop working on what we don’t need sooner, not later. Ask the Zeroth question about everything: Should we do this project at all?
- Be as transparent as you can be, about everything. When managers lead with transparency, the technical people know what to do.
You might find, as I do, that using flow/kanban with WIP limits and a cadence of planning/demos/retros works better for you. I’m a one-person business and I have replanned every single day this week.
You can discover your new normal.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: We Won’t Return to Normal; We Will Discover Normal Opinions expressed by Java Code Geeks contributors are their own. |
