The Art of Shifting Gears: What to do when team’s velocity slackens?

on
As you cycle your way uphill, we watch our pedal cadence and keep a certain rpm. We keep shifting gears in order to maintain this. Shifting gears prevents us from coming to a grinding halt.
In the same way, maintaining a team’s momentum is also about timing your gear shifts correctly. A great team knows how to keep the beat of software going. But occasionally, every team has moments where they slip. This is natural. The question is, when they do slip, how do they get back up on track and execute. As a Technical Program Manager your role is to proactively prevent slips from occurring.
In this article, I share strategies for Program Managers, Engineering Managers, and Software Engineers to ease the tension on the chain that holds the team together and switch gears with ease. I conclude with eight troubleshooting tips to help teams stay vigilant.

In every aspect of life there is a technique

A cyclist facing an uphill gradient faces difficulty keeping pedal rpms as the drag force increases. We know the cyclist needs more power. So you change gears! The gear train is capable of switching the power, altering the torque and speed. In every aspect of life there is a technique for accommodating the change, from music to rocket technology to human psychology.
A narrow gauge steam engine going up a winding grade to the summit of Bear Mountain

How to shift teams’ gears?

The key thing for shifting a road bike is that you have to simultaneously turn the pedals with your feet and move the shift lever in order to change gears.
As a program manager, you and your team need to be very vigilant to achieve the goals your team has set. All actions need to be focused on the goal. This is “Cooperative endeavour-ship.” Dedication is critical and everyone must commit to this. True unfoldment can only happen in such teams. Everybody must give their best. If the team starts taking action only for the purpose of selfish personal goals, bit by bit, drag will set in.
“Obstacles are those frightful things you see when you take your eyes off your goal.” — Henry Ford

Framing Goals and OKRs

As the team goes about setting the goals, ensure that the goals are big. When framing quarterly goals, frame them with exit criteria in mind. Goals should be properly aligned and tie in with your organisation P0s (Top priority for organisation) and anything not connected with those goals are not P0s. If you need to work with other teams, ensure that you understand the other team’s motivation and how it ties in to the larger goals. Have teams outside of your core team include it in their OKRs, share dates, and make them part of your launch.
  • Keep repeating those goals during presentations.
  • Every quarter setup OKRs knowing trends.
  • Reschedule work according to how well you know your team’s capabilities.

Institute code milestones not document completion milestones

See my article, I am 99% done: On defining done and instituting code milestones — and know why they are critical to your engineering teams’ success & velocity.
At times the OKRs you set can require collaboration from other product areas or orgs.

Organization Alignment is Key

Teams often invest time in massive efforts but soon loose it’s momentum. The project can be perceived as having strong management support but, the reality in terms of priorities and head-count, they don’t want to invest in it. So, it is important to get buy-in.
  • Ensure Organisational alignment
  • Ensure there are Dedicated people for shared OKRs
  • Get buy-in from Adjacent Teams

Institute Vision Workshops

When looking at setting annual roadmaps, I normally conduct a day long vision workshop for teams before the annual roadmap session approaches. The goal is to identify all the opportunities and narrow down 1–3 key ideas to develop and add them to the annual roadmap.
The key highlights of this 1-day workshop are:
  • Teams initially share “how might we ” data with your team. How Might We (HMW) questions, part of design thinking exercise, are a proven way to open up brainstorm sessions. This data sharing activity is to discover opportunities, ideas, features, and constraints. Presentations around key areas are made and HMWs are recorded.
  • Prioritise the HMW items and vote for the top 5
  • Generate Q&A for these possibilities. Brainstorm while encouraging the wildest of ideas without being judgemental.
  • Finally prioritise the ideas with votes. Break up the teams into small groups to develop these ideas in depth, and have each team make a final presentation on an idea.
  • Include these ideas in your roadmap.

Create Group Understanding with Shared Goals

As organisations grow larger, team members at times are unable to relate what they are working on to the P0 goals of the organisation.
Every team member needs to know why they are building what they are building.
One easy way to create a shared goal and group understanding is to have periodic “program charter meetings”. These meetings facilitate group cohesion. These meetings are a great way to get the integration items on the table sooner and get all affected components on the same page. A product manager also participates to set the customer goals. The Tech Lead and engineers divide up user stories, discuss them, and identify external dependencies. Here is an expected outcome:
  • Restatement of the purpose: shared goal
  • Agreement on success metrics
  • Walkthrough of new UI/Features (share doc ahead of time)
  • Identify dependencies by asking teams to identify stories related to the proposed UI and features.
  • Bubble risk items associated with the stories.
  • Develop clear completion criteria for the stories.
  • Sign off of new interface and features with dependent teams
  • Look for potential early­ integration checkpoints, ways to improve redundancy from the beginning, the creation of appropriate testbeds, and the setup for load testing.
  • Discuss a rough timeline for the integration and launch.
  • Identify Q&A deliverables and a test plan.

Eight Troubleshooting Tips to Stay Vigilant

Thus far, we have focused on long term goal setting and getting organisation alignment. How do we handle the day-to-day fires when velocity slackens?

Tip 1: Run a short retrospective

Run a short retrospective to get insight into why you lost momentum. The focus should be to see if the team has improved in its ability to work as a team. Understand the energy flow all the way up to launch and identify some recent activity where you saw a momentum drop. Watch out for the high tempo events, and an analysis of the lows will indicate the reasons for the loss in momentum.

Tip 2: Leading and Lagging Indicator Dashboards

Ensure that high priority items are set up for success. Have visible leading and lagging indicators to detect momentum drops or gains in your team. In your communication artefacts have a dashboard that shows the progress of your backlog, your P0-P1-P2-P3. Focus on how you prioritise them, and give teams the needed clarity to execute the backlog.

Tip 3: Identify Muda

While defining doneness for your efforts or demonstrating what is in code at the end of an iteration, don’t stop at checked-in CLs but ensure running in production is also accounted for. If you can break up a large changelist into smaller changelists, it can speed up approvals. If your team has a huge number of pending changelist reviews, it is a sign of “muda” (waste). Improve the CL flow in your team by spreading the load of CL reviews, and don’t have too many reviewers for the same changelist, or else it can cause confusion.

Tip 4: Organise Team Events

  • Get rid of technical debts that can slow down a team by organising special ½ to 1 day long fix-it type events with specific goals. Developers enjoy these refactoring, fixes, and the production of a high quality product. Ask product managers to walkthrough a few important user journeys to be tested as a part of the fixit or bug-out days.
  • Off-sites are a great way to bring a team together, but articulate the expected outcome of the event so that everyone understands it beforehand.

Tip 5: Include Slack if your team is too stretched

Just as in cycling, adjust the tension in your chain, include slack in your team schedule. Many might have heard of 20% time. It is all about keeping your team’s capacity at 80% rather than at 100% and avoiding high-queue states.

Tip 6: Provide Early Design Feedback

To build a quality product, the team would like access to customer feedback early. They need feedback on designs. Schedule a design session with most folks as soon as possible — don’t delay this step, and don’t wait too long. Have a “formal” presentation with the entire team so that everyone is on the same page. Also, ensure product managers are present in your iteration planning meetings to provide early design feedback.

Tip 6: Never hurts to Repeat & Over Communicate

  • Some things just need to be told again and again. Focused precise goals for sprints that will be repeated during all duration of iteration.
  • Challenge the team to think in terms of Step functions that they could work on to improve on outcome.

Tip 7: Focus on the one thing

Could it be the team’s belief in the goals have weakened over time? Many teams have shared in retrospectives that they made great progress because of the ability to “focus on one thing”. During an iteration planning meeting, try to get an agreement on the one primary goal, so that all hands on deck are ready to make it happen.

Tip 8: Escalate only when necessary

Teams like to avoid late deliverables. To address this, the team should escalate such matters through channels outside of the weekly meeting in written form and management chains — from staffing all the way to technical decisions needing clarity. But, balance it as you build bridges with adjacent teams.

Be ever vigilant…

To summarise, make changes to make people’s jobs more interesting. Continuously steer them towards the goal. Dedication to these goals is the epitome of great teams. Shifting gears takes a bit of practice. But, over the course of time you will get used to watching the cadence and ensure to keep a certain number of rpms and keep shifting gears.
Windmills in Netherlands adapt to changing wind directions

Acknowledgements

I thank Eric J. Dee for his copy edits and feedback.


***

Comments

Post a Comment