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?
There are two main problems that I see Scrum suffering from right now.
1.) Does not provide guidance or rules around actual development work, just process. Many teams fail, because they are not enabled to succeed by following good development practices in addition to Scrum’s processes.
2.) Time boxing ends up creating a large amount of waste. In estimating, in eventual padding and story size inflation, and in debating what is and what isn’t in scope. Time boxing is great for training wheel for a team, but we need somewhere to go from there. Continuous flow is more difficult, but has less waste. Once a team gets to a certain point, Scrum needs to adapt to the new needs of the team.
I wrote a post on what I think is a pretty good solution here: http://simpleprogrammer.com/2010/04/28/the-kanbandand-guide/
I call it Kanbanand, but it is essentially my idea of a continuous flow Scrum.
@john – I’m not sure that Scrum was ever meant to provide rules around development work. Scrum was built as a framework… and I would go as far as to say that good development practices (xp) compliment Scrum very well.
Scrum was never meant to be the silver bullet. It was built as a light framework to start.
@David Starr – Very much looking forward to what you have to say as well as what you find out. I’m staying tuned!
“do something about it” = go work for free and make me more money
That sounds a little bitter and personal. Want to man up and tell us about it?
When did the word “request” go out of fashion?
Scrum’s strength is also its weakness in terms of perception. Scrum is designed to bring light to problems in a development cycle as soon as possible and provide a guideline on what a team can do to resolve those obstacles. Teams or management are often not receptive to having problems visible and think that there’s a problem with the process. (I.e. iterations too short, etc.) and you end up with Scrum-buts.
I don’t recall the quote specifically but it went along the lines of “If you aren’t encountering obstacles, you aren’t practicing Scrum”.
That sounds like more of an issue with human beings than an issue with Scrum. I understand what you are saying here, and perhaps the thing we need is a set of clearly understood ways to communicate the issues that Scrum shines a light on?
Good that you decided to do something about!. In my experience as you said scrum is not always the perfect solution and every team should adapt it to its particular situation or experience. At this time we’re using “scrum” but in very lighted way and methodology so more than help I think it’s adding waste. Any way I’ll keep in tune t see what good practices I see here that I can apply to my current team.
I think you would have to approach it from both directions separately. Development Team -> Management, and Management -> Development team. The pigs need to learn what it is to be a pig, while the chickens need to learn what to expect from the pigs without worrying/commenting on what a pig does. Managers can learn about ways to monitor and direct a Scrum project; specifics such as burn-down charts, etc.
@6776b55697c09f2c1751984fbbcda0e2:disqus
Agile Scout
I fully agree, when well implemented scrum (or any of the other
agile development methodologies) will make your team more productive, I have
seen scrum teams become very productive then fall apart once they finish
solving the process problems, and start exposing the human problems:
micromanaging scrum master, manager that refuses to let the team self manage,
rouge team members that sabotage other teams, forcing teams to be to large,
etc.
The sad thing is the process that was working is blamed or abandoned because
of the human element. @twitter-15013693:disqus I think you hit it right on the head in the
Elegant Code cast with Ken a little while ago, if you have managersteam members
a that don’t trust their teams or each other Scrum wont work.
Finally! After a few months of elegant slow down, sth comes up! Keep on writing David, I’d like to read a lot about ‘how not to’ 🙂