My Work with Scrum.org
For the last few years, I have been working with Ken Schwaber and the good folks at at Scrum.org on several projects. Through this work I have come to understand that Scrum is fundamentally misunderstood by most of it’s practitioners. Heck, I learned many of my own notions were wrong and my understanding has been constantly improving. With that in mind, I have decided to go all in Scrum.org’s mission of Improving the Profession of Software Development. This isn’t to say I am just travel around teaching Scrum classes. That’s not the deal.
I am going to write and speak about this stuff more.
I will be making some announcements regarding specific projects in the near future.
I am joining others in meaningful work that generally seeks to improve our craft.
This all started because of a conversation I had with Ken. I expressed my exasperation that Scrumbut implementations tend to outnumber healthy Scrum teams.
My early experiences with Scrum were horrific. I started trying to use Scrum as a team leader way back in the 2003 time-frame. Specifically, I read the books and my organization paid for the standard 2-day Certified Scrum Master course and we had 30 people sit the class, all before starting to use Scrum. Great start, eh?
For the next 6 months, we squandered money at an alarming rate struggling to implement the theory and principles we learned in our Scrum training. We made a lot of mistakes while trying to enact the Scrum framework. I have come to understand in the years since that this all too common. So common, in fact, that it is the norm for organizations new to Scrum.
I also expressed to Ken a concern that Scrum did not have answers for all developers. There are simply work systems in which Scrum is not currently an ideal solution.
When Ken heard all this, he did what any great mentor does: He challenged me.
“So, do something about it,” Ken said.
That’s a big ask, and not something that is going to be solved by 2-day training classes. That said, training has been a logical place to start and I will be making some announcements soon that focus on training. But, for Scrum itself to mature from here there are some things that need to be debated in the daylight and those include:
- Appropriate use of continuous flow models.
- Technical practices needed for Scrum to work well.
- True understanding and use of empiricism to develop software.
- The meaning of commitment.
- Frameworks vs. methodologies.
- Genuine understanding and exploitation of of self-organization.
- Ensuring HR people understand that you can’t certify competence, only knowledge. Right now.
- And plenty of others.
Consider this the Main() method for a series of posts on these issues and others that seek to discover where we can all go from here.
So, let’s get started. What problems do you see that Scrum suffers? What would YOU do about them?