An Open Letter to Participants When We Go In To Train
I've been talking a lot about what's needed in the Agile space is a better training method and a better way to use frameworks. I've also talked about how many company's getting to Agile are late adopters. I often write letters to would be participants of proposed training and I realized that many companies are not late adopters but rather have been rightfully concerned about what Agile training they'll get. They want improvements, not frameworks which at best are a means to an end.
I recently wrote such a letter and thought it'd be worth sharing. This was for a proposal for a small-scale adoption of Lean-Agile (small scale is 3-10 teams with associated product owners).
Here it is:
First, those of you who are concerned about getting Agile training, I don’t blame you. Most “Agile” training isn’t about Agile really, but rather about Scrum. These are two different things. I don’t believe in frameworks that force you to do things so that you’ll get better. I prefer providing insights to people so they can use them to get better. You’re already capable, knowledgeable people who know your job much better than me. Most of you probably know a good amount about Scrum anyway and learning more may or may not have value.
A little bit about me. My background is as a developer / architect. I’ve written two technical books – Design Patterns Explained and Essential Skills for the Agile Developer. I believe you can only teach what you’ve done and I’ve done a lot of development and product management. Although I have taught Scrum for almost 20 years and Kanban for over 10, I can assure you it was always in support of the real goal – improving the capabilities of the people being trained. I have no interest in teaching you frameworks or methods. My interest is in helping you get your job done in a more effective and efficient manner. As someone who developed software for over 3 decades, I’ve been there. I also promise you you won’t hear any dogma from me.
The training that’s being proposed has four main aspects to it:
- How to identify the most important work to be done
- How to provide that to the teams
- How teams can break these targeted business increments down into small stories in a way that also provides clarity on the behavior that’s needed and in such a way that it’s easier to implement
- The light ceremonies needed to keep the teams coordinated
To be clear, the training is not about teaching you “Agile” so you can figure out how to work better. It is about providing insights and patterns that you can use to do your work better. We won’t focus on standups or retros, but rather on things such as how getting clarity on requirements helps inform design and why smaller is better.