Does the raft have a peak load?

Software development is inherently complex and therefore risky. Historically there have been many techniques leveraged to identify and manage risk. As noted in Agile and Risk Management, much of the risk in projects can be put at the feet of variability. Complexity is one of the factors that drives complexity. Spikes, prioritization and fast feedback are important techniques for recognizing and reducing the impact of complexity.

  1. Spikes provide a tool to develop an understanding of an unknown within a time box. Spikes are a simple tool used to answer a question, gather information, perform a specific piece of basic research, address project risks or break a large story down. Spikes generate knowledge, which both reduces the complexity intrinsic in unknowns and provides information that can be used to simplify the problem being studied in the spike.
  2. Prioritization is a tool used to order the project or release backlog. Prioritization is also a powerful tool of reducing the impact of variability. It generally easier to adapt to a negative surprise in a project earlier in the lifecycle. Teams can allocate part of their capacity to the most difficult stories early in the project using complexity as a criterion for prioritization.
  3. Fast feedback is the single most effective means of reducing complexity (short of avoidance). Core to the DNA of Agile and lean frameworks is the “inspect and adapt” cycle. Deming’s Plan-Do-Check-Act cycle is one representation of “inspect and adapt” as are retrospectives, pair-programming and peer reviews. Short iterative cycles provide a platform to effectively apply the model of “inspect and adapt” to reduce complexity based on feedback. When teams experience complexity they have a wide range of tool to share and seek feedback ranging from daily stand-up meetings to demonstrations and retrospectives.
    Two notes on feedback:

    1. While powerful, feedback only works if it is heard.
    2. The more complex (or important) a piece of work is, the shorter the feedback cycle should be.

Spikes, prioritization and feedback are common Agile and lean techniques. The fact that they are common has led some Agile practitioners to feel that frameworks like Scrum has negated the need to deal specifically with risks at the team level. These are powerful tools for identifying and reducing complexity and the variability complexity generates however they need to be combined with other tools and techniques to manage the risk that is part of all projects and releases.

Safe to fail experiments are about education.

Safe to fail experiments are about learning

In IT, ‘safe to fail’ describes activities that are used to generate knowledge. Additional terms that might be used are probes, spikes, R&D and prototypes. The outcome of a safe to fail experiment can be innovation, the information necessary to make decisions or to discover alternatives.  All these scenarios are appropriate for a safe to fail experiment, however sometimes safe to fail experiment are not safe nor are they appropriate.

Safe to fail experiments are appropriate in situations where learning is required to deliver a project. You might need an experiment or a bit of prototyping to learn whether something is possible or if there is a more effective way to perform a repetitive task. For example, earlier in my career my team converted credit card portfolios from one provider to another. We used a standard process for most of the hard work. Yet, we were always looking for a way to make the process more efficient using mock conversions as experiments. The goal was to find better processes and techniques.  These experiments did not always yield process changes, but they always added to our knowledge of what would and wouldn’t work. Another opportunity for safe to fail experiments is in situations where several possible alternatives exist. You need an experiment to determine which (if any) of the alternatives make sense. A test or an experiment is considered successful if it proves either that an alternative is a good choice OR if the results can be used to cross an alternative off the list. Organizations that judge results that can disqualify an alternative as a failure are apt sort out alternatives in the market place rather than before they go into production because their experiments will not truly be safe. Finally, safe to fail experiments are useful tools in formal decision-making frameworks. For example, frameworks built to comply with the CMMI process area, Decision Analysis and Resolution (DAR), often leverage safe to fail experiments to generate data for formal, structured decision-making.

Safe to fail experiments are not always appropriate.  Many projects exist with a both fairly well understood solution and a hard deadline. In some portion of these projects the solution may not be perfectly optimal or the coolest possible solution, but it is doable in the timeframe. Experimenting to find a more optimal solution when taking the time and effort could cause you to miss the due date is not appropriate. In the credit card example mentioned earlier, we explored new ideas and optimization between projects to avoid experiments that would put the conversion at risk or cause the team to miss more of their weekend than was already necessary. Experiments that imperil the commitments a team has made or inhibits their ability to effectively deliver are not experiments and are safe to fail. Experimenting is also not appropriate where negative results are thought of as a black mark on a career. In this case straying from the tried and true approaches are generally a bad idea. This scenario tends to occur in highly politicized or overly competitive organizations. In this type of scenario if you can’t change the environment, I would suggest experimenting with other job opportunities. A third scenario is more questionable than absolutely inappropriate. In scenarios where there is little potential upside to the experiment experimentation is probably not a good idea. In most organizations, time and attention are always in short supply. Every team needs to judge what it needs to learn and ration resources that are in short supply when there is little or no perceived upside.

Safe to fail experiments are scenarios where an organization or team truly wants to sift through possible alternatives before using them in a project or in production. Safe to fail experimentation is an application of the scientific method to generate knowledge and decisions so that teams and projects deliver more value.

Remember: DEEP

Remember: DEEP

I like to describe the product backlog in Agile projects as the hub from which all other activities spring.  The backlog encompasses more than just the features that the project will deliver. The backlog includes features, bugs. technical work and research. As with many agile tools and techniques, despite the power and importance of the backlog, the life cycle of project backlog items included in the backlog is fairly simple and straightforward.  The backlog is a list of work items that are prioritized and accepted into a sprint. The team breaks the items down into tasks and activities for the sprint backlog and then demonstrates or reviews the completed items at the end of the sprint. Work that was not accepted, incomplete work items and new work items are added (or re-added) to the backlog.  The backlog is continually groomed and prioritized.

Backlog items include:

  1. Features – The functionality delivered by the project is identified in the list of features on the product backlog.
  2. Bugs – You need to capture defects when they are identified so the team can allocate effort to fixing them. Note: Defects that can be correct on the spot are probably not worth the overhead of tracking.
  3. Technical Work – Non-functional work items make up substantial portions of many projects.  Non-functional work can range from network changes to application architecture changes.
  4. Knowledge Acquisition – Research is an occasional, but important feature in many projects.  Teams need to set aside time to determine solutions, explore an idea and/or learn a new process or tool.  We have explored the concept of spikes (a specific quantity of time set aside to develop an answer) as one mechanism for knowledge acquisition.

The items on the product backlog must include all of the items a team will work on during the project. All the items on the backlog can and should be described using  a user story because it makes the team go through the discipline of determining who will be affected, by what and the value of the work item. While the product backlog includes the overall requirements, backlog items don’t become truly operationalized until they are accepted into sprint planning and broken down into tasks and activities.

Roman Pitchler and Mike Cohn (and many others) have described four attributes of a good product backlog.

  • Detailed Appropriately – Backlog items that are to be done soon needed to be understood and granular enough to be completed in a single upcoming sprint (the sprint should be upcoming very soon). Those that will be worked until later in the project don’t need to be as well understood.
  • Estimated – Each backlog item should be estimated.  The level of precision of the estimate for any item will vary based on the how soon the work items will be completed. Estimates are useful as a trigger to break work items down and as an input into prioritization.
  • Emergent – The backlog will evolve and change over the life project.  Backlog items will be added, completed, split, changed, deleted base on the feedback the team gathers as they learn and deliver value.
  • Prioritized – The work items that are the highest value or need to be done first need to at the top of the backlog. The product owner with the support of the team owns the prioritization process.

The DEEP mnemonic gives the discussion backlogs a metaphysical feel. More importantly it provides the team with a reminder that in Agile, gone are the days of the big requirements document that acts as a contract to drive development. Backlogs, however, are more than of a to-do list that acts as the central planning tool for Agile projects.

Spikes are for research

Spikes are for research

A spike is a type of user story that is used to answer a question, gather information, perform a specific piece of basic research, address project risks or break a large story down. Fundamentally, spikes are used to address uncertainty by gathering specific information to understand a functional or technical requirement. For example, when the team needs to prove a specific technical problem or do not have enough information to estimate the story they would use a spike.

Spikes are treated like user stories using the standard format (persona, goal, benefit).  The benefit is the goal of the research, rather than direct user value.  Because a spike does not deliver direct value they should be used sparingly. Spikes are not a cop-out to slip back into waterfall behavior.  Another difference between a spike and a typical user story is that are not estimated, but rather time-boxed.  Instead of an estimate, the team commits to spending a specific quantity of time performing the necessary research.  Upon the completion of the time box the original story is reframed, groomed, split or rewritten based on the information learned during the time box.

Spikes should be estimable, demonstrable and acceptable. They should be added to the project backlog and prioritized.  The time box needs to be long enough to answer the question posed in the spike. Once accepted into the sprint the team effort required for the spikes time box should be burned down just like another story.  At the end of the sprint the results need to be demonstrated during the sprint demo. As with all stories the outcome of a demo is that the spike results are accepted or rejected.  Spikes almost always generate new stories.

Teams need to have a mechanism for dealing with what they don’t know. But, don’t get addicted to spikes.  If every story needs a spike, the wrong team is probably working on the project.  Spikes are a serious tool for teams to gain knowledge, determine how to mitigate a risk, validate that a technical approach is feasible or to decide how to estimate a story.  Spikes are not a back door to analysis, design, build and test (i.e waterfall).