OK, time to stir the pot a little. In the blog posts Scrum is not Enough and Call It What It Is, I've been critical of the fact that Scrum by itself is inadequate for providing teams with a sustainable, long term approach to building software. I'm not alone in this opinion - Jeff Sutherland and Ken Schwaber also teach the use of XP practices in addition to Scrum's:
I want to make it clear at this point that I do believe that there is tremendous value in Scrum and its practices. It will allow teams to improve their productivity. It forces more direct communication and more visibility into the development process. These aren't just good, they're great! Again, though, the long-term viability of the Scrum practices alone is questionable. Teams need to use engineering practices in addition to the Scrum management and team practices in order to be successful.
So, why don't I see this in the courses? Why are those, such as James Shore and Mary Poppendieck, who say that Scrum practices alone aren't enough being called out? Perhaps it's as simple as the fact that basic, out of the box Scrum is a very easy sell to management and teams.
Let's frame this as "Dave the Manager walks into the Software Development Process Big Box Store":
My team is thrashing and we need some help. What do you have?
Again, Scrum is good. It just doesn't provide enough in its own practices to sustain the level of improvement that can be achieved.
Ron Jeffries on the XP Yahoo GroupAt the same time, Certified ScrumMaster courses are booming and Scrum is becoming the de facto standard for Agile - when most people talk about "Agile", they are in fact referring just to Scrum.
Also Ron Jeffries on the XP Yahoo Group
Video of Jeff Sutherland presentation
Jeff Sutherland's Blog
Interview with Ken Schwaber
InformIT Article with Ken Schwaber and Kane Mar
I want to make it clear at this point that I do believe that there is tremendous value in Scrum and its practices. It will allow teams to improve their productivity. It forces more direct communication and more visibility into the development process. These aren't just good, they're great! Again, though, the long-term viability of the Scrum practices alone is questionable. Teams need to use engineering practices in addition to the Scrum management and team practices in order to be successful.
So, why don't I see this in the courses? Why are those, such as James Shore and Mary Poppendieck, who say that Scrum practices alone aren't enough being called out? Perhaps it's as simple as the fact that basic, out of the box Scrum is a very easy sell to management and teams.
Let's frame this as "Dave the Manager walks into the Software Development Process Big Box Store":
My team is thrashing and we need some help. What do you have?
"Hey, Scrum is fantastic! It will help you right away with communication, and prioritization. The best thing is that we're not going to tell you how to do your work! Your team is self-organizing!"Nice. I'll buy that! CHA-CHING!!
"Oh, by the way - you'll need these few other practices to make sure it all works."Huh? But I just bought Scrum?
"Sure, and it's great!! You just need to buy these few..."But I don't have any money left to buy anything else!
"Oh. That's a problem. I guess you can get away with just Scrum, but those few other practices..."You said that Scrum would help me!!!
"Of course it will. And these few other practices will help more..."That's false advertising!!
"I BEG YOUR PARDON, SIR?!! HOW CAN YOU SAY THAT?! I told you that Scrum will help your team... you just need these few other practices to make sure it helps for a long time."OK, so this is a bit over the top. However, can you see the point? If you're selling, teaching, promoting, or otherwise suggesting that someone use Scrum for software development and you aren't pointing out that the engineering practices must also be examined, then you are partaking in false advertising. I would imagine that in the vast majority of cases it's entirely unintended, but it's still false advertising.
Again, Scrum is good. It just doesn't provide enough in its own practices to sustain the level of improvement that can be achieved.
Comments
I have a suspicion that CSMs aren't pushing that message very hard in most Scrum installations.
XP was more forgiving. (It was my observation of the difference between Ward Cunningham's and Ken Schaber's personalities - and how you could see that reflected in, respectively, XP and Scrum - that led to my Process and Personality, of which I'm proud.)
I hadn't read "Process and Personality" before - very nice. I noticed early in my days in the "agile world" that there seemed to be an abundance of people who were Myers-Briggs Intuitors ("N"'s). That could also be attributed to early adopters in general, though, but I certainly agree that personality does have an effect.
I've recently seen some interesting things happen in that respect - Tobias Mayer saying that Mary Poppendieck is trashing Scrum, David Anderson up in arms about the lack of a forum for Kanban at Agile '09, and many references to Sutherland Scrum vs. Schwaber Scrum. That also takes me back to the whole XP/Agile Universe and Agile Development Conference debates a while back, and the whole reason for the meeting of minds at Snowbird that created "agile" in the first place. Essentially, I'm seeing that the agile "movement" is still personality-driven. For any long term success, that's going to have to change.
Hmmm... perhaps that's why waterfall persists to this day - you don't hear anyone saying the "Roycian Model" or "Royce's Uniform Process". ;)
For example: Suppose the person responsible for prioritizing the product backlog is simply unavailable or unwilling to do so? I've seen CSM-trained leaders respond to that situation in all kinds of "interesting" ways, including doing the prioritization himself or telling the team to do it. When the inevitable crap hits the fan later (when it turns out that what was worked on wasn't what should have been worked on), that same individual may hold the team responsible for the "failure" or blame the Agile process.
Why? Because in a short training session it's impossible for an instructor to understand just what sort of culture currently exists in an organization. That's not what they're there for... they're there to regurgitate material that they either strongly believe in or don't (for some, after all, it's just a job). They might even be interested in offering their services in that capacity, but often the company getting the training didn't realize that they needed to budget for that additional (and non-trivial!) expense.
I spent two years as the Agile Manager while 200+ employees and I underwent the transition to Agile, and I feel fairly confident in saying: it's a much bigger job than a short training course can undertake! There are nuances to it that you can't even imagine as you sit there hearing about how it's all supposed to work according to Scrum doctrine.
For Scrum (or Agile) to work on a large scale, its introduction has to involve more of an acknowledgment of just how much will have to change, how hard it is to make that change, and what you can do to nudge it along. As one person I read recently said in a different context, that's sort of left as "an exercise for the reader." Understanding the Scrum material, at least at a surface level, was trivial within the company that I worked for. Figuring out how to make it work in our dysfunctional organization that preferred lip service to actual commitment was a mammoth job, for which nothing prepared us adequately. That's one of the failings of this whole movement, I think. And it fits within your False Advertisement concept.
I managed to fill two entire books with material on how difficult our move to Agile proved to be, so that says something right there! :-)
Scrum is not turning into a service used by training companies, consultants, etc... And these people are there to make money: "Sure, Scrum will get your project done in 4 weeks, with one lazy programmer working 2 hours a week and we'll teach you how. All we need is your money".
Painting rainbows is a sale tactic, they tell you just what you want to hear, and not what it actually is.
My opinion is if you don't know what Scrum is about then probably you don't need it.
Thanks for commenting on my piece over on Artem's website regarding Scrum Transformations being difficult. I hope you stay tuned for the remaining parts in the series.
I don't agree here with PMhut, we are a Scrum software company and consultancy and I don't see us or our competition making the types of claims you're talking about (scrum is easy, Scrum 1,2,3...).
In fact, check out our blog regarding this here: http://www.danube.com/Scrum_is_Hard_and_Disruptive (note the 2007 date).
If you want a real world example, I would encourage you to read our case study with Intel. In that you'll see how interesting and difficult and regarding a quality transformation can be. Here's the link if you're interested:http://danube.com/docs/case_studies/Intel_case_study.pdf
Ken S has responded to Martins post on Flaccid Scrum. I would encourage to read the response with an open mind. I think both sides have strong value. Here's a link to that response: http://www.scrumalliance.org/resource_download/745
br,
Laszlo S
Absolutely. OJT is the way to go, a lead who can move forward one-in-the-same with a project, team members learn as they go. Technical skills and organizational showstoppers are the only reason a mentor can't move forward and they're both outside the scope of applying any methodology.
> I've watched CSM "graduates" walk out of their course with a nice, handy list of "What To Do As A ScrumMaster" and then demonstrate that they had no idea how to handle the various hurdles that would come their way.
Because the making an end in itself was done. The most competitive methodologies are transparent to the task at hand. There are too many discretionary calls that no methodology can box up and answer for you.