Dirty Rotten ScrumDrels

anna forss 17 minutes later:

• • wonderful. and it goes both ways: if you’re a lazy product owner, your requirements will suck too. And the end result will be the exprected

William Pietri about 1 hour later:

• • Although I agree with everything you say, I think you’re missing the valid point behind some of the recent finger-pointing at Scrum.

  • I agree that it’s possible to do XP badly, like it’s possible to do Scrum badly. But when I talk with teams that are doing XP badly, I have almost always been able to connect their bad outcomes with failure to follow particular XP practices. Whereas when I talk with bad Scrum teams, they are often “doing Scrum” in a way that’s nominally compliant. That makes it very hard to explain to them that they are Doing It Wrong.

  • Although there are definitely plenty of good Scrum practitioners and coaches and trainers, I’m worried that the lucrative CSM industry further perpetuates this problem by allowing people to sell a relatively dilute product as full-strength Agile.

  • Everybody should be responsible, and strive to do a good job. But one of the big lessons I took from XP and its early practitioners was that what I was calling a good job could actually be improved upon wildly. If people adopt Scrum and get a 10% improvement without getting an inkling that 10% is just the beginning, then I think that is a problem with Scrum, not laziness in its adopters.

Kevin Rutherford about 3 hours later:

• • I believe almost everyone does think they’re doing a “good job”, as you put it. The “bad” agile teams I meet don’t know they are “going through the motions”, haven’t heard of technical debt, don’t know their development practices are slowing them down and costing everyone serious money.

  • “Good job” is a judgement term. Can we all please respect the fact that even air-guitar playing Scrum teams have had a go at improving—and let’s instead work out what we can all do better so that the next generation of agile try-outs are more successful?

Rob Bowley about 5 hours later:

• • I don’t think everyone involved in this Scrum bashing/witch hunt is blaming Scrum itself for the problems (although many definitely are), but are uncomfortable with the CSM industry that, lets face it, has the core objective of making money for it’s members. Of course there’s absolutely nothing wrong with people making money, but you can’t expect that it won’t have an impact on what’s being taught.

  • Unfortunately I feel the Scrum Alliance has become a victim of it’s own success and like any organisation that becomes so influential (Microsoft, Google etc) is justifiably up for a lot of criticism as their actions have such a huge impact on our daily lives.

Jeremiah J. Mitchell about 5 hours later:

• • I couldn’t agree more. Those of us who practice Agile need to realize that the blame lies completely in our laps.

Sebastian Kübeck about 7 hours later:

• • After Jeff Sutherland (co-creator of Scrum), you inevitably end up adopting XP practices when you are serous about adopting Scrum in software development. Software development specific parts where removed from Scrum to support other application such as sales and marketing. However, it is way easier to blame the process than to blame oneself. Here are the good news: Those who blame Scrum for their own failing will inevitably fail with any other process. Probably it is even cheaper to fail with Agile than with Waterfall so that is another for proof for Agile’s superiority ;-).

James Shore about 13 hours later:

• • There’s something subtly disrespectful about this essay. I think what bugs me is that you refer to my recent essay (“The Decline and Fall of Agile”, http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html) without linking to it, and then proceed to completely mischaracterize it. You’ve posted an entertaining rant, but I don’t appreciate being the straw man.

  • For what it’s worth, here’s what I actually said: “It’s human nature to only do the stuff that’s familiar and fun, and that’s what has happened with Agile… Scrum makes it worse by ignoring important (but hard) agile engineering practices, and the Scrum Alliance makes it worse still with their armies of trainers-some good, some not-issuing dubious “ScrumMaster” certificates to people who demonstrated competence in connecting butt to chair for two days.”

J. B. Rainsberger about 15 hours later:

• • While this is both characteristically and perhaps unnecessarily harsh…

  • “Scrum is not the problem. Scrum never was the problem. Scrum never will be the problem. The problem, dear craftsmen, is our own laziness.”

  • ...it carries some truth. I find the word “laziness” overly blaming, especially considering that relatively fee agile evangelists are leading a legion of people down a garden path by holding back (or worse, not realizing) what agile demands of us to find success. I’ve been one of those evangelists, so I empathize with them. I used to cause pain and suffering when I espoused practices like TDD as silver bullets. Perhaps this is why I don’t pounce on those who do the same day.

  • Every change agent has an evangelical period. That there are many agile evangelists doing this reflects something good in the agile movement, even if it hurts the movement’s “ratings” in the meantime. People continue to watch, to read, to learn. The ones who hate agile because it didn’t magically solve their problem can only succeed within an overtly Taylorist context. They don’t want what agile offers them. The ones who want to throw off the shackles of Taylorism will seek us out, no matter what the press says.

  • So Jim, while I agree with you about Bob’s subtle disrespect, I have to say that your position is at least as needlessly alarmist as Bob’s is needlessly harsh. And, of course you know that I love you both dearly.

Pete about 15 hours later:

• • • Do a good job.

  • Uncle Bob

    • “And what is good, Phaedrus, and what is not good—need we ask anyone to tell us these things?”

  • Socrates

David Carver about 17 hours later:

• • As has been said, a combination of Scrum for the project management aspect, and XP like portions for the development can make a good agile methodology. I found that XP lacked the Project Management portion, but was strong with the development cycle. Scurm lacked the development rules, but was strong with Project Management. Combining the two makes a good combination.

Justin Knowlden about 17 hours later:

• • Uncle Bob,

  • Couldn’t agree with you more. I have seen on more than one occasion a development team regale in its methodoligical righteousness while being very dysfunctional. This commentary is also a nice tie into your talk on “The Cost of Owning a Mess”. It’s hard to miss the binding argument between the two, Personal Responsibility.

unclebob about 18 hours later:

• • Jim,

  • While it is true that your blog was one of the catalysts for my rant, it was not the only one. The “blame Scrum” attitude has gotten a bit too loud lately. Perhaps I should have linked to your blog, but I didn’t want my rant to be a direct attack on an individual or an article. I was going after the more general sentiment that Scrum needs to be blamed.

  • What are we blaming scrum for? From my vantage point, the agile movement is doing rather nicely, and many teams are making great progress. Companies are adopting agile more than ever, and good work is getting done. So I don’t think we experiencing a decline or a fall.

  • Yes, it’s true that there are some naive or lazy teams who have adopted scrum in a silver bullet way, and have proceeded to make a mess by missing the benefits of the XP engineering practices. But that’s not scrum’s fault, and it’s not the scrum alliance’s fault. It’s the fault of the team, and possibly the coach (if there is one).

  • While I have always been dubious about the value of certification, I have to admit that scrum certification has been an extremely powerful agent for promoting agile in the industry. That certificate seems to motivate people to learn and adopt. I doubt we would have the level of agile adoption we enjoy today were it not for scrum certification. I think more people are practicing XPbecause of scrum certification.

  • So rather than pointing fingers at Scrum, and the Scrum Alliance, I think we should be thanking them for a job well done, and acknowledging that they have worked hard, and that the fruits of that work have been beneficial. We also need to stress, far and wide, that scrum by itself is insufficient, and that the engineering disciplines of XP can help to make up the difference.

Neil about 19 hours later:

• • I have always seen Scrum and XP as being an excellent combination. Scrum requires something like XP, whether this is XP itself, or a set of practices that the team evolves to ensure quality. I do not feel then that Scrum ignores important engineering practices, it is just decoupled from them. It is, if you like, open for extension with the engineering practices of your choice. If these are crappy then you must expect crappy results, if they are quality and agile in nature, then you may get good results if you and your team possess sufficient discipline. I have posted a fuller reaction inspired by this post, James’s post, Jeremy Miller’s recent post, and the general anti-Scrum backlash on my blog just now.

James Shore about 20 hours later:

• • Thanks Bob, Joe. Hugs all around.

  • I agree with the basic premise that if you want excellence, it needs to come from people, not processes. In my essay, I wasn’t trying to blame Scrum so much as observing that it was being misused. (See the section “Scrum, Misapplied.”)

  • Scrum isn’t to blame either—if XP was still the dominant agile methodology, I’m sure we’d be seeing a similar proportion of XP failures. I contend, however (based on what happened when XP /was/ the dominant agile methodology) that when XP fails, people recognize it. Scrum is failing and people aren’t recognizing it.

  • The other thing going on is that Scrum /seems/ much easier to adopt than it actually is, so people are adopting it and then turning it into “what we already do, but faster and sloppier.”

  • Lastly, I agree that certification has certainly launched Agile into prominence. Or has it? The /word/ “Agile” is quite popular. Successful /practice/ of Agile seems to be rare, and if anything, I hear about fewer joyful successes now than I did in 2002. It’s good for us as consultants, and it will probably end up benefiting the industry as a whole (eventually), but seeing all these struggling teams is frustrating.

Daniel Wildt 1 day later:

• • @James: “I agree with the basic premise that if you want excellence, it needs to come from people, not processes.”

  • +1. The process will help in what you need to do. But not how. You need to create tests. How about the test quality? How about test coverage… there you go.

  • And yes, people think that Scrum is too easy, so simple… that’s the problem. It’s simple.

  • Now, how simple it is to change the culture of a team? How about just the culture of one person?

  • @Bob Martin: you are correct when you say “Do a good job. Oh, yeah, and stop blaming everything (and everybody) else for your own laziness”.

  • We cannot blame Agile for failures. Teams were already failing. Agile is just showing where some team is going bad. Now, improve, adapt, change, and try again. Discipline! And action!

Scott Pfister 1 day later:

• • Uncle Bob’s post got me to read James’ post. And after both, I found myself reading all - every one - of the comments. Because there’s so much truth in both, and I think the error in each is actually the same—to seek to find blame. Or, rather, to assume that there is anything at all even blameworthy.

  • One simple fact is that Agile is no longer new. At its onset, it was a set of wonderful, common-sense principles applied in a new way to an industry that had begun to get buried under its own weight. Before Agile - whatever you should choose to call it - the emphasis was on engineering... The cost of defects found “late” in the process… SEI… CMM Level-5… requirements gathering. The Agile Manifesto brought us back to basics, and now it has grown and matured to the point where it is no longer being applied to itself!

  • Is the Agile Manifesto perfect? Is it complete? Or, perhaps, now that we’ve had it around for a while, is it time to have a bit of a retrospective on it? Like Bob, and Micah, and others I am discovering, I find myself sitting squarely in the camp that’s bringing us back to basics once again and focusing on craftsmanship. It’s no longer enough to focus on what we do, but we need to re-emphasize how we do it.

  • Agile struggled to break into the mainstream, and when it started it was novel, and was practiced by those who saw that the future - Uncle Bob, Kent Beck, Ken Schwaber, and the rest - was not documenting, but doing. And so it passed that the world saw that tree-strangling requirements docs were nothelpful and Agile has hit the mainstream. And with it, the mainstream developers and managers who need to be led further down the path. Now it’s the next step where the focus shall be taken beyond doing to doing well. It’s not a return to the beginning, we’ve come a long way. Agile has plunged a knife into the heart of Death-By-Documentation and that mainstream won’t again need to be convinced that the Waterfall is Bad.

  • You can say that Software Craftsmanship is the movement to take over where Agile left off. Or you can say that Agile has evolved, and the 5th principle of “Craftsmanship Over Execution” is the new iteration of Agile. But whatever you do, don’t say that agile is done, or that it’s fallen, or it’s in the past. Agile is alive and well, and is the necessary and fundamental stage for whatever comes next.

Dion Dock 1 day later:

• • So if SCRUM cannot be blamed for a failure, does it also follow that it cannot be credited for a success?

Michael Spayd 3 days later:

• • I have enjoyed this discussion thread, and that on James’ site as well.

  • I approach this from a bit different angle than others: how organizations change. With that bias, I introduce an organization to Scrum first because (in my experience) it is easier for the organization to adopt. Most development teams are not ready to go to XP right off the bat (when they are, more power to them).

  • After we have established an organizational heartbeat (with 2 week sprints), teams have gelled, product owners and stakeholders are thinking in terms of business value, then, many teams are in a position to think about the engineering practices. This is a natural evolution of teams maturing.

  • I have found XP to be a reliable blueprint for creating a high performing software team. If teams don’t move in that direction at this point (whether calling it XP or not), then something is wrong. Maybe I as a coach have not challenged them enough or helped them inspect and adapt to their quality and technical debt issues; perhaps managment is uninterested and has moved on from Agile adoption; sometimes the team is merely complacent.

  • I honestly think the natural order of things is to evolve from a Scrum-like framework to an XP-like set of practices. Deviations from this path, while common, are just that…deviations, because something is off in the system.

  • BTW, I don’t think the Agile movement is anywhere near in decline…just going through a difficult evolutionary/consolidation stage.

Steve Freeman 3 days later:

• • Agile is following the usual pattern of all technological change. If the OO revolution had really happened, then we wouldn’t need “Clean Code”. In the end, most teams will be a little better than before, a few will really fly, and quite a few will be a confused disaster.

  • As for us, we have responsibilities but we also have limits. We don’t control everything in the world (well, I don’t). Scrum’s apparent simplicity appeals to people desperate to get their organisation under control, who don’t understand how to make code happen. They roll out the training and declare “Job done”—and some consultancy will have accepted the money to do that. In the aftermath, I’ve seen teams wrecked by hit-and-run training, the ceremonies without meaning, who would have done better by having the time to read and discuss a few books.

Michael Feathers 3 days later:

• • I half agree with Bob when he points the finger back at ourselves. There’s a lot to be said for individual responsibility, and I don’t think enough has been said about it. But, on the other hand, it definitely isn’t the only thing.

  • In politics, there are people who believe that society can be changed by changing individual conduct and there are people who believe that by changing the structures of society, we achieve changes in individual behavior. I think they are both right, and the art of change is figuring out what to do when in every different circumstance when working with a team. Sometimes, you need to get people to step up and sometimes you need to help them to change the structure. Neither view is right. Both of them are just tools.. approaches.

Mike Dwyer 3 days later:

• • You don’t understand Bob. The man said this suit of Agile and Scrum clothes would instantly make me be cool, have lots of money, and most of all make me free of any obligations to ‘da man’.

unclebob 3 days later:

• • Yeah, Mike, I’ve heard about that. If you adopt scrum you won’t have to worry about putting gas in your car, or paying your mortgage. If you help scrum, scrum will help you.

Diana Larsen 4 days later:

• • “A manager of people needs…to understand that the performance of anyone is governed largely by the system that he works in – the responsibility of management.” W. Edwards Deming.

  • The fault may not lie with Scrum or XP or the practitioners/proponents/evangelists of either. When will we get to examining how the organizational systems influence behavior? If developers don’t improve their skills, it may also be that there are active disincentives for doing so.

  • Today, the McKinsey Quarterly published an article which states, “Employees can’t change if their managers don’t. Lean leaders act as role models for the mindsets and behaviors they wish to instill in their teams.”

  • Hey, I know, let’s don’t blame methods or ourselves. Let’s blame the managers! As long as we’re blaming.

  • Oh wait, Agile hasn’t really talked to the managers much about their role in this whole magillah, have we? Systems thinking, that’s the ticket.

Justice~! 5 days later:

• • I think Diana keys on one thing I’ve observed a lot of in our industry – Agile itself, nor Scrum, nor anything else, can solve a pandemic where people don’t want to be accountable or in fact are very comfortable in “the old ways of doing things”. And I’m not talking about devs here. It’s very easy to hide behind waterfall or CMMI levels if you don’t want to be accountable, and that’s a culture that doesn’t just pervade dev.

  • I’m not trying to blame managers for poor dev practices by any stretch of the imagination, the industry is built on the backs of poor schlubs from IT schools given nominal at best training and then foisted off into the workplace. However, I have found from experience that often times having a dev team that doesn’t have a clue often shields us from the rest of the corporate culture that put the clueless dev team in there in the first place.

Abe 5 days later:

• • In Ken Schwaber’s Google Video “Scrum et al” he mentioned that you can be doing Scrum, but if you have a bad team then you’ll consistently produce bad software every 30 days.

  • When there is a 25-to-1 differential between the best people and worst people, and a 4-to-1 differential between the best and worst teams, you need assess your Peopleware before you decide to adopt any framework/methodology.

  • The sad fact is that most IT Managers are there due to the “Peter Principle”, leaving little or no chance of hiring people who are “Smart and Get Things Done”!

Tom Mellor 6 days later:

• • I responded to Jim Shore’s post earlier on his site. I am a Scrum Trainer and train CSM inside my company – a very large company. I teach that Scrum is only part of a solution; a good (agile) work organization approach (Scrum) is meaningless without the use of good engineering practices. They are are symbiotic and most certainly not mutually exclusive.

  • As for “butts in seats”: what people get out of CSM training is a product of what they invest in it through their time and attention (not money.) But I can say that, as Bob alludes to, we have seen significant increase in satisfaction of our customers and workers – almost all of whom are used to waterfall. We are not married to Scrum; learning its principles, practices, values, etc. has caused us to think differently and choose options along a continuum of approaches.

  • Diana was correct about managers which is why I strongly recommend “Leading Self-Directed Work Teams” by Kimball Fisher to my students. Management has to appreciate, understand, and embrace this different model of leadership if we are to benefit from this difference from the traditional model. Toyota lives it and they are an example of how it works.

  • Scrum intentionally makes no presumption about engineering – as Ken has said “If you have crappy engineers and crappy engineering practices, you’ll like produce crappy code.” Scrum is about organizing and delivering the work in an iterative, incremental manner – not in opposition to XP, but complimentary to it. The two can easily co-exist and combined can prove a potent approach.

  • Bob made the most profound point: “So rather than pointing fingers at Scrum, and the Scrum Alliance, I think we should be thanking them for a job well done, and acknowledging that they have worked hard, and that the fruits of that work have been beneficial.”...and let’s work together to improve in the kaizen way. We don’t need hugs, though those are nice; we to constructively offer ways to improve agile and help people do it as best as possible.

Paul Beckford 6 days later:

• • Hi Guys,

  • We need to be careful how we use language here. Agile is not Scrum or XP for that matter. These are just labels for branded methodologies/practices. Infact Agile itself is just a label. What we all care about is the “thing”.

  • The thing is multi-faceted, and is embodied in people who share certain values and principles which they apply to their working lives. Those of us who get it and are part of this culture know the thing when we see it, and we also recognise when “labels” are being misapplied.

  • Here is a quote that I think is relevant here:

  • “The Map is not the territory, the label is not the thing.”

  • S. I. Hayakawa, Language in Thought and Action

  • Agile, Scrum, XP have been successful labels as far as marketing is concerned, but they are not the thing. Infact I for one wished these labels would go away so that we can focus on the thing, but alas marketing seems to be a necessary evil.

  • I come form a TQM background and I have seen this all before. The Japanese have an approach to learning which they call Shu-Ha-Ri. In the 80’s and 90’s western companies decided to try and adopt the management philosophies of the Japanese. The problem was though is that they didn’t understand Shu-Ha-Ri and focused on buying Labels like TQM, Six Sigma, etc instead. The result is they didn’t grasp the thing, TQM went through the Gartner adoption curve like everything else and we moved on to the next buzz. I think it was “downsizing” or was it “right sizing”? I can’t remember.

  • The Japanese think that us in the west will never “get it”.

  • We will win and you will lose. You cannot do anything because your failure is an internal disease. Your companies are based on Taylor’s principles. Worse, your heads are Taylorized too. You firmly believe that sound management means executives on the one side and workers on the other, on the one side men who think and on the other side men who only work.”

  • Konusuke Matsushita – Panasonic

  • Maybe their right?

  • Another quote:

  • “Money is the route of all evil.”

  • Anonymous, The Bible.

  • Paul.

Peter Hundermark 6 days later:

• • Ron Jeffries, one of my heroes in the world of software development, has said; “My advice is to do it by the book, get good at the practices, then do as you will. Many people want to skip to step three. How do they know?” Quite in keeping with Shu Ha Ri, I think.

  • As many have already stated Scrum, XP and Agile are not the problem. Our individual weaknesses and failure each day to do what is right as opposed to what is easy condemns us to mediocrity. Our courage and willingness to try and to fail and then to get up and try again is what is needed for continuous improvement.

  • @Paul: Your biblical quote is incorrect. The correct version is “For the love of money is a root of all kinds of evil.” 1 Timothy 6:10 (New International Version).

  • Peter

Gabrielle Benefield 6 days later:

• • When I first read Jim’s blog I was a little shocked. Jim for me stood in the camp of being a practical Agilista – the group that really understood how to help people solve issues at many levels from team, system, technical etc. The term of “War” was also a surprise as I had trouble tying in “War” and “Jim Shore” (nice though they rhyme). Instead of a community of like minded people trying to improve the lot of teams we were at war with “One methodology to rule them all”.

  • I’m a practical Agilista. My aim is to help people with their challenges of creating great products and having fun while they do it. I am a Scrum trainer but started with XP, Scrum and Lean at the same time and blended them as a recipe for good results. I’ve been bought into XP teams who aren’t seeing results as they build good quality code fast, but they aren’t necessarily heading in the right direction with their product. In essence they are building more waste, even if it’s good quality waste. I’ve seen Scrum teams not adopt the engineering practices amongst others (the “Scrum but…” approach), I’ve seen so called “lean” teams take some Japanese words, put up a kanban board for the developers and run waterfall for everyone else.

  • What happened to creating a learning organization with the relentless pursuit of perfection? It is hard. Two days of any training won’t make you Agile, reading a book won’t make you agile, having a coach onsite won’t make you Agile…alone. It does take more, but like anything people need to start somewhere. Rather than looking at the negative side and what’s missing, how about reaching out and working together. Here is a novel idea. Could XP’ers who believe the Scrummers are missing something and vice versa help each other out? Instead of worrying that the other methodologists (or is it Methodists?) are the competition, go out and help organizations do better with their implementations, and build on success so that it increases the pie rather than scrapping about who owns the pie or gets to eat the biggest piece.

  • I’m now glad that Jim and Bob have posted their blogs this week. We talk about visibility a lot so it’s nice to see we are tackling these issues. The Agile community is going through its storming phase and it’s still a new community under its current identification so this is all natural. Thanks, you both made me think more this week.

David James 20 days later:

• • I fear that Mr. Panasonic’s assessment may be too close to the truth, that management in the west may be based on power instead of responsibility (I think, you do).

  • At my current job we recently had a management change. My previous manager was constantly controlling but never in control. It was the worst for me. However, the new manager, on our first meeting together (after I had suggested a plan of attack for part of our application) said, “hey, sounds great, why don’t you just run with it”. Wow! Management based on empowerment. What a difference. But not just for me (happier, more productive, employee of the month!) but for the whole company. People are interacting, talking, thinking and moving forward together.

  • This is what Scrum introduces and succeeds with: empowered teams based on trusted and motivated individuals. Conversely, the failure of Scrum (at least from my experience) is the failure of management and employees to be rid of their comfort zones (the thinking and the doing zones, respectively).

Jurgen Appelo 3 months later:

• • I wrote my own reply to all agilists who are preaching that certain agile practices are required to be called ‘agile’:

  • The Decline and Fall of Agilists http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html