Making things simpler by providing choices with Disciplined Agile

 

Everyone agrees that simple is better than complicated. But there's not a lot of agreement on what simple means. Many in the Agile community view simple as meaning minimalistic - having as few parts as possible. Scrum in particular, has intentionally been defined as a minimalist framework in order to keep it simple. While Scrum may be simple, if any of its immutable roles, events, artifacts and rules don't fit a team then this lack of fit will make its adoption more complicated than it would be if a fit were provided.

Some people believe the only alternative to Scrum's minimalistic approach would be a framework that is too complicated because of all of its options. I do not agree with the presumption that including more choices results in more complexity. In the same way a well architected software application will only expose those options that make sense for the user, a well architected framework will do the same. This keeps the number of exposed options similar to a fixed set. 

The purpose of architecture is to avoid this from occurring. Software developers have been doing this for decades with application and system architectures. We should expect frameworks be architected as well to enable us to have multiple implementations to choose from without adding complexity. This enables us to choose what we need instead of reinventing it or possibly never knowing it exists.

Architecting frameworks this way also makes it so those new to Agile don't need to re-invent the practices they need. Although it is presumed they will, they often don't and when this happens Dark Scrum is a common result.

Consider how tool boxes in an auto-repair shop are organized. The top drawer contains the commonly used tools. But underneath the top drawer are other drawers - each containing more specialized tools. Mechanics don't think of the toolbox as one big container, but rather as an organized set of tools that they navigate according to their need. 

When a new mechanic is being trained they may not even be aware of many of these tools. But as we need them, they can be explained to the newbie.  They certainly don't need to be re-invented. This organization enables easy access to what's needed without overloading anyone. 

Users of a framework should not have to worry about how the framework is architected as much as how it is used. Choices can be presented without adding complexity. If this is not done then practitioners are often required to use practices that are not really suited for them. Using practices that are not fit for purpose adds complexity on its own. 

This is the idea of Disciplined Agile's Way of Working. It enables you to find practices that are fit for purpose. The Disciplined Agile framework has been designed to be easy to navigate and make choices. That's our job. The user's job is define their challenge. They get help in doing this from Flow and Lean thinking on which DA is built. 

It is easy to design something that is simple to understand but difficult to master. But this is often the result of poor design. Good design separates the user interface (in this case, how the framework presents itself to the user) from how the system is implemented (in the case, the inner workings of the framework). This is one of first laws of design - decoupling interface from implementation.

With proper design, frameworks can make things much simpler by focusing on fit for purpose instead of fewest components/practices available. Most frameworks need to step up to this. Fortunately, Disciplined Agile already does.