I have been active in Agile for over 20 years now. Starting with eXtreme Programming, Scrum, Kanban, Lean, SAFe, and Flow not to mention the technical side of Agile that even goes beyond XP. While not at the first Snowbird in 2001 when the Agile Manifesto was written, I was invited to and attended the Snowbird 10th anniversary of the event. I’ve seen the Agile community turn from what once a true community, even a tribe, into a mostly driven for business operation. There’s nothing wrong with this except that the side effect has had a few individuals control the thinking of a few groups which has indirectly control the thinking of millions.
There are many insights and concepts I use on a literally daily basis that seem to be ignored because the duo of Scrum and SAFe don’t attend to them. I thought I’d catalog them here so those wanting to learn how to break out of the Agile echo chamber might be able to do so. Here are the ones I think most important at the moment. Many of these are in my book but some are not.
Many of the following relate to concepts that popular Agile methods say they attend to but don’t really.:
Concepts from my book Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation (online book)
The Business Case For Agility. Many people are still going after the wrong thing. Agile teams are like the engine in your car, critical, but only a component of what we are trying to accomplish. This chapter also introduces the minimum business increment (MBI) – one of the most critical components in achieving business agility.
The value stream of the effective organization. If you’re trying to improve it’s a good idea to know what improvement looks like.
Business Architect. The role of managing how different offerings affect each other is missing in most organizations.
The Technology Delivery Manager. If you are familiar with SAFe this can be thought of as an extended view of the release train engineer (RTE).
Agreements We Make With Each Other: The Guardrails. It still surprises me that most Agile adoptions begin with agreements on how to follow a framework instead of how you are going to work together.
Inherent Problems at Scale. Agile is difficult to achieve for a variety of reasons. It is useful to know what these are.
Laws of Software Development. Some of these are true laws in that they always apply. Some are more like adages or even principles. But they are worth attending to because they will attend to you even if you ignore them.
The Value Stream Impedance Scorecard. We all have an intuitive sense of what’s helping and hurting us. The Value Stream Impedance Scorecard is an explicit statement of this intuition.
Systems thinking and How It Can Be Applied to Frameworks and Methods. Systems-thinking tells us that systems are more about the resulting whole of the interaction of a system’s components than it is about the components itself. Agile has a history of doing local optimization. It’s important to understand the bigger view.
The role of leadership and management. These roles are critical. Even people who bashed the roles 15 years ago are admitting it by offering courses in it. But the Agile manifesto still does not mention management even once.
Why Epics Are Not Used in FLEX. Epics may have been ahead of their time 15 years ago but they are old school now and causing damage.
The Relationship Between Acceptance Test-Driven Development and Design Patterns. ATDD and design patterns can work together to improve the evolution of both requirements and the design of the system.
The need to teach the principles that drive practices with the practices. We see teams and organizations failing in the same way over and over again but haven’t questioned why. This will provide some insights.
Scaled Learning is a set of techniques that allows for more effective training at a lower cost. With the spread of Agile these methods are needed.
Why Agile Coaches Need to Know Both Scrum and Kanban. As Agile has spread throughout the organization different methods of adopting it is needed. Neither Scrum nor Kanban are always better. In fact, almost always a combination of both is useful, if not necessary.
Why Essential SAFe is Both More and Less Than What’s Needed at Small to Mid-Scale. While SAFe is very popular, most people are using at the program level and having difficulty using the higher levels. The reason for this is simple – the higher levels are more complicated than they should be and not as effective as they could be. But just using Essential SAFe has its own set of problems.
If you want to learn more about FLEX you can take an online course at the Net Objectives University or take a live course in Orange County, CA May 6-8 or in Seattle in June (both led by Al Shalloway). If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway