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, the transcendence of the practice.
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.
“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.
This is Al Shalloway. Visit us at www.netobjectives.com.
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.
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?