Most agile software teams have a serious imbalance in technical and managerial agility.

The imbalance begins early, as many teams and organizations believe they will be agile simply by adopting agile management practices like sprints, standup meetings and storypoint estimations.

I liken those three management practices to training wheels.

Training wheels make it possible for your kid to experience the instant gratification of riding a bike without having to learn how to balance on two wheels.

When it’s time to take off one or both of the training wheels, or raise them up so they don’t directly touch the ground, your kid has to confront the challenging task of learning to balance.

This time is often filled with a great deal of fear and desire to return back to the ease of riding with training wheels.

Balance is essential to riding a bike, yet it’s hard to learn after you’ve already been successfully peddling yourself about with training wheels.

Thankfully, there is a better way.

The new way requires first learning to safely balance on a short, moving bike without peddling and only adding peddling into the mix after balance and movement have been mastered.

Watch how my own daughter learned to ride her bike in the space of two days using this approach:

Agility in software development requires learning to balance key technical and managerial risks in your process.

For example, if your software has many defects and they are preventing you from focusing on important new functionality, you likely need to address the risk by learning and practicing test-driven development.

If you find yourself routinely slipping deadlines and missing targets, you likely need to learn how to do evolutionary software design, including the practice of splitting user stories, working on high-risk/high value items first and practicing what I call bargain hunting.

If you find your development slowed to a halt by having lost people who were knowledge silos (i.e. solo members of your team who are the only ones who know some part of your code), you would do well to address the problem via pair- or mob-programming.

If you find that the architecture of your software product is fragile and/or burdensome, make sure that your backlog isn’t controlled by a single, non-technical product owner who has no clue about the disastrous effects of technical debt. (And consider reading my blog, Community, Not Product Owner).

Chances are that slowness in your ability to deliver useful, high-quality software relates to an imbalance in your agile practices and values.

By learning to balance technical and managerial concerns early, you’ll have a far easier ride on your path to software development agility.