One of the core tenets of Scrum is that it will expose the challenges you are having by the end of a sprint. Another is that Scrum is a lightweight framework not specific to any particular type of product development. Yet another is that teams are successful with Scrum because of self-organization.

These ideas have led many to infer that the best way to start with Scrum is to focus on the framework since it is so simple. Just give teams some basics in how to do Agile work but mostly have teams start with Scrum. Then time-boxing and the practices of Scrum will uncover impediments and teams will self-organize to remove them.

This sounds good in theory, but how often does it work in practice?

Consider this common situation. A team receives initial training that focuses on Scrum and provides only lightweight coverage of Agile analysis. Very often, the team will discover that they have many stories open at the end of the first sprint. In other words, most of the work may be done but few of the stories are fully completed (that is, they are tested). At the end of their first sprint, they realize that they need smaller stories to begin with and more of a focus on finishing.

So, as they prepare for their next sprint, they attempt to write smaller, better defined stories. However, the day of the retrospection and planning for the next sprint is a tough time to be learning. In addition, they are often under so much pressure to catch up that they often commit to two more weeks of work on top of the work they hadn’t completed. Unfortunately, the adage “the first 90% of the work takes 90% of the time and the other 10% of the work takes another 90% of the time” has a lot of truth in it. This can be the start of a downward cycle.

It does not have to be this way. If management is on board, they can meet with the team and recognize that the right thing to do in this situation would be to give the team the opportunity to learn from the sprint and to spend a couple of days writing better stories and only commit to what makes sense given the uncompleted work from the sprint before. Unfortunately, this rarely happens.

The irony is that because this sounds all too familiar, it can be anticipated. You don’t need the sprint to tell you what will happen. What happens if you begin to learn Scrum from a different perspective?

The first thing to acknowledge is that the Agile world is quite a bit different than it was 20 years ago. Since Scrum’s creation, both Lean Software Development and Kanban have arrived on the scene. In addition, Theory of Constraints has become much more widespread and appreciated. We can use these bodies of knowledge to understand the challenges teams have and will face as well as patterns for their solution. This means that teaching the skills to solve the problems they will face will be a better idea than focusing just on Scrum. While self-organization is important, knowing what to do is probably more important. It should not be assumed that people will figure out what to do, and in any event, there is no reason to re-invent the wheel.

So, instead of believing that:

• We need to use Scrum to expose the challenges you are having within the length of a sprint.
• Scrum is a lightweight framework not specific to any particular type of product development.
• Teams are successful with Scrum self-organization

We accept that:

• Using an understanding of Lean flow and systems thinking we can see what a team’s challenges are without having to do a sprint
• While it’s great that Scrum can be used anywhere, when used by development teams it should be taught for development teams
• Teams are more successful when they know what they need to do

These changes have a profound impact on our thinking on adopting Scrum for software development teams. Because we know so much more about Agile than we did 20 years ago, we can focus on what the work teams do and prepare them for the challenges we know they will face. This also means that in addition to better initial training we can provide them with a support system that will help them with the challenges they will likely face. This also means that anything about Scrum we don’t teach in initial training can be picked up later.

The bottom line is that since Scrum is simple but Agile is not, spend more of the time you have on initial training on Agile (e.g., Accceptance Test-Driven Development). But doing so requires a support system: a place Scrum Masters can go to get questions answered as they need them.