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.


One of the concepts that the Lean Start-up movement puts forward is the Minimum Viable Product. A Minimum Viable Product includes only those features needed to allow the product to be deployed, and no more. It is used to evoke fast feedback of a product or product feature. The concept is as applicable to process improvement as product development.

There are two critical words we have used for you to remember. The first is “feedback”. Unless you gather and listen to the feedback based on the process being implemented you are wasting your time. Keep developing and implement later. The second word to remember is “viable”.  The process you are implementing to generate must be useable and useful to generate rich feedback. An overly striped down process is merely a skeleton.

Engagement and feedback are interrelated like the bricks in the aqueduct.

Engagement and feedback are interrelated like the bricks in the aqueduct.

In Senior Management and the Success of Agile Implementation, I described the results of a survey of experienced process improvement personnel, testers or developers felt contribute to a successful Agile implementation. Tied for second place in the survey were team engagement and generating early feedback. These two concepts are curiously inter-related.

Team engagement is a reflection of motivated and capable individuals working together.  Agile provides teams with the tools to instill unity of purpose. Working with the business on a continuous basis provides the team a clear understanding of the project’s purpose. Short iterations provide the team with a sense of progress. Self-management and retrospectives provide teams with a degree of control over how they tackle impediments.  Finally, the end-of-sprint demonstrations provide early feedback. Feedback helps reinforce the team’s sense of purpose, which reinforces motivation.

Early feedback was noted in the survey as often as team engagement. In classic software development projects, the project would progress from requirements through analysis, design, coding and testing before customers would see functional code.  Progress in these methods is conveyed through process documents (e.g. requirements documents) and status reports. On the other hand, one of the most important principles of Agile states:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Delivering functional software provides all of the project’s stakeholders with explicit proof of progress, and provides stakeholders with a chance to provide feedback based on code they can execute. Early feedback increases stakeholder engagement and satisfaction, which also helps to motivate the team. As importantly, since stakeholders see incremental progress, any required course corrections are also incremental.  Incremental course corrections help to ensure that when the project is complete that most value possible has been delivered.

Team engagement and early feedback are both important to successful Agile implementations. Interestingly, both concepts are inter-twined. Feedback helps to generate engagement and motivation. As one of the respondents to the survey stated, “Agile succeeds when it instills ‘unity of purpose’ and builds a ‘community of trust’ within an organization.” Team engagement and early feedback provides a platform for Agile success.

Complicated user story!

Complicated user story!

A user story (See User Stories, October 28, 2013) is a brief, simple requirement statement from the users perspective. The classic format of a user story is:

“As a <persona>, I want to <goal> so that <benefit>.”

When initially constructed, a user story can represent a concept that the team can’t wrap their mind around and can’t finish in an individual iteration. Therefore the user story needs to be broken down into smaller chunks. Large user stories have three main side problems that can be addressed by breaking them down.

  1. They’re harder to understand.  Large stories generally represent multiple, related business concepts. An example of large story might be, “As a business man, I need to book a trip from Cleveland to Philadelphia so that I can attend a meeting.” Anyone that has booked a trip knows that are a number of smaller stories embedded in this larger story.  Booking the trip may well include an initial conveyance (plane, train or automobile), lodging and potentially rental car.  Until the larger story is broken down, it is difficult to determine if all of the parts have been identified.  It is also more difficult to determine how long it will take to complete the story, making it difficult to know if you have taken on too much work.
  2. They take longer to elicit feedback.  Agile techniques elicit feedback as work is being done. I have always found it easier to solicit feedback when I have something to show and acceptance criteria to compare against.  Acceptance criteria are typically constructed so that we can know when the overall story is complete.  When we are dealing with larger stories, we need to wait longer to get enough work done to use acceptance criteria as a comparison tool. For example, if I broke out conveyance to the meeting from the overall story, I would be able to get feedback on potential plane or train tickets (I am not driving) earlier than if I had to plan the entire trip.  Even if the only feedback point is at the demonstration where the completed story is reviewed by a wider set of stakeholders, a large story may fail to complete therefore miss getting formal feedback for one or more sprint.  Feedback is important to avoid rework.
  3. They can clog the flow of work.  The one thing that is always true in software development is that we never foresee all eventualities (popularly known as “stuff happens”). Generally when a team is working on a large story a substantial portion of the team is involved in getting all of the tasks done.  When something goes wrong or new tasks are discovered, it is highly probable that other planned work will be delayed.  The large story will clog the process.  Using our trip example, if I need to price Amtrak (train) and United Airlines (plane) and found out that United did not fly to Philadelphia, I would have to stop and research other flight options.  The new activity may well cause me to postpone other tasks I had planned for the day.  Breaking stories down into smaller pieces makes it less likely they will be stuck for long and when they are stuck it will be less likely that the whole team is stuck working on the problem. Value can continue to be delivered.

Smaller stories are easier to understand, estimate and implement. When the team understands a story they will be better able to deliver the value inherent in the user story.  The ability to understand is critical to reducing the possibility of surprises when they are developing the solution.  Surprises, when they do happen, will have less of an impact on the team if the stories are small enough so the whole team is not stuck.  Breaking down larger stories increases the through put and therefore increases the amount of value delivered.

The remainder of the week will be used to explore how to split stories.