This is an except from Al Shalloway’s upcoming book: Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation. It is from a particularly important section called Teaching and Adoption.
I have never liked the common Scrum/SAFe approach of teaching select practices that are expected to be used as is. Their justification is that you need to understand how to use these practices before going beyond them. I have observed that while people need a set starting point they also need to understand why things are working. This creates learning opportunities from the start and enables a gradual improvement, or even, transcendence of the practice.
The martial arts model of “Shu (follow) Ha (break with) Ri (transcend)” is often used to justify this approach. But several several flaws exist in this logic. In the martial arts you are trying disengage your mind at first, not so in knowledge work In addition, no guidance on how to move from following (“Shu”) to breaking with (“Ha”) is provided. What’s worse, is that by defining Scrumbut in the way it has been, the belief that people who don’t “follow the rules” are somehow bad and get poor results.
The worst flaw, however, is more insidious. It’s the loss of the opportunity to learn while using. This would be to provide the underlying model of the practice. People can ‘follow’ the practice while seeing how it applies the underlying principles involved. This enables them to learn how to use these principles and tailor the practices for their own situation. They never break with the underlying principle but will break with the practice and possibly even transcend it completely. But not the principle.
Let me give you an example from sailing. Fledgling sailors are told to look at a flag or ribbon on the mast to see which direction the wind is going. But they are also told that they can learn to see the wind in the water if they look upwind and attend to the ripples on the waves. Newbies can immediately use the flag on the mast. But by looking at the more advanced practice of looking at the ripples on the waves they can learn to see the wind before it hits the sail – a very useful thing. So very quickly they learn to see the wind as it hits the sail and before it hits the sail. In addition, they eventually notice side ripples on the main ripples. These are from swirls in the wind. This tells them even more. They learn through a combination of using the basic practice, trying more expert practices, falling back to the basic one when needed and understanding what is happening much more. They never transcend the principles – only the practice that they started with. And they don’t have to do a sudden “break” with the practice, but can do it over time.
Learning with this combination of practices and principles is what sets Net Objectives training as different from frameworks. All frameworks are a combination of practices and principles. But the framework is defined by some core set of practices (e.g., in Scrum you must have time-boxing and cross-functional teams). The dangers of this are twofold. The most obvious one is that the practices prescribed may not fit your organization. But the other, more insidious one, is that doing this prevents you from learning as quickly as you would otherwise.
First of all, I like Scrum. I think it can be a great framework when used in the right place. But I also think it must be taught as a tool in your toolbox, not an end in and of itself. This means initial training of Scrum should include more of the flow model (eliminating delays in workflow, feedback and using information) on which it is based. Test-first methods should also be incorporated into this training. This combination allows for teams to avoid most of the pitfalls teams new to Scrum face. I also believe one should look to see if Scrum or Kanban is better for a particular team (or something in between). See first comment for how I do this.
See Why Agile Coaches Need to Know Both Scrum and Kanban.
Continue reading “What I Think About Scrum”
Creating software has several aspects to it.
- Deciding what to create
- How creating new software affects existing software
- How people work with each other
- The process being used to build it
Although all of this creates a very complex process, only the first three are fairly unpredictable, the fourth is not.
Continue reading “Time to Say Goodbye to Empirical Process Control”
“Were you directly involved in the creation of the materials for your workshop?”
This is important because it guarantees the trainer will understand the materials. And because you know they are prepared to handle skepticism met during the presentation.
Here is what trainers know. Creating course materials deepens your knowledge of the materials. You can question the assertions being made. You understand the order, and the reason for that particular order. You can anticipate questions that will be asked and the students’ skepticism. You are prepared to teach… and not simply to convey information.
A recent trend for certifying bodies is to bring in outside trainers to create materials for them. In many ways, this is good. However it means that these bodies are becoming somewhat more focused on marketing than on creating new concepts. They are taking other peoples’ work and putting it into their marketing and delivery channels. And they have trainers deliver courses who haven’t developed experience through build the materials.
They lack the deeper knowledge to help their students.
Design patterns are often described as “solutions to recurring problems within a context.”But the real power of patterns is to see the forces that each pattern resolves. They should be used as a way to help analyze what’s needed to create a quality design. That is the goal.
Given a situation where, say, the Strategy Pattern was not quite present but its concepts could be used, no one who understood patterns would criticize the solution by saying ,“Well, that’s not a Strategy Pattern!” So why do we hear these sorts of critiques in the process world? Let’s think about it. Continue reading “How Design Patterns Give Insights Into Process Patterns”
If you only quantify one thing, quantify the Cost of Delay” – Don Reinertsen
Cost of delay is the overall cost of loss in revenue, lost opportunity, increased risks, customer respect, etc., due to a delay in realization of value.
This jewel of advice not only tunes us in to what’s important, but it can guide us in all aspects of value creation and delivery. It’s what’s behind CICD, small stories, avoiding handoffs, not working on too many things, automated testing, test-first and more. Pause for a moment and consider how each of these remove delays in workflow, feedback, communication and error detection.
Projects miss schedules not because of one big delay, but due to a succession of small delays – each having a cumulative and cascading sequence of events that compound each other.
Using a mantra of eliminating these delays provides insights for how product owners, ScrumMasters and the team itself can work. Anticipating delays can even enable avoiding impediments instead of having to wait to hit them. The causes of delays are primarily working on items of lesser importance, lacking a focus on finishing, having too much work in process, lack of cross-functional teams, large stories and lack of collaboration. Understanding this greatly speeds up the adoption of Scrum for new teams.
Focus on Scrum. Use its practices, events and artifacts to drive teams to improve. For example, time boxing requires smaller stories. Releasable quality code at the end of the sprint encourages team members to work together. Retrospections are about learning. Daily Scrums provide an opportunity to pivot each day. This is the common way certified training is done.
Take a CSM course and teach it to your teams. This somewhat follows the above method as CSM classes also focus on Scrum.
Learn principles of flow (Lean) and Agile. Focus on how to do Agile work (small stories, collaboration, test-first, …) and then teach Scrum in how to support it.
The first two approaches teach Scrum but leave it to the team to learn what they need to do. The last approach gets people started on their real work and teaches how Scrum can support it.
Note: When I write things like this it seems clear to me which of these is the best way. Is it not clear to others?
I’ve been espousing (a nice word for rant) about the need for scaled learning methods and how 2-day classes have low retention. I’ve decided to integrate our On-the-Job Online Advanced Scrum Master / Kanban Coaching workshop with our Team-Agility Coach (our integration of Scrum/Kanban workshop.
Our online workshop is normally $595 but when you take our Scrum/Kanban master course we’ll include that for $200 a person. This means that our 2 day workshop followed by our 3 month program is $10,400 for 12 people ($500 for each additional person).
The onsite aspect of this integrates Scrum and Kanban. The three month program has me work with participants helping them apply what they’ve learned, as well as advanced topics of Agile, with their teams.
Please message me if you’re interested.
After writing about how our workshop avoids the issue of the 80-90% retention loss of normal trainings, covers twice the material of an Advanced CSM class, provides a performance support system and is provides timely coaching to its participants in their working with their teams, I had decided to raise the price from $595 to $895 – still a bargain compared to the common $1295 fee for an Advanced CSM class (not to mention the 2 days lost in an Advanced CSM class and likely travel time/cost).
But I’ve decided to go in the opposite direction. While the program is 3 months long, I will let people have access to the live coaching sessions included for 6 months along with the already annual access to the performance support system for a year.
I am committed to disrupting the current ineffective manner the industry now relies on for teaching people how to be Agile coaches. I am leading this workshop myself and promise it will change both how you look at Agile and Lean as well as your effectiveness.
We’re starting the next workshop this week, so please ping me if interested.
A friend of mine said I sounded frustrated in my posts. My reaction to myself was, of course, that I’m not supposed to be frustrated. But the truth is, I am
The reason? After 20 yrs of working to help people see how to do their work better I find I’m fighting the same battles I was 20 yrs ago. Only the difference is now we know what to do & there are active forces working against it. Waterfall was just an ineffective belief system-but no one was behind it.
Back then no one understood Agile or Lean or test-first or the importance of flow. We didn’t have modern learning methods nor the technology we have now that enables remote, on the job training.
The choice no longer has to be Scrum or Kanban but rather an integration of the two in a manner that works. It has been demonstrated that learning ATDD/BDD up front is critical. Learning how to be an Agile coach should be multi-month program working with your team on how to help them be more effective. And improving organizations must be based on increasing the ability to take strategies through deployment & realization
Unfortunately, our focus is on frameworks & certification. While containing good ideas they distract us from the real work at hand. If you have this sense as well, as always, I’m happy to chat