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
Using a predetermined set of roles, events, artifacts and rules is like having a GPS that just gives you the directions without the map. If you get lost or you can’t make a turn or you miss it you are lost.
Being given a map with alternatives to get there provides not only options that work for you but provide a way of getting back on track when you get lost. In the complex world of software development it is even more likely you’ll need this ability.
Many people require a given set path. But have it include where you are and have it provide you with a reset option when you get lost. This is what Lean-based team Agile does. Scrum doesn’t even try because you are out of Scrum by this time. Scrum proponents just call this Scrumbut and go on to the next team. This doesn’t mean you can’t use Scrum, it just means that when you do Scrum you should do it within the context of Lean.
Which has you feel more trusted and respected?
1) Consultant comes in and says “do this until you understand what I’m telling you. Only then can you modify it. Trust me.”
2) Consultant comes in and says “when looking to improve, look at this and these patterns. Imagine how they have affected you in the past. Take those experiences with these new insights and solve your problems. I’ll be here to guide you but won’t tell you what to do since you need to understand why what you’re doing is going to work or not. And I know you can. Trust yourself.”
Neither is inherently better. It depends upon you.
Frameworks provide us with:
- A list of roles, actions and artifacts which are useful
- A set starting point
However, frameworks don’t discuss:
- When they are most applicable
- How to transcend them after the adopting organization has successfully adopted them
Frameworks are also not meant to be modified. The reason for this is stated as self-evident & therefore rarely (ever?) discussed. However, there is much evidence that a framework being adapted to an organization while still providing a set starting point is a better way to go.
The net result of the above is that people tend to adopt a framework as is. And many tend to require adherence to it. All of the above strikes me as particularly non-Agile. We have put fences around what we can do. The justification for this has been twofold – people need to follow something until they can think on their own and it’s too difficult to come up with a tailorable model.
The first one strikes me as not having confidence in people’s ability to figure out what they need to do. The second one misses the point. I’m not suggesting that the people adopting a framework figure this out, I’m suggesting that consultants and trainers figure this out and be what they present to their clients.
The prevalent kind of Agile team training is:
- here’s what to do
- follow it until you understand it
- you can fill in the blanks, but don’t change the foundation
- if you do, we can take no responsibility for results because then you’re not doing what we said
Continue reading “Two Different Kinds of Training (admittedly a rant)”
I know I’m on the edge. And I know I don’t fit everyone – both in style and approach. I prefer working with people who want to think, people who have confidence in themselves. People who are open to learning but don’t believe what they are told until they understand it. People who look for consultants to guide them – not direct them.
I believe frameworks have their place to provide insights on where to start and what to do but are a risk when just followed- which is what most promoters imply when they say “you have to do this until you understand.” I believe that statements says more about their ability to explain and points to a weakness in their framework than it does about who they are talking to.
I have always questioned stock answers, because I believe HL Mencken’s comment – “for every complex problem there is a simple, neat solution that is wrong” applies all too often. The quick fix might get you started but it might also be exactly what gets you even more stuck after just a little while.
I believe that a good approach provides immediate value. And if it doesn’t, then a better approach is available.
If you have similar beliefs, I believe you’d find me valuable to work with.
This is almost universally used to teach how to write stories. But notice, it’s a goal, not a method. Goals are good, but in themselves, don’t provide much guidance to get to them (think “buy low sell high”).
A better way to learn to write stories is to take advantage of the discovery & specification phases of Acceptance Test-Driven Development (ATDD). While usually relegated to the 2nd or 3rd round of training we’ve seen light-weight ATDD integrated with initial Scrum training enables teams to write stories right out of the box and eliminates 3 of the major challenges most teams have adopting Scrum:
1) writing small stories
2) having clear requirements
3) understanding why testing cannot lag coding
This is the key to learning Agile- not just learning the end state desired, but using methods that actually help get you there. It is easier to act your way into a new way of thinking than think your way into a new way of acting.
ATDD has the dev team focus on identifying and validating (Testable) Small chunks of Value by “Negotiating” with the PO. Part of ATDD is to decouple (make Independent) the stories. Since these stories are now understood, they are also Estimable.
Certifying bodies promoting a particular brand have changed the industry for the better in many ways.
But they are businesses. And their model is selling training. As much as possible, as you’d expect from any business. And the people they support’s model is training and placing coaches.
Brands compete – so it’s not surprising to see a focus on the brand in workshops instead of activities everyone needs to learn. If the focus were on the work much of Agile training would look similar.
Training today is not that dissimilar to what it was 20 years ago – intense workshops with follow up coaching. The first is inefficient (people don’t retain much from workshops) and the second is expensive.
We need a disruptive force here. But don’t expect the certifying bodies to provide the disruption – they have no incentive to make things more efficient. Expect the disruption to come from somewhere else.
Given I’ve written 5 books, delivered 100s of courses/talks/ webinars, influenced Scrum, Kanban & SAFe, that’s a big statement. I think it’s true because I hope its introduction of proven methods of training/coaching developed at Harvard will prompt the Agile industry to improve current methods which I believe are outdated and one of the biggest impediments to the widespread adoption of effective Agile.
• Common training formats are ineffective and expensive. Intensive 2-4 day workshops have been shown to be the least effective method of conveying skills. These also incur the cost of lost days and possibly travel to take. Flipped classroom methods are both more effective and much less costly to deliver and incorporate follow up coaching
• Content. Being effective requires both Scrum and Kanban. Each are selective views of Lean, which is now recognized as a critical component of Agile beyond a team.
• Lack of a support system. There are patterns of challenge and solution which should be provided to students so they get assistance in solving problems on their own
Bottom line – this method can increase the effectiveness and content of a course while dramatically reducing real cost
You can learn more about this course here. Take the overview box (mostly black) for a 28 minute overview of the class that explains both content and format.