Rethinking the Practices of Scrum - or What Would Chris Alexander Say?

June 13, 2008 — Posted by Al Shalloway

Note: This blog talks about MMFs because that was the term we used in 2008.  Today we use the term MBI meaning Minimum Business Increment.  

I have just come back from SQE's Better Software Development Conference after having finished my sixth team-oriented Scrum training in the six weeks. It has been an amazing time with these teams and it has reinforced my belief that learning Scrum needs to be a team-activity because Scrum is a team process. To create a highly functioning team, everyone on the team needs to understand the basics of Scrum. The team's coaches - the Scrum Master and the Product Champion - need some additional training for their specialized roles. It gives everyone a common vocabulary and a shared understanding. And it provides the foundation for developing specialists as needed. Contrast this with other training approaches you might see out there that seem to focus their training on the becoming a Scrum Master. Why would you put everyone through that? It is not the best use of their time or your scarce training budget. It is better to equip them with what they need to do their work. That is why Net Objectives offers team-oriented Scrum training with follow-on training for Scrum Masters, for Product Champions, and for testers and developers. And no, this blog is not a commercial.

It brings me to what I have been doing for the last six weeks. The companies I have been working with were quite diverse. They included a gaming company, a company embedding software on a personal product, an IT organization, and two online services organizations. They ranged in size from 50 to almost 50,000. The team sizes ranged from 8 to 500.

As diverse as they were, they had many similar problems; and the challenges they had with Scrum were virtually identical. They included:

  • How to estimate large features
  • How to coordinate teams in an enterprise that have dependencies between them
  • How to keep the big architectural picture in mind while developing small stories
  • How to keep stories coordinated that make up an epic
  • How to convince developers not to work on code in a style that is based on individual preferences that make it difficult for team or cross-team support
  • How to make things work if they just jump into doing sprints

There were others, but I think this is enough to give you the pattern: Scrum teams are having a challenge keeping the big picture in mind while dealing with small things.

Before I proceed, I want to be clear about two things. First, I like Scrum. As CEO of one of the largest Scrum training companies on the planet, that should be obvious. Take a look at my blog posting, Praise for Scrum. As much as I like it, it is not the answer for everything. It is important to help practitioners understand where it works, where it does not, and where it needs to be extended and how. 

Second, Scrum is more of a framework than a set of practices. Scrum is really about delivering software in stages with self-directed teams figuring out the best approach. There are many practices that are core to Scrum, such as daily stand-ups, release planning, and sprint planning; and basic quality practices apply as well, such as continuous process improvement, and voice of the customer. Unfortunately, most Scrum thought leaders have refused to clarify what good practices are beyond these or even what constitutes the core competencies of Scrum. This may be rooted in the fear of being prescriptive and causing teams to use practices that don't apply to their context. However, in my experience, this has led teams to much wasted effort and inefficiency as each team has to discover these core practices for themselves. There is no need to continually reinvent the wheel when some kind of wheel is needed every time. Teams need to know that wheels are needed and what comprises a "wheel." More so, many teams end up picking up practices from other teams because "that's what we thought Scrum was".  This results in even more challenges.

Rather than being prescriptive or being completely evolutionary, we prefer a third way, guiding through patterns.

Patterns are not prescriptions

In the Lean-Agile community, I am known for my insistence that Lean can be useful for Scrum teams, I am also known for having written a book with Jim Trott called Design Patterns Explained: A New Perspective on Object-Oriented Design. In the process of writing this book, I gained two key insights from Christopher Alexander in his seminal book, The Timeless Way of Building. The first is that patterns are not prescriptions, but rather about the forces present in the problem domain and resolving them.  In the past I have spoken about using principles to suggest practices, and this is consistent with this insight. 

In this blog, I want to talk about the second major insight I got from Alexander.  Alexander basically states that "good design requires keeping the big picture in mind." That is, design pieces within the context of the larger whole - what it is that you intend to create. For example, if you are looking at putting a porch on a house, you do not just design the porch in isolation. Nor would you try to make some sort of generic porch  that could do all sorts of "porchy" things. Rather, you would start with where the porch is going to go. You would consider the house it will be attached to and the yard behind it. You would think about how it relates to the things in its surroundings. 

The idea of designing from context is fairly obvious in the real, physical, world. For some reason, in the software world we often approach things differently. Focusing on the re-usability and de-coupling of classes made me think that classes needed to be designed in isolation from each other - paying attention only to what a class did and how its interface should be defined.  Once I realized what patterns really were, I also realized that when designing a class, instead of thinking of how the class works, I needed to think of how it will be used. (This latter approach follows the "Dependency Inversion Principle" which I will not go into here.) Thus, Alexander's contextual design appears to be a general principle - applying in both the physical architectural world and in the world of software design. I have long felt that this is a general principle and would therefore apply in other places as well.

Patterns in Agile

Consider each of those challenges I mentioned earlier. Each one of them arises because we are dealing with small, isolated pieces and then trying to bring them together. In Agile circles, large features are typically thought of as a collection of stories. This practice derives from XP practices where one starts with stories given to a small team by a customer. Over time, the size of these teams grew as their projects grew. Stories got larger and many related stories were needed. Practitioners assembled them into collections which they called "epics" or "themes." This was helpful. It at least created concepts that were very useful. But it came at it from the wrong direction: building up from small to large. This is backwards. While one could say Scrum doesn't address this issue at all, I would say that Scrum is how it lives in the community and this is what happens there.

Lean says to "optimize the whole." One consequence of this is to prioritize work in order to create the most business value as soon as possible. Adding value to the customer drives most of this business value. Prioritization can involve minimizing risk and uncertainty, increasing competitive position, maximizing the number of common services available, exploring alternatives, or other factors. This is one of the most important jobs that the Product Champion has (hence, the need for that more specialized training).

However it is sorted, we want to work from greater priority to lesser priority, pulling out smaller stories until we have whatever is required to define the bigger picture and implement it in stages. This focuses the team on whatever is required to create the highest value fast. You might think of this as the minimum marketable feature (MMF) pattern, as defined by Mark Denne and Jane Cleland-Huang in Software by the Numbers.

"As the name implies, an MMF is characterized by the three attributes: minimum, marketable, and feature.

Probably the most significant characteristic of an MMF is the fact that it represents a distinct and deliverable feature of the system. Webster's dictionary describes a feature as "the structure, form, or appearance" of an entity, or as its "prominent characteristic." A feature is therefore something that is observable to the user. For example, in an online travel agency application, a flight planner and an online tour organizer might be seen as distinct features. In contrast, a class library would not be considered a feature because it provides no clear-cut and deliverable functionality to the user. Similarly, an underlying architectural layer that provides the infrastructure for an application would likewise not be a feature, because it only provides value when delivered within the context of the entire application.

An MMF also must provide significant value to the customer. We use the term "marketable" to describe this concept. However, value can be measured in many ways, such as revenue generation, cost savings, competitive differentiation, brand-name projection, and enhanced customer loyalty. Even this list is by no means exclusive, as true value can only be defined within the context of the proposed project and measured by the organization developing the software."

Stories as described by most Scrum practitioners are not MMFs, but rather things of value, that, when combined, create some valuable feature that can be released. By starting with an MMF, one starts with the big picture. Stories can then be defined within the context of this instead of starting with the stories and then seeing how to combine them to make the value marketable.

How this applies to Scrum

This has a potentially dramatic impact on Scrum planning. By creating a thought process where one goes from the big picture, from the context, Scrum teams can start out with MMFs up-front, with those essential large stories that specify the functionality of the MMFs to be built during the project. The Scrum process then becomes one of:

  1. Writing minimum marketable features that describe the functionality that needs to be implemented
  2. Estimating these features at a high level
  3. Creating a conceptual architecture which creates the context for the parts as they are built (see the streamzines Commonality- Variability Analysis and the Analysis Matrix on our Technical resources page - you'll have to register to get access to them)
  4. Preparing for iterations by laying the groundwork required

By turning around the context of small-to-large to large-to-small, many of the problems facing Scrum teams will be easier to solve. As I said earlier, this isn't really counter to Scrum, it's just something not mentioned by it.  By taking advantage of general design principles available from other disciplines we can improve our Scrum practices.

This blog is already getting to be pretty long. I will leave it to future blogs to address all of the implications of this turnaround in perspective. One of our Senior Consultants, Guy Beaver, is chomping at the bit to explain how to write user stories from Business value. In fact, it is Guy's work that sparked some of these insights and write this blog.

Mostly, I wanted to put these thoughts out there if you have been thinking that something has been wrong in the common practices of Scrum that don't keep the big picture in mind. You might be right.  Trust your instincts on going from large to small.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

I'd suggest that if you observe the design of good solutions, it won't be either "small to big" or "big to small" but rather a more complex mix. The good end result may seem to look like it was derived using a big to small process but that's not really how creativity works.

Otherwise, I'd generally agree with the post.

I agree, it is actually a combination of big to small and small to big.  However, in Scrum, it is better to start big to small, then see how the pieces fit.  I presented this one-sided view as a start to both be a little provocative and to help balance out the opposing view which is almost all I have seen.

Alan Shalloway, CEO Net Objectives

#1 thru #4 - Isn't this part of what happens in Sprint 0 (well, ideally for a smaller product)? For a larger product, it would start well before "Sprint 0" and Sprint 0 would be more for finalizing the MMFs, the architecture and the iterations - correct? So this does fit well within the scrum framework.

Starting with MMFs will certainly help with making priority decisions.

I agree that this should be done in Sprint 0.  Sprint 0 is an extension to the original Scrum framework that many (most?) Scrum practitioners agree is a good idea.

Alan Shalloway, CEO Net Objectives

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban