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:
July 19, 2016
May 24, 2016
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…)
December 30, 2014
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.
December 29, 2014
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.
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.
October 9, 2014
The team backlog is comprised of everything a team might get done because if it is not on the list, it can’t be prioritized and taken into a sprint. Simply put, if it isn’t on the list there is no chance of it will get done. The attributes of the team backlog are:
- The backlog includes all potential work items of the team. Work items will include user stories, non-functional requirements, technical items, architectural requirements, issues and risks. Note: All of these can use the user story construct for communication and presentation.
- Backlog items represent possibilities. Until the team’s product owner prioritizes an item and the team accepts the item into a sprint, it is merely an opportunity that may get done.
- Backlog items should be estimated. An estimate reflects the level of effort required to complete the work item based the definition of done and the work items acceptance criteria. Until it si accepted into the sprint, having an estimate is not a sign that the work item has been committed to be delivered.
- The product owner owns the backlog. The product owner prioritizes that backlog therefore controls what the team works on (product owner is a member of the team). In programs, the product owner helps to channel the programs priorities.
- The backlog is groomed. Grooming includes ensuring that backlog items are:
- Well formed,
- Prioritized, and
- When necessary removed.
Disclaimer: I am a list person. I have lots of them. I have not descended into lists of lists, albeit I do have a folder in Evernote of lists. Backlogs are the queue of work that a team will draw from. Backlogs, like any list, can feel like they are the end in their own right; almost a form of tyranny. I heard it said, “What is the reward for completing a user story? Another user story.” The backlog can seem relentless. However grooming, prioritization and sprint planning ensures that the team works on what is important and valuable. The backlog is merely a tool to make sure nothing is inadvertently forgotten or ignored.
July 26, 2014
Hand Drawn Chart Saturday
Techniques for building an initial backlog can be classified by how the conversation between stakeholders and the project team is initiated. Some techniques are focused on asking, other techniques focus on observing, while the third category is all about showing something and getting reactions. Most practitioners blend the best from each of the categories. Here are some examples of the hybrid techniques:
Role Playing Prototype: This technique blends paper prototypes (show) with role-playing (observe) to get users and stakeholders to consider how they might act in an environment that has not been fully designed.
Straw man/JAD: This synthesis seeds a JAD session (ask) with an loose outline of a solution or set of potential solutions that are used to guide the discussion which are at the core of JAD. However, the seeding tactic can inhibit creativity. The technique is less constraining when a set of competing solutions is used as the conversation seed, however developing the range of solutions before the JAD session increases the cost of the JAD.
Embedding: This techniques puts team member(s) into a department to actually perform the work (observe) alongside actual users and stakeholders. This generally requires the embedded team member to be trained and mentored to intimately see how the work is done. I have seen debrief sessions added to this technique to ensure that participants get a chance to discuss the nuances in the workflow. As I have noted before, with any observation technique everyone needs to understand what is going on and why. This is not an episode of Undercover Boss.
Combining tactics from different categories of techniques that teams use to develop an initial backlog can fundamentally change the dynamics of the requirements definition session. A group of stakeholders will generally have a diverse range of learning and interaction styles that they favor. Combining backlog building techniques gives the project team a better chance at making a connection. Combining techniques should not be done randomly or an ad-hoc basis. Selecting which techniques to combine has four prerequisites:
- Someone with experience and training (perhaps a business analyst).
- A knowledge of the user community (knowledge the product owner can provide).
- Planning (time and effort).
- Involved users and stakeholders (call on the product owner and project sponsor to help with this prerequisite).
Developing an initial backlog is a step to get projects going and moving in the right direction. It is, however, only a first step. Backlogs will evolve. Teams, product owners, users and other stakeholders will gain knowledge and experience as the project move forward that will continually shape and reshape the backlog.
July 24, 2014
One of my jobs during high school was in a tire manufacturing plant in Memphis, Tennessee. On more than one occasion the hated and dreaded time and motion “guy” showed up to observe how I was doing my job. I never knew what the outcome of the observation was or whether the change to the four page process I performed to sort green tires was due to the observation. The job was never easier after the change. Reflecting on that time (and several industrial classes later) I understand that observation is an important tool for developing an understanding of how work should be done, but is not a tool to be used all the time. Using observation in the right scenarios and then taking steps to plan how you will observe is critical getting value for the effort needed.
Why observe? The simplest and clearest rational for using observation techniques is that users and stakeholders either don’t always know what they want or can’t always express their current needs and foresee their future needs. Therefore a new set of eyes will expose more and different needs. There are four typical reasons for observing should be considered as a tool gather knowledge and requirements.
- Physical location is a determinant. Processes and work flow is often affected by the physical location. When the physical layout of the people or machines could strongly affect the solution the team developing the initial backlog should observe the process in action to understand the nuances of flow of work.
- When people can’t tell you. Occasionally the process being studied will be so complex that no one is able to coherently describe how it works or how it should work. Even more occasionally asking is met by silence due to lack of trust. In both cases observation is a valid tool to develop an initial backlog.
- When interactions are crucial. Complex processes often require a wide range of interactions between people, tool and applications. Interactions, except when they cross the boundary, are difficult to identify unless you see them.
- When the output and the process don’t match. When, on occasion, the measured output or the output described by a manager does no match what is possible based on the published process then observing the real process is mandatory.
Once you have decided that you must observe, planning becomes a necessity.
- Begin by reviewing the known policies, culture and process of the organization or team being observed. This step helps to ensure that you have a sense of the environment and what you will be seeing.
- Decide on how long you will observe. Some processes and process variations need time to be seen. If a process requires a week to complete you will need to observe for at least that amount of time.
- Determine how you will record what you see. Trying memorize what you see will result in some information, however you will at least need to take notes. Remember that recording can include taking notes or recording audio and video. The level of detail needed will help determine the method needed.
- Finalize the logistics of the observation session before showing up. Office space, network and physical access can suck up huge quantities of time and effort. If you have a week for observation do not spend the first day dealing with administration tasks.
- Decide how you will create rapport with the group you are observing. Your presence will cause disruption. You need to find a way of observing with minimal impact to the results and without scaring those you are observing into calling placement firms. I am a fan of transparency; tell people why you observing and what will be done with the data. Where possible I usually involve those that I have observed in an early review of the data collected to elicit more information (hybridization of techniques by combining observing and asking).
- Finally do what was planned, but do not be afraid to tweak the plan as needed.
When I was in the tire plant, the time and motion guy would just appear and no one was thrilled. When we saw him coming we followed the proscribed process a bit more carefully, even if it was less effective. Observation can change behavior positively or negatively (Hawthorne effect). Sometimes observation might be the only way to know what is really happening, but without planning the data you gather might be what someone wants you to know rather than what you need to know.