Scrum is a Diet, Kanban is a Mirror

Episode 43

January 18, 2012

19:51

TBD

tbd

The Agile Weekly Crew discuss controversial topics found on Twitter.

Episode Notes

Clayton Lengel-Zigich, Roy van de Water and Derek Neighbors take to the twitters to find controversial topics to talk about.

Kanban, Agile, Scrum are among top trends of 2011

What do you get a ScrumMaster for Christmas?

Getting turned down for a ScrumMaster role because you are too experienced

Water-Scrum-Fall and ScrumerFall

Scrum is a diet, Kanban is a Mirror

When do you use Agile Methodologies and Techniques like Scrum

Is it nuts to invest in specialization when Scrum is generalizing the team

Are story points a proxy for time?

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the ScrumCast. I’m Clayton Lengel‑Zigich.

Roy van de Water:  I’m Roy van de Water.

Derek Neighbors:  I’m Derek Neighbors.

Clayton:  Today we are going to the Twitters. We looked up some tweets using the Scrum hashtag. We’re going to just go through those and rapid‑fire talk about them.

The first one, this one is the San Diego Times, perhaps, the SD Times who ranks Kanban, Lean, Agile, Scrum among top trends of 2011. What do you guys think? Are these trends fads? Are they just becoming popular? Maybe they are making some mainstream media concept. What do you think?

Derek:  I believe the SD, Software Development Times.

Clayton:  Oh, that makes a lot more sense, though.

Derek:  Yes, I think in some ways they are trends in the sense of…these stuff that’s up‑and‑coming, will they last? I think that the Agile principles and the values are fairly timeless. I think the process implementations, if they’re truly Agile, people are going to inspect and adapt on them over time; which means that they will be different, and we will probably discover new ones as well.

Roy:  I think too, that lately I’ve seen a lot of companies that are saying that they want to be more Agile, or want to implement Scrum or LEAN or whatever. I think that a lot of them are just saying that, based out of articles they’ve read, or people they’ve talked to, and don’t really understand what it’s going to take.

Oftentimes, it’s going to take some sacrifice from themselves and from the organization in order to reach that end goal. Once they find out that that’s part of the process, they’re going to be disenchanted with the concept.

Derek:  Kind of like I really want to lose another 50 pounds but I don’t want to stop eating donuts?

Roy:  Sure. That would be a good way to put it.

Clayton:  It seems like with any software development stuff, there’s always going to be trends and waves of popularity. But it seems like some of the stuff has been getting a little more mainstream. But it definitely feels kind of faddy, in some degree. But I think you’re right, the Agile values and principles, that stuff will be pretty timeless, I think.

Next up, here’s kind of a fun question. What do you get a Scrum Master for Christmas?

Roy:  A box of index cards?

Derek:  I think you’ve got to practical joke them in some way or another, just not having enough fun. I’d fill their cubicle, if you have cubicles, up with popcorn and peanuts or something. Short sheet them, move their desk into a bathroom, something interesting.

Roy:  For a while, we were actually collecting our used index cards. Once the sprint was over, we’d collect our index cards and throw them in a box. It’d be great to save up a year supply of those and fill this cubicle with them.

Derek:  Perfect.

Clayton:  Or if they have a sunroof you could pour them in their car, that might be a little more fun. There’s a tweet about someone got turned down for a Scrum master role because they were too experienced. How do you become too experienced as a Scrum master?

Roy:  I think that it sounds to me like what happened was they didn’t want to hire him for some other reason and they were too much of a pussy to say what the real reason was, so they told him he was overqualified for the position.

Clayton:  They got that “You’re too experienced” answer?

Roy:  Right.

Derek:  Yeah. I think most companies that do that for a position, what they’re really saying is your salary range is beyond the scope of what we’re willing to pay. Therefore it’s easier to say, “You are too qualified for us” than it is to say “You are too expensive for us,” because one makes you sound good and the other one makes us sound cheap.

Clayton:  Yeah. I wondered about, I think a lot of companies have a hard time defining exactly what the Scrum master is supposed to do. I would be pretty impressed if there is a company that had a formula, so narrow down they’d be able to tell if you’re overqualified or not.

There’s an article that came out and this tweet references it, but it’s about the concept after some time has gone by, most of the agile “projects” are really, the author described them as water Scrum fall. There’s some kind of waterfall implementation of requirements gathering and figuring what it is.

Then the work itself is done additively and then there’s some kind of release process that still waterfall it. What do you guys think of the Scrum or fall stuff? Is that real, does that exist?

Derek:  I think it depends on how you really define it. I think in one respect I think that most Scrum is mini waterfall in the sense of you’re doing all of the cycles within an iteration.

You’re only doing enough design, only doing enough architecture, only doing enough requirements definition at the beginning of a sprint planning meeting to last for a sprint. Therefore could you say that because you do that every single time that these aren’t falling to waterfall category.

I think the determination for me is the actual process is a little bit different. You’re not saying “We’re spending one day doing requirements definition, we’re spending one day doing development design. One day doing development, one day doing testing and one day doing releasing and that’s a sprint,” or something thereof.

I think design and architecture and things evolve over time within a sprint. I don’t think things are set. I can certainly see how people say. You’re doing all these activities in a pressed time period, but in reality you’re still doing them sequentially, meaning I don’t think we could ever do a Scrum where we say, “Hey, we’re going to jump in and we’re going to start testing before there’s code and before there’s actual, the entire stack of the code.”

I definitely think we can jump in and say “We don’t even know what the story is but we’re writing code.” That would be irresponsible.

Roy:  I think the article that linked, as well mentioned a second article that talks about there are three types of Scrum teams. Ones that don’t practice Scrum at all, just say that they do. Ones that practice Scrum to the book and a third team that does Scrum, but they make a lot of concessions due to their corporate structure or whatever other factors in a place like the traditional Scrum buts.

The main article that we’re talking about suggest that that approach of doing strict Scrum but them making the concessions where needed might be the most pragmatic approach. Because it’s the easiest to implement and it’s less painful.

Looking at that as pragmatic might be a mistake because if you’re doing that you might be ignoring the problems within your organization that strict Scrum is trying to uncover and that you’re avoiding those problems in the name of pragmatism.

Derek:  Yeah. I definitely think it’s the pragmatic approach in the sense of, the most being for the buck right off the bat. The problem you have is this is where we see the curves that say, your implementations going whether you have a code, you don’t have a code. Your performance going up and then it plateaus and the will drop back down and the will plateau and drop and never gets as high as that or first initial piece.

I think that’s because people do make all the concessions. It’s the race to implementations i.e. we know we’re going to do shorter races, we’re going to do some things. We’re making a lot of tradeoffs to get that to happen.

What they do is they never deal with the real problems. And so what happens is after the newness of this new process wears off people fall even further back in to the bad way of doing things and performance drops again. Then it’s “OK, let’s get serious about Scrum again or Agile again” or “Let’s switch to Kanban,” whatever the motivator is and then you see an uptake again until that pain reaches.

If they’re going to be pragmatic about it when they get to the plateau stage they have to start to say, “OK, now we’re going to start removing the “but” parts. We’re going to start saying how do we get to the real implementation and deal with what it exposes.”

Clayton:  The next tweet goes towards some of the Scrum versus Kanban stuff, but it says Scrum as a diet, Kanban as a mirror. This is getting at the Scrum, makes you or suggests that you make some changes to your process where Kanban has got it more, let’s visualize what you’re already doing.

This is an interesting anecdote. It’s a great tweet because it’s link BD, it’s been re‑tweeted a few times here. I will say there’s probably a lot of overweight people who have mirrors in their house, but that doesn’t seem to help much. I don’t know what that says about this.

Derek:  I saw an excellent Ted talk in the last few days that talks about some methodology about a sailor going through where the sirens are located. He wanted to h