Skip to content

Elevate your tech career, reclaim your life.
Home / Content / The Show / Scrum Is The “Motor” Of Your Project, But Who’s Steering?

Scrum Is The “Motor” Of Your Project, But Who’s Steering?

Scrum Is The Motor Of Your Agile Software Project

When talking about the differences between scrum (or kanban) and agile development, the motor and steering wheel of a car can be a useful analogy.

Watch or listen to this episode

YOUTUBE

SPOTIFY

APPLE

When talking about the differences between scrum (or kanban) and agile development, the motor and steering wheel of a car can be a useful analogy.

When your team is working to write requirements, write code, test, and deploy releases of your software – they probably follow a development process like scrum or kanban to get work done.

This work can be thought of as the motor of the car that propels the software product forward, changing or adding new features to it.

However software companies sell products in a changing market – competitors can force us to change, customers can force us to change, and our own team members can discover information that forces us to change.

This is when the leadership of a software team especially need to trust their other team members to make changes.

Each time the team makes one of these changes to respond to unplanned events, they are being agile.

Being agile in software development is like using the steering wheel of the car.

When things change, the direction of the features needs to be turned so the “power” of the engine is focused on something different.

In software development, we steer the car by putting new product backlog items (or kanban tickets) at a high priority to make satisfying our customer paramount.

Customers won’t buy a software product when we’ve built everything WE think they want – but only what THEY accept.

In this episode, I share some thoughts around this analogy and how you might use it to ask this question next time you’re making a software development process decision:

Is this practice going to help, or hurt our team’s ability to ‘steer’ the car that is our software product’s queue of work to be done?

Resources

Know When To STOP Learning And Just Write The Code!
We Designed A Software Product That Never Got Built

About the THRIVING TECHNOLOGIST show

On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.

Subscribe Now
YOUR HOST

Jayme Edwards

A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.

Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.