Preparation is key to reaching your goals.

Successful and efficient planning of any sort represents the confluence of preparing the work to be planned and proper logistics. Earlier in this series on planning, we  reviewed the basic logistics needed for a planning event and defined a simple checklist.  While both are important, preparing the work to be planned requires more effort.  Preparing the work for planning requires knowing the capacity of the team and grooming the work items (stories, requirements, support tickets and/or defects). (more…)

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

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 21st 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. (more…)

14955864_10154768928297276_8000508545464981060_n

There are those who believe that implementing a capability team is as easy as identifying a group of people, putting them together, and then doing a few team building exercises. Instant team! In the simplest terms possible – they are wrong.  There are four complicating factors that have to be addressed. (more…)

Find the defects before delivery.

Find the defects before delivery.

One of the strongest indications of the quality of a piece of software is the number of defects found when it is used.  In software, defects are generated by a flaw that causes the code to fail to perform as required. Even in organizations that don’t spend the time and effort to collect information on defects before the software is delivered collect information on defects that crop up after delivery.  Four classic defect measures are used “post” delivery.  Each of the four measures is used to improve the functional, structural and process aspects of software delivery. They are: 

(more…)

Onion

Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos.  Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. The onion metaphor that is popularly used in agile planning (Cohn’s Planning Onion) can be used to describe the evolution of backlogs. Building an initial backlog is much like peeling through the layers of an onion to get to the core. There are many mechanisms for developing and maintaining the detailed backlogs, including: asking, observing, showing and all sorts of hybrids. Using the onion metaphor, the techniques we have explored in the past are the second layer of the onion. However, before getting to the center of the backlog evolution onion, composed of features, epics, and user stories, we need to understand the big picture.  Structured storytelling is effective tool to elicit a description of an outcome and nuances behinds that description, the outer layer in the backlog onion. The outside layer of the backlog evolution onion provides a strategic vision used for budgeting, change management and to provide context to guide the team or teams of teams as the development process progresses. (more…)

 

A framework is just a framework without 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.

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

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 21st 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

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.