This’ll be short. This’ll be a rant. Here goes… I’ve taught three scrum classes in the past two weeks, and I get a lot of questions like “…but, scrum says we’re supposed to produce releasable product every sprint, and that’s too hard – so we can’t use scrum, right?” or “scrum says we’ve got everybody we need on our team, but we’ve only got one tech writer, so we can’t use scrum, right?”
WRONG! The essense of agility is reacting to the reality that is right in front of you, and scrum is just a management framework for doing that. I know that every process is a crutch that takes care of the easy stuff for you, but that does not give you license to give up thinking altogether, does it? Sorry, rhetorical question… what I meant to say was “this does not give you a license to be stupid on purpose.” And, when you know something is not going to work for you, and you do it anyway, that is being stupid on purpose. Don’t do that!
Just do the best you can. Your reality is seldom the reality you want – deal with it, improve it, and get on with things. Just keep moving…
Ok, I’m getting calm now… backing away from the keyboard… talk to you later…
Dan 😉
Dan Rawsthorne
dan@danube.com
Finding The Best People For Agile Teams 
February 24, 2007 at 11:59 pm
I hate to open up excuses for the pessimists we should be challenging to think a different way. Scrum doesn’t say “releasable” product every sprint, it says “potentially shippable.” Potentially-shippable means shippable within one additional stabilization sprint if the Product Owner feels it has enough features to warrant releasing.
Teams *can* produce potentially-shippable product increments each Sprint — I’ve seen it happen when people changed their thinking and skills on this. It does mean building thinner vertical slices than most people have imagined in the past.
People who sit in class and say Scrum looks too hard should have their belief systems challenged, not appeased. They should at least shoot for demonstrable results each Sprint, dedicated cross-functional teams, etc. In trying, they will discover what their *real* strengths and organizational impediments are instead of the ones that seem so real in their imaginations.
–mj
February 25, 2007 at 6:20 am
Michael, I agree with you, but that’s not the point. The point is that people are looking for excuses to fail, and I’m not going to give them any. When they are afraid of something, they often set up strawmen like these in order to have such excuses. I say, “go ahead, be afraid, but at least do something…”
Now, we could argue all day about what scrum actually says (and some of us have :)), but my point is that every team should do the best it can, build as complete a product as it can, and improve themselves over time. If their definition of “the best they can” doesn’t satisfy us, if we know they could do better, we should say so. But, we shouldn’t let this stand in the way of them getting moving.
At the extreme end (to start the next argument) we have teams that leave something important out, like testing or documentation. We wouldn’t like this, and would suggest that they not do this, but that’s what they are doing… it is what it is.
At least they’re moving. They’ll figure out what they are missing through their retrospectives, and they’ll adapt and improve. They were being stupid, but at least they were being stupid by accident (we hope).
– Dan 😉
February 25, 2007 at 11:11 am
Kennedy said “We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.”
The key phrase is “not because they are easy, but because they are hard.” Saying “just do the best you can” sounds too much like “keep doing what you’ve been doing and call it ‘Scrum.'” I’d rather open minds to new possibilities than succumb to Stockholm syndrome.
Everything about Scrum will look “stupid on purpose” to someone who hasn’t tried it yet, or else they’d be doing it already. A micromanager I recently met thought it was stupid to stop “helping” his team. An engineer with control issues refused to collaborate on the build script — he actually used the phrase “stupid on purpose” about our team’s pair programming agreement. A client you and I both work with has barely mustered one release per year while we both know they’re capable of three releases in 2007.
When I was a traditional software architect, Kent Beck’s continuous design ideas struck me as reckless, and it was too long before anyone challenged me to try them. That’s why I feel it’s our job to challenge people to try Scrum practices that are counterintuitive at first, but turn out to work. Not because they’re easy, because they’re hard.
–mj
February 25, 2007 at 11:47 am
This has always been our fundamental distinction – you and I. YOu want to do it right out of the blocks, even if it’s painful; I want to just get moving and improve as I go.
But, you’re right. If you want to define everything you don’t want to do as “stupid on purpose”, then that is “stupid on purpose”. Slippery slope time. Some people just insist on failing, and ignoring the lessons of others, once you know them, is a telling symptom.
And, it is our job to challenge people, and tell them what is right, or better. If they don’t do it, then they are being stupid on purpose, by our definition. If they deliver product by going against our guidance, then they were not so stupid, eh?
Remember, it’s always the team’s process that counts. We sometimes have to lead the horse to water, and watch it drown. We then rescue them, tell them something else to try, and watch them drown again. At some point they may just give up and do it the “right way” – but it must be their choice. Until they do, that’s being stupid on purpose.
Dan 😉
February 25, 2007 at 1:37 pm
Well, I agree it’s important to show early successes. And I have seen teams that felt bad about not building a tested/integrated product increment their first Sprint because they took on too big stories, or “epics.”
Many people just starting Scrum have a huge legacy code debt ( http://danube.com/blog/michaeljames/how_to_survive_technical_debt ), or they’re short on the skills unique to Agile development (TDD, Continuous Integration, leaving your job title at the door of the team room ….). In addition, if they’re a new team, they may not even have their tools set up yet.
So the question is how to downshift so everyone doesn’t just feel frustrated.
I just got back from the gym. If I discover a weight is too hard to lift properly, my options are to use sloppy form (omit testing, refactoring, pair programming, etc.), or reduce the weight (split the story) and use correct form.
The Scrum approach is to cut the work thinner *vertically* instead of horizontally, i.e. resorting to phasewise development or handoffs to other departments. Deliver a smaller sliver of a feature done right.
–mj
February 26, 2007 at 10:07 am
I think I understand the distinction being made here:
Dan – you’re saying that if you make any incremental improvement with a customer, that’s better than nothing.
Michael – you’re saying that we should teach people the right way to do Scrum else they’ll never learn because we’ve given them an “out” to bend the rules.
Here’s how I see it:
– If we’re doing a CSM class for a company, then we should teach them Scrum principles through and through (the mechanics may change from the book per collective experience). It’s a CSM course after all and by giving work-arounds that bend the rules, they are in effect not learning what Scrum actually is about–the point of the certification.
– If we’re going on site to do some consulting (not a CSM course), then we have more liberty to make improvements by any means necessary.
Personally my preference is to stick to the principles and get them to change their bad habits rather than enabling them to continue to make the same mistakes over and over. But that’s just a difference in philosophy. Here’s the underlying question: is the customer paying me to help them change their organization toward Scrum, or just do something to show some improvement above current levels.
August 9, 2008 at 9:21 pm
“Reality”,
Sorry to hear you’re having a hard time doing Scrum. The forced reality check of building a potentially-shippable product increment within a timebox of 30 days or less certainly does suck for people or organizations with severe impediments. Consider the possibility your team or your engineering practices suck.
What would you prefer to do? Waterfall? RUP? Anarchy?
–mj
September 22, 2008 at 10:31 am
Well, Reality, if this stuff isn’t working for you, don’t do it! That’s the point of this blog – don’t be stupid on purpose.
Of course, you have missed the whole point of scrum. It isn’t a methodology (you got that right), it isn’t about the task board, it isn’t about the daily meeting – it is about facing your realities and dealing with them, and getting better as a team. That’s it. That’s all. That’s enough!
Dan 😉
dan@danube.com