Scrumcrazy_header5.jpg
scrumcrazybtn.jpg

For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.



Caveat: I suggest some techniques to execute Scrum below. Those techniques may or may not work well for your team. But, hey, isn't that what Scrum is about? Try it, inspect, and adapt!

The following are some common reasons I hear people give when they think they need to use Kanban(by itself, i.e. Kanban without Scrum) to do software development at the team level. I've given my answers to some of those reasons. Be sure to also see my article on places/contexts where I think Kanban fits well.

Continuous Delivery/Single Piece Flow

"We can't do Scrum... because we do continuous delivery, or single piece flow. We release software features as soon as they are done." My answer is that Scrum allows continuous delivery and single piece flow. Scrum allows the definition of done to apply to a single feature (Product Backlog Item) if you want it to. Scrum does not prescribe nor prohibit numerous releases per sprint. Scrum simply requires that at some point in your sprint, you have a releasable increment of the software that has at least one small feature that has value. You can always go beyond that and still benefit from Scrum Practices.

Work Priorities Change Too Fast

"We can't do Scrum... because our work priorities are constantly changing and event driven rather than planned, and Scrum doesn't allow scope changes mid Sprint." My answer is that Scrum has always allowed mid Sprint scope changes, and there is even specific language in the Scrum Guide to allow for scope changes. The only thing Scrum requires that is remotely related to scope is that the Sprint Goal cannot change. (And that's not even true -- you can cancel a sprint if the current Sprint Goal is no longer relevant). Further, you can define the Sprint Goal to be pretty much anything you want it to be. So, your goal could very broadly defined, such as "Adapt to changing priorities in such a way as to maximize value delivery for the company." (As such, even infrastructure/operations type teams can benefit from Scrum)

We Work on Numerous Products not just One

"We can't do Scrum... because our team works on numerous different software systems/products." My answer is -- so define your "product" as that suite of products that your team works on. The Scrum creators had to pick some simple way of describing Scrum. Describing it under a million different contexts would have made it too difficult to learn and adopt. So, they picked a "product" metaphor and gave you very little guidance on how to define "Product." As such, there is some room to define product in some other way than the most simple way possible. (As such, even infrastructure/operations type teams can benefit from Scrum)

Our Work Cannot Be Planned -- it's more Event Driven

"We can't do Scrum... because our work cannot be planned in advance, and often comes up last minute, so we can't do Sprint Planning." My answer is -- Scrum does not absolutely require that work be planned in any more in advance than about 2 days.. AND allows for changes to planned work(see "work priorities are constantly changing" above) at any time, so long as you define your Sprint Goal broadly enough. Sprint planning only requires that work be planned out, or "decomposed" for the first 2 days of the Sprint. Who doesn't at least have a straw man plan for the next 2 days of their work? After those first couple of days, you can do just in time, adaptive planning as the Sprint progresses. (As such, even infrastructure/operations type teams can benefit from Scrum)

We do Technical Work, so we don't have Stories per se

"We cant do Scrum... because our work is technical back end work and can't be written as User Stories." My answer is -- Scrum does not require the use of the User Stories practice at all. As such, don't feel like you need to use the practice. Your Product Backlog Items simply need a description, estimate, order, and value. In that same vein, your team doesn't have to use the other User Story practices either -- such as story points, velocity, acceptance criteria, the user story template sentence, etc. None of these are required by Scrum.

Estimation is a Waste of our Time in our Context

"We can't do Scrum... because we think estimation is a waste of time in our context." My answer is, the only real estimation required by Scrum is for Product Backlog Items. Even then, Scrum does not dictate an estimation technique. I know teams that either "right size" their PBI's (all roughly the same size) or simply estimate a PBI as "will fit" or "won't fit" in the Sprint. There is a requirement to sum the amount of work remaining daily, but you could do that simply by counting the number of not-yet-done PBI's every day. The estimation bar is very low in Scrum.

We get Awesome Success from using WIP Limits, Cumulative Flow Diagrams, etc

"We can't do Scrum... because we rely heavily on using the Kanban Metrics." My answer is, you can do all those metrics and still do Scrum. See: https://www.scrum.org/resources/blog/kanban-primer-scrum-teams

But But But... We've Been Using Kanban for a Long Time

"We can't do Scrum... because we've used Kanban for a long time and invested a lot of money in doing Kanban. And it works well for our context." My answer is, what empirical data do you have that it works well? Have you measured business value via a framework like EBM to prove which approaches work best in your company? Have you compared the business value metrics of your Waterfall vs. Kanban vs. Scrum teams? Regarding the sunk investment in Kanban -- couldn't we say the same thing about the sunk investment in Waterfall and all of the money the company has invested in Waterfall and PMI type techniques? Look, I'm not here to say that Scrum is always better than Kanban, but I am here to ask some tough questions to see if you're resisting change for the sake of resisting change, and whether you have empirical data to back up your claims about whether Kanban delivers more business value for your company. If your company feels highly confident in it's Kanban practice, then maybe the status quo is exactly what you want -- you know that context better than I do.





coaching(4).jpgForScrumMasters.jpgForProductOwners.jpgForScrumDevelopers.jpgPresentations.jpg