The Reasons We Created Scrum/ATDD

Agile Product Management is a key to quick realization of business value

The intention of teams adopting Scrum should be to help them quickly deliver value to customers predictably, sustainably and with high quality. Although Scrum was created for a single team doing development it is rarely used in exactly that context now. It is part of a bigger picture and teams often find themselves competing for limited capabilities. Agile product management provides this bigger picture and is therefore incorporated into Scrum/ATDD. Two quotes from Don Reinertsen, author of The Principles of Product Development Flow: 2nd Generation Lean Product Development (and considered the premier authority on this subject) tell this tale:

  1. “There is more value created with overall alignment than with local excellence.”
  2. “When your value stream just consists of a team, local optimization is global optimization.”

Our value stream is no longer just a team. We need to prepare teams to work within the bigger picture and not learn how to just self-optimize.

Acceptance Test-Driven Development is required

One aspect of Agile Product Management is to be clear about our requirements. This requires collaboration between Product Owners and development teams. The best way to achieve this clarity is through the use of Acceptance Test-Driven Development (ATDD) and writing stories in the form of testable acceptance specifications.

While teams can start with the “as a < type of user >, I want < some goal > so that < some reason >” this type of specification is not easily testable. It also doesn’t enable writing small stories. Integrating ATDD with Behavior-Driven Development’s “Given <situation> when <event occurs> then < this behavior is required> both greatly increases the necessary collaboration mentioned and writing small stories. Scrum/ATDD is the integration of Scrum and ATDD.

A serendipitous result is that when taught properly, it can be less expensive to teach Scrum/ATDD than Scrum alone.

Systems thinking and certain core Lean principles need to be incorporated into Scrum to facilitate continuous improvement

From the Scrum Guide: “Scrum’s roles, events, artifacts, and rules are immutable.” This was required when Scrum was created because it wasn’t well known how to apply Lean-Product Development thinking to software. We know this now. Using Lean-thinking (systems-thinking with a focus on time and quality) provides key insights to enable Scrum teams to improve. They no longer have to follow Scrum as a forcing framework – that is, a framework where if you follow the rules you get better results. Instead, they can start with Scrum as example, and then adapt it as needed.  Lean-principles can guide the team in making adjustments as needed for improvement.

Net Objectives has created a qualitative measure called the Value Stream Impedance Scorecard (VSI Scorecard) which can be used to help make decisions based on the team’s context and not a fixed framework.

Scrum should be specialized for software development/IT teams

Software is not the same as the physical world. While work in the physical world is often visible, in the software world it often isn’t. Consider how you can see what’s being built in the physical world, but in the software world, writing bugs or good code looks the same.

On the other hand, the software world has some advantage. For example, you can design software on top of a foundation that is readily changeable. You can also build a piece of software and start using it while in the physical world we often have to create prototypes to see what it will look like. It also takes more time to move from one task to another in the physical. Once you start to think about it, there are quite a few other differences.

Having a framework that is specialized for software can be designed to fill in what the physical world automatically provides for us but the software world doesn’t. It also allows for us to create value faster than would be possible in the physical world.

It also allows for training that is specific to those attending it. Scrum taught as a general framework is often considered to abstract and theoretically. People like to know what they need to do for their situation.

Scrum/ATDD includes a support system so that teams can start using it without requiring expensive embedded process coaching

People can only absorb so much information in a short time.  Although our Scrum/ATDD workshop has three days of attendance over four days, it is still a lot to absorb. Scrum/ATDD therefore is provided with a support system to help people learn over time.