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 important.
Customers won’t buy a software product when we've built everything WE think they want - but only what THEY accept.
In this video, 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 direction of work to be done?"
📺 Watch this video on YouTube
Or listen as a podcast:
🎧 Soundcloud
🔔 Subscribe for 90+ videos on healthy software development
Top comments (4)
I find that Scrum is a lightweight management process. In-and-of itself, it is not agile. But it is (or can be) lightweight. And it definitely can be a win-win, if used in conjunction with agile development. Even in the Scrum guidebook, it intentionally does not prescribe any specific agile engineering practices. Rather Scrum explicitly leaves agile development in the hands of the developers.
Agile development, in contrast, is not as much about the management process. Rather it is about agile engineering practices such as: continuous integration, unit testing, developer centric source control like Git, sustainable pace, test-drive design, aggressive refactoring, SOLID, GRASP, KISS, YAGNI, emergent design, simple design, design patterns, emergent architecture, continuous learning, collective code ownership, coding standards, pair programming, BDD, ATDD, code coverage, continuous deployment, cyclomatic complexity metric, other metrics, domain drive design.
No agile development team will use all of those agile engineering practices. But hopefully they use at least a few.
I’d agree for the most part. In general I was trying to make the point that a team can follow all of those practices but if no one is steering the product in the right direction (either out of laziness or refusing to satisfy the customer) no practice can help you change.
I fully agree. Someone has to be steering the product in the right direction.
Otherwise...
If you don't know where you are going, how do you know when you get there?
👍