38 min
Scrum vs Kanban - How Do They Help You Be More LEAN In 2017? Healthy Software Developer
-
- Technology
Embarking on the journey to let customers lead YOU to the most profitable solutions?
You’ll probably need to decide between the two most popular ways agile teams work, and I’m here to help you make that decision.
Scrum is a great process when your team needs a scheduled checkpoint for how well they are doing. It is also great when the customer can only respond to change every couple of weeks.
Kanban is superior when trying to use your resources to their fullest capacity. It’s also superior when your team needs to adapt to change without time wasted waiting on each other.
My vote: Kanban! BOTH processes can be used in a lean fashion, but I just find Kanban supports adapting to uncertainty more fluidly.
Kanban also lets team members work at their own pace, and do the work they enjoy most – not forcing people to attempt to work at the same speed and rely heavily on estimates being so accurate.
Caveat: If you’re going to use Kanban, schedule a regular checkpoint to continuously improve processes by having a retrospective.
REGARDLESS of which process you use, the same rigor you’d use on a waterfall project must be followed before any kind of estimate should be communicated.
Requirements (or user stories), ACCEPTANCE CRITERIA, infrastructure changes, user interface assets, technical documentation, support & monitoring needs – figure it all out first!
If this seems like a lot to figure out for one story – it is! That’s why stories must be small…
A team that is learning to truly “continuously deliver” value to their customer in small batches must reduce the business’ expectation of the RATE of product change.
There will be less released at once, but what is released will be HIGH QUALITY and ready to go to production immediately!
So how does a team prevent changes that aren’t ready for production from going out with those that are?
Feature Branching! *BZZZT* JUST KIDDING! Use /Feature Hiding/…
Use configuration settings to hide work underway so it doesn’t block releases to production.
When a feature is ready to go, just switch the configuration change on the next release!
This forces everyone to continuously integrate changes into the trunk (or “master” branch) which is a key principle of *cough* continuous integration (yes, the name means what it says).
You can also watch this episode on YouTube.
Related resources:
Continuous Delivery (Amazon) Introduction to Scrum - 7 Minutes Kanban 101 - What is Kanban? Lean Software Development - It's About Uncertainty! Software Estimation - Trading Perceived Effort for Outcomes Minimum Viable Product - Letting Software Customers Help You Profit
Visit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
Embarking on the journey to let customers lead YOU to the most profitable solutions?
You’ll probably need to decide between the two most popular ways agile teams work, and I’m here to help you make that decision.
Scrum is a great process when your team needs a scheduled checkpoint for how well they are doing. It is also great when the customer can only respond to change every couple of weeks.
Kanban is superior when trying to use your resources to their fullest capacity. It’s also superior when your team needs to adapt to change without time wasted waiting on each other.
My vote: Kanban! BOTH processes can be used in a lean fashion, but I just find Kanban supports adapting to uncertainty more fluidly.
Kanban also lets team members work at their own pace, and do the work they enjoy most – not forcing people to attempt to work at the same speed and rely heavily on estimates being so accurate.
Caveat: If you’re going to use Kanban, schedule a regular checkpoint to continuously improve processes by having a retrospective.
REGARDLESS of which process you use, the same rigor you’d use on a waterfall project must be followed before any kind of estimate should be communicated.
Requirements (or user stories), ACCEPTANCE CRITERIA, infrastructure changes, user interface assets, technical documentation, support & monitoring needs – figure it all out first!
If this seems like a lot to figure out for one story – it is! That’s why stories must be small…
A team that is learning to truly “continuously deliver” value to their customer in small batches must reduce the business’ expectation of the RATE of product change.
There will be less released at once, but what is released will be HIGH QUALITY and ready to go to production immediately!
So how does a team prevent changes that aren’t ready for production from going out with those that are?
Feature Branching! *BZZZT* JUST KIDDING! Use /Feature Hiding/…
Use configuration settings to hide work underway so it doesn’t block releases to production.
When a feature is ready to go, just switch the configuration change on the next release!
This forces everyone to continuously integrate changes into the trunk (or “master” branch) which is a key principle of *cough* continuous integration (yes, the name means what it says).
You can also watch this episode on YouTube.
Related resources:
Continuous Delivery (Amazon) Introduction to Scrum - 7 Minutes Kanban 101 - What is Kanban? Lean Software Development - It's About Uncertainty! Software Estimation - Trading Perceived Effort for Outcomes Minimum Viable Product - Letting Software Customers Help You Profit
Visit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
38 min