Scrum is a Diet, Kanban is a Mirror

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

Roy vandeWater: I’m Roy vandeWater.

Derek Neighbors: I’m Derek Neighbors.

Agile Frameworks Mainstream

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 Developer 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?

Scrum Master Christmas Gifts

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.

Too Experienced For Scrum Master

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 chicken 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.

ScrummerFall

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.

Three Types of Scrum Teams

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.”

Scrum vs Kanban

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 hear the sirens but he didn’t want to be lured in to the sirens. He asked the captain, the crew on the boat to actually tie him down to the mast of the boat so that he couldn’t get out.

The theory there is that it’s a commitment post. All the time in life we use commitment post that say we’re going to put something. If I’m losing weight maybe I say, “I’m not going to let any junk food in the house.” Maybe I say that “I’m not going to go to these types of restaurants,” because I know that there’s a weakness there and so I’m going to commit myself to not being tempted by that.

At times some of what we do in Scrum would be a kin to that. I don’t know if a commitment post is necessarily a bad thing. If you rely on it long term it’s probably not real healthy. I would pose it, a mirror doesn’t tell you a whole lot in the weight aspect of “OK, maybe I see myself getting fatter.” If I have no clue on how to lose weight, a mirror doesn’t do shit for me.

Whereas if I have guide post that say like, “Hey, here are some rules. Don’t consume more than 1,200 calories a day. Don’t eat after…,” whatever those commitment posts are. I rely on them and I start to lose weight now maybe the mirror becomes a better tool for me to say, “Hey, I see myself bulging back up again. Now I know maybe I need to go back to those commitment posts.”

So I think doing it the opposite way is just a much longer more painful way of doing things.

When To Use Agile Methodologies

Clayton: I think this is a funny little anecdote that cuts both ways. I can imagine lots of different ways that I could probably stand in front of the mirror and make myself look different. You still have to perceive it somehow.

This is kind of an open ended question, and it links to somewhere. The question is, when do you use Agile methodologies and techniques like Scrum? I think a lot of organizations may be going back to the trends of 2011.

A lot of them say, “We have a supper project, and Agile is going to make us go faster, so we’re going to use that.” What are some ways that may be a better way we can think about when should I apply some of these methodologies, and maybe when should I not?

Roy: That’s a tough one to give a blanket answer for.

Clayton: It depends?

Roy: I think some examples of situations in which you can use an Agile methodology like Scrum or Lean but it becomes very difficult is when you get into areas where there are strict compliance regulations, like if you’re trying to do HIPAA compliance, or if you’re trying to do FDA ones or anything like that.

Then it gets very difficult because a lot of times those compliance regulations require a lot of up‑front documentation and you have to get that approved or they could potentially turn it down. If you’re doing that as you go, you might end up wasting a lot investment money producing a product that gets turned down by the FDA when you could have caught that at the documentation stage.

Derek: For me, I would say Agile methodologies could be used any time you’ve got a team of two or more people. They’re really principles and values for how you work with other human beings. I think that’s vital regardless of what type of work you’re doing.

As far as an implementation, i.e. Scrum, or Kanban, or et cetera, I think that’s really going to depend on what kind of product you’re trying to deliver, what kind of project it is, and what things are important for success in that. I think the core methodologies apply to any kind of team.

Currently today we’re doing it inside of school districts. We’re not doing Scrum, but we’re applying a lot of these self organization techniques, and really even pushing it down to empower the students in the classroom to do retrospectives with their teachers and get them more involved. I think the principles go pretty much anywhere you’ve got groups of people.

Scrum Promoting Generalists Instead of Specialists

Clayton: This next one is a good Scrum question, there’s actually two things inside. It says, “Am I nuts to invest in specialization where I get the idea that Scrum is generalizing the team?” Two things. Is Scrum really generalizing the team? And then assuming it is, should you invest in specializing in some certain thing?

Roy: I personally am of the opinion that a jack of all trades is more valuable in the long term than a specialized individual. I’m also of the opinion that a specialized individual could be dangerous to your organization.

If you’ve got the one guy in there who knows how to do any particular task, let’s say he’s a DBA, or he’s the only guy that knows how to do the build, that means that you now have a bottleneck. First off, your organization doesn’t pass the “hit by a bus” test. The guy could be a total dick and you’d have to keep him around just because he’s the only one who knows how to do that, or he could demand whatever salary.

I think that ideally you have a team in which everybody is able from every task. It’s OK that no one of them is able to do it as well as a specialist would be able to. I think the trade off that you get there where you get a huge increase in flexibility is more than worth it.

Derek: For me, the big thing here is I’ve been in technology long enough to see how fast it moves. The people that were highly specialized 10 years ago, maybe I’m a Java programmer or a Delphi programmer, I’m a client side programmer. I’m demanding top dollar. I’m totally on top of event driven window programming. I’m the crap. In two or three years it switches to all web platforms, and web platforms now are pushing weave ins, and SQL databases away.

The problem is, if your career is going to be 30 or 40 years long and you’re in technology, you’re going to have to relearn a specialization every three to eight years if you want to stay gainfully employed, doing interesting work. Be fairly general, but if there’s something you like, maybe deep dive a little bit into it, but I wouldn’t get so myopic as to be totally specialized.

Clayton: I don’t think that there’s anything wrong with having some people on a team that maybe know more about something or may be more of a specialist, as long as there’s some kind of overlap, and you stick to the idea that the team is cross functional.

Roy: I think ideally you get a bunch of team members who are passionate about different things and will take the time to go out and learn it. We’ve got Drew on our team who is extremely passionate about JavaScript, and Clayton, you are very passionate about testing.

That ends up benefiting the team, not because you guys create information silos and lynchpin yourself in, but because you take every opportunity to teach us about the stuff that you guys know so that you’re able to spread that knowledge.

Story Points As A Proxy For Time

Clayton: This next tweet, it’s a good one. It says, “I have never met a proponent of story points that hasn’t ultimately described them as a proxy for time.”

Derek: This person has never met me.

Clayton: Do tell, Derek.

Derek: To me, it’s all about sizing, and I don’t think that really has to do with time. I think it much more has to do with effort. I guess at the end the goal is to take velocity and be able to say, “Do predictions.” Those predictions generally have to do with time, but I would not be a proponent of saying, when I’m explaining what story points are to somebody, that we use those to translate to time.

I never say, “Three story points translates to X number of hours.” You can make some assumptions about that and say, “Based on prior performance we might guess that that’s the case.” But to me it’s really a matter of what are they in relation to each other, i.e. story points are only relevant to other story points, not necessarily to time.

Roy: I think I’ve seen some great examples of this in action where we estimated a project at a specific number of points. We pulled in a bunch of stories that were relatively easy, they were twos or threes. We worked on them throughout the week and realized that what the product owner had intended for those was way more complex than what we thought.

We felt that those twos and threes should have actually been fives and eights. Then the following week we got into the fives and eights and those ended up being twice as complex as we thought too. Even though it was twice as hard as we thought and we felt we should double the points, it was actually fairly accurate. It just shifted everything up because everything was twice as hard as we had originally thought.

Derek: I think that’s the best way to explain it, Roy. That is that if you’re really doing things relative to each other, if you find out that a three takes you a lot longer than you originally expected, you don’t have to go back and re‑estimate everything.

If your stories were actually relatively sized it’s going to come out in the wash in that you’re going to be able to recalculate your velocity based on the level of difficulty being different.

I think that where people get hung up on is they try to say it’s a time based thing. The whole reason you use points is because they’re not time. If we estimated everything as ten hours, and then we found out it really took 40 hours we’re going to have to go back and readjust all of our estimates.

If we did it as a three and a five and we found out a three took 10 hours, and maybe in our original velocity estimates it would have calculated out to three hours, we don’t have to go back and re‑estimate everything, we just have to adjust our velocity, and that’s going to shift time.

Clayton: I think we see this a lot because the team will estimate something using story points and it works itself into velocity, and then everybody comes to that conclusion because ultimately they say, “We did a 20 point iteration and it took us, say our iteration is two weeks. So that means that 20 points equals two weeks.”

I think that everybody consciously or subconsciously makes that assessment. Then the people that maybe abuse the system want to try and extrapolate that out, and say, “OK, well that means that, when are you going to be done? That means that that many points takes that long and this story estimate point five takes two days and one takes half a day, or whatever you want to do.”

It seems like everyone tries to go down that road but I don’t think that’s the fault of story points.

Derek: So going to our earlier conversation, if you have a mirror you don’t need to own a scale.

Clayton: [laughs]

Roy: In the past, we’ve had some discussions, internal at Integrum, where we were talking about the idea of relative complexity versus relative time. The example I think we used at the time was, it takes me a few minutes to walk across the street, it takes me an hour to walk to work. But they are about equally complex. So when you are estimating those, would you rate those both the same points or would one be significantly more than the other?

Derek: No, they would be significantly more than the other because it’s amount of effort.

Roy: So you would say that it is amount of relative effort as opposed to relative complexity?

Derek: Right. I would say it is a combination of those two things.

Clayton: All right, well that does it for the tweeters for this time, so thank you guys.