Scrumban: Different Genie, Different Bottle

Sometimes you just have to . . .

I was originally asked to help provide additional ideas to convince a Scrum Master that had recently joined a team due to a company rotation policy not to give up Scrum (full scenario). The change in team composition led to problems.  On the surface, the decision by the wayward Scrum Master to abandon Scrum in favor of Kanban is an emotional reaction and does not reflect many of the leadership problems the Scrum Master introduced. Assuming that the leadership problems have been sorted, it is time to contemplate how the team will work as they move forward.  The question was posed as use Scrum or use Kanban; however, there is a third (and possibly better) answer. Do both — Scrumban.

 

Getting Stuff Done: Scrumban and Beginning With A Backlog

Longer races usually use “bins” to group runners, like classes of service.

Without some sort of structure, projects, daily to-dos, ideas and just flat stuff can quickly overwhelm anyone. Many, if not most, of us have spent time taking time management classes of all types in an attempt to find the secret sauce for managing the chaos that is the 21^st century. My wife is a sort of adherent of GTD®. Once upon a time I took classes for the Franklin Covey Planner, and I dutifully carried it everywhere. In recent years I have used Scrum and Kanban to manage projects. Many of the lessons in Agile and lean project management coupled with time management concepts are a useful synthesis: a personal Scrumban (Kanban-y Scrumban) approach. The approach begins with deciding on a set of classes of service and then developing an initial backlog.

 

Two Teams or Not: First Do No Harm (Part 2)

WIP limits are needed to stop waiting in queues.

Recently a long-time reader and listener came to me with a question about a team with two sub-teams that were not participating well together. In a previous entry we began describing how kanban or Scrumban could be leveraged to help teams identify issues with how they work and then to fix them.  We conclude with the last two steps in a simple approach to leveraging kanban or Scrumban:

 

Two Teams or Not: First Do No Harm (Part 1)

 

Sometimes a process change is required!

Coaching is a function of listening, asking questions and then listening some more.  All of this listening and talking has a goal: to help those being coached down a path of self-discovery and to help them to recognize the right choice for action or inaction.  Sometimes the right question is not a question at all, but rather an exercise of visualization.

Recently when a long-time reader and listener came to me with a question about a team with two sub-teams that were not participating well together, I saw several paths to suggest.  The first set of paths focused on how people behave during classic Scrum meetings and how the team could structure stories.  However, another path presented itself as I continued to consider options based on the question.  

 

Metrics: Adding Complexity to Cumulative Flow Diagrams

A waterfall is an example of a complex flow!

The simple cumulative flow diagram (CFD) used in Metrics: Cumulative Flow Diagrams – Basics introduces most of the concepts needed to read and use a CFD. However, software development, regardless of the size of the work or the method used, is more complicated.  CFDs adapt to the true complexity of software development. CFDs allow teams and managers to visualize the flow of work .

 

Getting Stuff Done: Daily Retrospectives

Reflection is a central tenant of all Agile frameworks. Do a bit of planning, execute against that plan, then step back and reflect on what was done and how it can be done better. Reflection acts as both a capstone for a period of work and as an input into the next cycle. For example, in Scrum each sprint culminates with the team performing a retrospective so they can learn and improve. Retrospectives have the same power whether they are team based or done at a personal level. In personal Scrumban, performing a daily retrospective is useful to generating focus and then tuning that focus based on the day-to-day pressures and changes in direction.

Daily retrospectives are a quick reflection on the days activities and how they were performed. The goal of the daily retrospectives is continuous improvement at a very intimate level, focused on the day YOU just completed. The process can be a simple extension of classic listing retrospective techniques (answering the questions “what worked well” and “what did not work,” and then deciding on what can be done better). A second process for daily retrospectives that I often recommend (and the one I use) is to:

1. Position yourself in front of your Scrumban board. Personal Scrumban boards come in many shapes and sizes, ranging from white boards marked with columns for backlog, doing and done with a few yellow sticky-notes to fairly sophisticated tools like Trello or LeanKit Kanban.
2. Adjust any cards (or tasks) to ensure that the current state of progress is reflected. This step will ensure you have re-grounded yourself based on what was accomplished during the day and made sure the board is ready for the daily planning/stand-up session the next day (kill as many birds with one stone as possible).
3. Reflect on what you accomplished during the day. Celebrate the successes, then ask yourself whether you learned anything from what you accomplished that could be generalized and leveraged in future tasks. Alternately, ask yourself what was one new thing you learned today. Make a list and watch it grow. These techniques support process improvement, but are also motivational.
4. Reflect on what you committed to accomplish during the day and did not complete (if anything). The goal is not to re-plan at this point, but to determine what got in the way and what can be learned from the experience. Pick one of issues you identified that you will commit to working on fixing (and are within your ability to address) and add it to your backlog. Consider for performing more of a formal root cause analysis (Five Whys for example) for the items that continually find their way on list.
5. Close your notebook or turn off you laptop and call it a day!

The process for daily retrospectives is fairly simple. I try to spend 15 minutes at the end of work every day performing a retrospective. More than once I have tempted to spend more than 15 minutes on the process, however when I do, I find that what I’m really doing is planning for the next day. If I have found a shortcoming to the daily retrospective it is that I try to perform the process as the last event of the day (hence step 5), which makes it easy to forget if I am tired or the day has extended into the wee hours of the morning. Frankly, those are exactly the days that a daily retrospective is needed the most.

Daily retrospectives provide a tool to make changes when they can have the most effect. By their nature, daily retrospectives are more focused than weekly- or team- or sprint-level retrospectives, but that focus makes them very valuable for affecting the day-to-day process of how your work is done. Adding daily retrospective to your personal Scrumban adds the power of an empirical process to your daily grind.

 

Getting Stuff Done: Planning

 

A framework is just a framework without planning!

Personal Scrumban establishes a framework for conquering the chaos that day-to-day life can throw at you. However having a structure, even a structure with multiple classes of service, does not get the most important pieces of work in the queue when they need to be in the queue. Planning is required. Weekly and daily planning exercises, similar to sprint planning and the daily stand-up, are useful for taming the backlog and adapting to the demands of real life.

I begin all weekly planning sessions with a quick backlog grooming session (note: when new items are added to the queue during the week, grooming can be performed). In personal Scrumban, the goal of backlog grooming is not get team consensus (no need for the Three Amigos). Rather the goal is to ensure each backlog item that might need to be tackled in the next week has been broken down so that there are one or two immediate next steps identified. The first step in backlog grooming is to ensure that all work items (or stories) have been classified by class of service. For example, if one of the work items was “Review cover art for the Hand-Drawn Slide Saturday Ebook,” the work item should be classified in the Podcast/Blog class of service. Classes of service act as a macro prioritization and assigns the work to the relevant time slice in any given day. The second step is sizing, just like in Scrum, the immediate next steps should be of a size that can be accomplished in a single sitting. The information gathered in execution will used as part of daily planning or during the next weekly planning session.

Weekly planning is comprised of getting work items in priority order and then deciding which needs to be dealt with during the upcoming week GIVEN what is known when planning occurs. If you have not already established a work-in-process limit (WIP), set one for each class of service. A WIP limit is the amount of work you will allow yourself to start and actively work on at any point. Work is only started if there is capacity to complete the task. Prioritize up to the WIP limit or just slightly past the limit in each category. Remember if as you complete tasks in a category (and you have time) you can refresh the backlog by prioritizing new items. I generally do my weekly planning every Sunday evening so that I am ready to begin the when I roll out of bed on Monday.

Daily planning is exactly like a daily stand-up meeting, with two minor twists. In Scrum, the daily stand-up meeting starts the day with each team member answering the three famous questions:

• What did I complete since the last meeting?
• What will I complete before the next meeting? and
• What is blocking progress?

The three questions provide a framework to make generate laser focus on what is done and what needs to be done. The twists

In personal Scrumban, as in normal Kanban, completed work items would have been moved to the completed column of the Kanban board as soon as they done, however this is a good time to ensure that has occurred. The twists relate to how new items are dealt with and time allocation. During planning, work items that will be accomplished during the next 24 hours should be moved to in-progress. Given the nature of daily planning, if new work items have been discovered and prioritized into the backlog, they then become part of the standard planning process. The stand-up also provides time to reflect on anything that will block accomplishing the planned work items. A second twist to the stand-up process is a reassessment of the time slices being provided to each class of work. For example, if a critical work product needs to be completed, time from a more discretionary class of service can be reallocated and the work items in this category can be put on hold.

A weekly planning session provides a stage to address the week. To paraphrase Helmuth von Moltke the Elder, no weekly plan stands first contact with Monday. The daily stand-up provides a platform to re-adjust to the nuances of the week so that you can stay focused on delivering the maximum value possible. Without planning, all personal Kanban is a framework and a backlog of to-do items.  Planning puts the energy into the framework that provides the guidance and reduces stress.

 

Getting Stuff Done: Scrumban and Beginning With A Backlog

Longer races usually use “bins” to group runners, like classes of service.

Without some sort of structure, projects, daily to-dos, ideas and just flat stuff can quickly overwhelm anyone. Many, if not most, of us have spent time taking time management classes of all types in an attempt to find the secret sauce for managing the chaos that is the 21^st century. My wife is a sort of adherent of GTD®. Once upon a time I took classes for the Franklin Covey Planner, and I dutifully carried it everywhere. In recent years I have used Scrum and Kanban to manage projects. Many of the lessons in Agile and lean project management coupled with time management concepts are a useful synthesis: a personal Scrumban (Kanban-y Scrumban) approach. The approach begins with deciding on a set of classes of service and then developing an initial backlog.

In a typical implementation of Kanban, classes of service allow teams to break backlog items into different groups either based on risk or the cost of delay. In our personal Scrumban, we combine the concept of cost of delay with different focus areas. Unlike a typical work environment where a person and team would focus on one thing at a time, a personal process for handling the overwhelming list of projects and tasks that occur in everyday life needs to acknowledge life is more than a project or a sprint.

I have developed an approach that recognizes five classes of work ranging from association work items to work items associated with my work (I am process consultant and manager at the David Consulting Group). Each class of service has a higher or lower priority based on the day of the week and time of day.

My Classes of Service

For example, daily items like running or editing a podcast segment typically have higher priority between the time I get up and beginning the work day. In a similar manner house/personal and podcast/blog entries priorities are driven by day of week and/or time of day. Alternately work and association items are driven by cost of delay. The backlog items in each class of service vie for the slices of attention available 24 hours a day and seven days a week.

Backlog items are captured in a wide variety of manners. For example, project work items can be captured using standard techniques for building an initial backlog (observation, showing, asking and/or synthesis). Backlogs for most projects can be developed using these techniques. Many smaller items or grand concepts will be discovered while encountering day-to-day trails and just generally living life. These need to be captured and logged (a habit that has been drilled into me by my wife), where they can be broken down and prioritized at leisure rather than being forgotten. Just as in a typical backlog, items that that are higher priority (by class of service) are broken down into next steps that are small enough to be completed in one to two days.

Using Scrumban as an approach to bring order out of chaos can be combined with other time management techniques. Real life is more complicated than a single project. For example, real life might be a project at work, prepping the yard for winter on the weekend, training for a half marathon and writing a book before sunrise. Each type of work is its own class of service that needs to be addressed separately to focus on what is important, when it is important.

 

SPaMCAST 277 – Scrumban and Limitations of Scrum from Steve Tendon’s Tame The Flow

Software Process and Measurement Cast http://www.spamcast.net

Check out Software Process and Measurement Cast 277.  SPaMCAST 277 features our essay on Scrumban. Scrumban is the combination of Kanban (lean) and Scrum (Agile) techniques. Each contributes different things to the hybrid framework. Kanban contributes a focus on flow, while Scrum contributes a focus on people and timeframe. Together, both focuses bring value to process improvement. The understanding of how these two sets of techniques and philosophies can be combined provides change agents with another powerful arrow in their quiver of available options.

Also in SPaMCAST 277 Steve Tendon discusses the limitations of Scrum.  Many people believe Scrum is a silver bullet for every situation.  Steve will attempt to dissuade you of that opinion!

Remember to register for the “Influential Agile Leader” events led by Johanna Rothman and Gil Broza.  Check out the full details at www.InfluentialAgileLeader.com

Get in touch with us anytime or leave a comment here on the blog.  Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature an interview with Diane Zajac-Woodie. Diane and I talked about the role of business analysts (BAs) in Agile projects and Agile teams. BAs can play an extremely important communication and leadership role in Agile projects which enhances the team’s ability to deliver value.

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars.  The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

 

Scrum . . . A Simple Framework: Barnacles

Barnacles attach to ships and add drag

In earlier entries of the Daily Process Thoughts, I believe we have established that basic Scrum process can be defined using three roles, five events and three artifacts. This is the Scrum canon, much like the canon of stories that make up the Sherlock Holmes series. Many organizations and consultants have added practices to Scrum in order to meet specific needs (if those needs are real or perceived is an open question).  At the Scrum Gathering in Las Vegas in 2013, Dr. Alistair Cockburn called these additions barnacles; Ken Schwaber has written extensively about “Scrum buts. . .” and “Scrum ands. . .”. Barnacles grow on the hull of ships and create drag, slowing the ship or requiring greater energy to drive the same distance. However for all of the downsides of a barnacles they serve a purpose, deliver a benefit, or they would not exist in nature.  The additions to Scrum must compete and deliver value or they will be swept aside.  Several of the more common barnacles are related to defining and estimating work. They include:

• User Stories, phrased in the now classic “persona, goal, benefit” format, are an addition to the canon of Scrum.  User stories provide a disciplined framework for describing units of work, which improves communication.
• Story Cards, which generally include the user story, acceptance criteria, size and other ancillary pieces of information, provide a means to the organize units of work a team will be working on.  Organization of information provides a means of visualizing gaps and keeping track of work items so they can be communicated (and in my case, so they don’t get lost).
• Story Points, are a representation of the size of a user story or any unit of work based on the collective understanding of the team that is being tasked to deliver the work.  The use of story points provides a team with a consistent scale that helps team members communicate about their perception of size.
• Planning poker, a variant of the Delphi estimation process, acts as mechanism to structure the discussion of size and estimation within Agile teams to increase communication, ensure all relevant voices are heard and to control paralysis by filibuster.

Add to the potential additions technical practices like Test Driven Development, Behavior Driven Development, Continuous Builds and hybrids like Scrumban and the number of potential barnacles can grow quite large.  That is the nature of a framework.  Techniques, practices and processes are bolted on to the framework first to see if they improve performance.  As practitioners and methodologists we must insure that only those that provide tangible, demonstrable value are allowed to stay bolted.  Remember that each organization and team may require more or less barnacles to be effective.  Like the Sherlock Holmes stories, others have extended the canon with their own stories, practices and process.  Some are valuable and find traction, while others are experiments that have run their course.