In February, Julie Wyman and Trent Hone traveled to Fort Lauderdale, FL for LeanAgileUS. The conference brought people together from all over the world and attendees shared new insights into how people and organizations are working in more Agile ways. Here are Julie and Trent’s top takeaways from the conference. Scrum with Kanban – Julie […]
In February, Julie Wyman and Trent Hone traveled to Fort Lauderdale, FL for LeanAgileUS. The conference brought people together from all over the world and attendees shared new insights into how people and organizations are working in more Agile ways. Here are Julie and Trent’s top takeaways from the conference.
The aspect of LeanAgileUS that I appreciated the most was the blend of traditional presentations with longer, 3-hour plus, workshops. The workshops allowed me to dive deep into several interesting topics.
One of the workshops I attended was “Scrum with Kanban”, led by Steve Porter and Daniel Vacanti. Steve and Daniel introduced a newly published Kanban Guide for Scrum Teams. They carefully explained that it is NOT about picking and choosing the elements you like from both Scrum and Kanban (sometimes referred to as Scrumban). Instead, “Scrum with Kanban” blends the practices of Scrum—as described by Jeff Sutherland and Ken Schwaber in the Scrum Guide—with Kanban principles to visualize the Sprint Backlog and better manage the flow of work within the Sprint.
It’s easy to see how a Scrum team that starts all their stories on the first day of the Sprint, and only gets half of them “Done” in time for the Sprint Demo, could benefit from the application of Kanban principles, like work in process (WIP) limits, to smooth out their delivery. I appreciated that Steve went further, showing how improving flow could even aid teams that consistently deliver all their stories by the end of the Sprint (although they may deliver them all at the last second). In this later case, a smoother flow ensures a better workload balance across the team; it also reduces risk—through smaller batches and less WIP—if, for any reason, the Sprint has to be cut short.
Steve and Dan walked us through a series of examples that made a good case for leveraging the visibility and flow metrics of a Kanban system within the regular Sprint cadences. Several teams I’ve worked with have, over time, come to very similar conclusions on their own. They’ve seen great benefits from implementing WIP limits and tracking flow metrics along with their Scrum practices. So, I encourage all Scrum teams to read the Kanban Guide for Scrum Teams and think about how to bring better flow to their work!
I particularly enjoyed Jabe Bloom’s talk, “Designing for Lean-Agile Transition.” Jabe made the point that different levels of an organizational hierarchy operate on different time scales. At the team level, the focus is on the next several weeks or Sprints. Managers, or others who work with a collection of teams, will have a longer scale in view, perhaps to the next quarter. Above that scales continue to grow, until the leaders of the organization are looking out several years. I like this concept, and it resonated with me when Jabe explained that individuals at different levels will come into conflict when their time scales start to overlap.
I’ve experienced this; when former subordinates and I became focused on the same time scale—due to a planned release or upcoming event—friction inevitably seemed to result. Jabe’s view of time horizons offers an elegant explanation for why. We had become focused on the same moment in the future and our time horizons overlapped. The importance of properly segmenting focus is one of the reasons I wrote in defense of hierarchy in this space a little while ago; Jabe’s view expands on this point and resonates with it. I was pleased to see another, valuable take on this crucial idea.
Jabe’s perspective also contains a valuable warning. As we work with Agile teams to release in shorter and shorter time scales, we risk constraining the organization’s focus and limiting its ability to plan for the long term. Teams doing continuous deployment can narrow their view to a single week or less. That can pull their managers down to a time horizon of less than a month. If the upper levels of the organization don’t remain focused on the long term, this trend can continue until the occupants of the C-Suite abandon long-term strategic thinking and instead focus on just the next year (or less). This danger should be avoided, and it is important for Agile practitioners to keep it in mind as they go about improving the agility of teams and organizations.
Getting Agile requirements right can be a challenge but it’s essential as they can make...
Scaling, like Agile itself, can become a target objective rather than the means to an...