This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and 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.
Andrew - I apparently didn't write this well enough.
The user does not realize they have a bucket full of tools. They only have the tools they need, but they are tools that work for them.
We know enough now that not everyone needs to make sense of the jumbled discord of knowledge that characterizes most of Agile. A good framework, such as DA, organizes this information so the user can just get to what they need.
So in practice you are using the 5S Methodologie (Analogy) adapted to DA to organize the tools in a way of increasing the user perception on the overall function of the tools, at witch lifecycles they belong, when they should be used, in conclusion assigning the tools for each DA prescrition ?
Thanks, Al. I do understand. I think I meant to write more, then got distracted away. And stinks we cannot edit comments here, only in discussions.
Is it fair to say, though, that not all options may be understood immediately, by say, the newbie mechanic, but as they grow in their role, they gain a better understanding of what is available to them and how to utilize that in which is available? Or even better understand what it is actually needed so to have a better ability to find a solution, in this case, a ready-made solution.
Hadn't thought about it that way, but yes. Look at the big picture, see what needs to be accomplished and then select fit for purpose. But the real thing here is not Disciplined Agile. It's that it can be done. The minimal = simple so that you can start easier is seriously flawed and unexamined.
Andrew - thanks for the clarification. Funny i had thought i had just misunderstood. And you are absolutely right. So the way things are exposed has to account for this. As a consultant using DA you don't just go out and give them everything. That's exactly what the minimalists are afraid of. But it's like teaching someone who has never ridden a bike when they get a 27speed bike. first teach them 1 speed (set the appropriate speed for them and don't let them change it) and the rear brake. Then teach them the rear derailur. then the front break. then the front derailur.
a system must be both architected for this and have a way to learn. The integration of DA and FLEX is ground-breaking because FLEX provides a good architecture at scale and DA provides the options in the different contexts.