Working towards Sustainable Pace in Scrum, SAFe and Kanban
Aiming towards Sustainable Pace “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” – The
Home » Scrum with Kanban
Aiming towards Sustainable Pace “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” – The
Here’s a frequently asked question in the SAFe community: I wanted to understand what SAFe says about someone who wants to go faster than 2 weeks of iteration? I mean the whole PI concept is based on 5 iterations worth of planning. What if a team/organization wants to develop and synchronize faster than 2 weeks? Is speed going to be compromised by following the standards of PI cadence?
Here’s my take:
Adjusting Cadence Length in SAFe – Can you? Should you?
Everybody wants to Scale Scrum So you have a couple of Scrum Teams that are working in adjacent areas and you’re starting to face some
Leverage Kanban and DevOps to improve Scrum
Should you use Scrum, Kanban, or DevOps? You don’t have to choose: Scrum teams improve when they look at flows inside and outside their sprints from a Lean/Kanban perspective. In this session, we will talk about Kanban-related myths prevalent in the Scrum world and identify common ground between them. We will look at ways to bring Kanban flow into your Scrum: the Kanban-based Sprint/product backlog, flow-based daily Scrum, visualizing aging work, and flow-based Sprint planning. We will describe ways to wrap Scrum with a Kanban flow system, and at the higher-level picture of a DevOps culture and process. You’ll leave with a better understanding of how Scrum, Kanban, and DevOps relate to each other and with ideas for experiments to try when back at work.
Recorded at Agile New England
The Sprint Increment Got Us Here
If you’re a veteran of the software industry, you probably remember those days when we released to production/GA every couple of months. Heck, many of the companies I meet these days still work that way.
If you’re also an experienced Scrum practitioner, you probably associate the time you started to use Scrum with the time you started to release more frequently. The Sprint Increment that had to be potentially releasable caused you a lot of pain as you were trying to improve your processes and capabilities, implement Continuous Integration, and finally gain the ability to actually have a releasable Increment each Sprint. You were pretty proud.
The Premise
A year ago Scrum.org, in collaboration with Daniel Vacanti and myself, published the Kanban Guide For Scrum Teams, a guide that is aimed at helping Scrum Teams take advantage of Kanban/Flow principles and practices. (I wrote an earlier blog post about understanding the guide)
SAFe™ has included Kanban at all levels since version 4.0. Some basic guidance about Kanban is included in most if not all SAFe curriculums. Can a SAFe practitioner learn anything from the Kanban Guide For Scrum Teams?
In this blog post, I’ll explore some of the flow metrics from the guide with an emphasis on those that aren’t covered in SAFe.
One of the new concepts we introduce in the Kanban Guide for Scrum Teams is the Service Level Expectation, defined as:
An SLE forecasts how long it should take a given item to flow from start to finish within your workflow. The SLE itself has two parts: a period of elapsed days and a probability associated with that period (e.g., “85% of work items will be finished in 8 days or less” which can also be stated as “8 days with 85% confidence/probability”).
Co-Creating and teaching the new Scrum.org Professional Scrum with Kanban class has given me an opportunity to get back to geeking out on WIP limits, flow metrics and all things Kanban. And it’s been fun!
In the Kanban Guide for Scrum Teams and the Professional Scrum with Kanban workshop, we introduce 4 key flow metrics that we believe Scrum teams
It’s been so exciting to hear so much positive feedback and interest in the new Scrum.org Kanban for Scrum Teams guide and the accompanying Professional Scrum with Kanban class. Creating the class and guide together with Daniel (Vacanti) & Steve (Porter) and then working on getting it to market in a professional way (how else? ) with the Scrum.org staff has been a great experience and a major focus area for me in the last couple of months.
As you might imagine, together with the interest come some questions about some choices we made in the design of the guide and the class. Several are emerging as the frequently asked ones. I wanted to tackle a couple of those in this post.
Where are some of the core Kanban practices?
Request for additional information and prices