이 에피소드에 관해
Clayton Lengel-Zigich, Derek Neighbors and Jade Meskill talk about a blog post from Liz Keogh called Step Away From the Tools.
What does it mean to do BDD?
Agile as the Hope killer, the tools give you hope
Diving In vs Deliberate Discovery
Are we too focused on tools instead of the reason’s they exist?
Tactile Tools and their benefits over Digital in the Process
Tools as a blame catcher
Assuming you’re wrong
Transcript
Derek Neighbors: Welcome to another episode of “The ScrumCast.” I’m Derek Neighbors.
Jade Meskill: I’m Jade Meskill.
Clayton Lengel‑Zigich: And I’m Clayton Lengel‑Zigich.
Derek: Clayton, earlier this week you had posted on a blog post, about “Step Away From The Tools.” We gonna started a couple of discussions and came find around here. Maybe it’ll give us a little bit of background, the post, the reason why you post it and can’t find…some of the discussion around that.
Clayton: Yes, the headline was grabbing, kind of inner results to separate from the tools linking, frustrating this industry. It’s so cut‑up and their tools, stupid little things. That was just interesting…I clicked on it.
It was interesting to me because, I’ve been lot of thinking lately about the way they we did BBD. What is the meaning of BBD and all those things. I think for a long time Cucumber came along and the rails community and it was, “You can do BDD if you use Cucumber” and “OK that’s great.” Then things like Webrat and Capybara came out and it was like, “Look at our cool web steps where you can fill out this form.”
In her post she makes reference to a post by Dan North about understanding the domain language and how it’s pretty easy to write, you could write a test that seems like you’re doing BDD but you’re really not and it should be at a higher level and substance, just been interesting me lately. That’s why it stuck and there had been a few people on the team I’ve been talking about that whole concept with. That would be fun to share with everyone.
Derek: Yeah, I thought it was interesting because one of the things that I picked up from Liz last time she was out here that I really liked was that Agile is the hope killer and hope is what basically prevents projects from shipping on time.
I think that sometimes when we get too focused on tools, the problem that tools are like hope. If I only use this Cucumber thing or I only do BDD using these tools then I’m just going to develop better software. The hope is that as long as you’re writing scenarios that you’re writing good software.
I definitely agree that Dan’s focused discovery or deliberate discovery is…most of software development is about having conversations about what software to actually develop. As developers we like to dive right into the meat and say, “Let me code. Get out of my way and let me code. Just tell me enough information to let me start writing the first line of code and get out of the way and let me do it.”
In reality that’s where all the problems start coming in, whereas we do some of that discovery of “Oh, you mean there’s just other role that doesn’t have access to this and this and this is how it works?”
When we find those things out four weeks into after a feature’s been flipped and then we have to basically un‑plumb everything and add something new, this is where defects get out of control and we just get this kind of crazy, spaghetti mess by not really listening. I think that that’s definitely…
Clayton: That’s where the resentment starts to build up, too. “Well, don’t you know how much time I put into this thing? Making this awesome ivory tower?”
Derek: “Why didn’t you tell me?”
Clayton: Yeah. Yeah.
Derek: “How come you never told me that there was this user?” The takeaway there from the post for me was that conversations help us discover things. I think that too often we really want to write code more than we want to have conversations. BDD really, to me, isn’t about testing, it’s about having conversations. User stories aren’t about requirements gathering, they’re about creating opportunities to have future conversations.
For me, what the title of that post really started to spark was, what are some other examples of places where we’re too focused on tools and not focused enough on the reason why the tools exist in the first place?
Clayton: Code coverage is another good place to go from there. A lot of times, teams that do get a lot of benefit out of BDD start to get obsessed with “Well, how much of my code is covered?” and what does that really mean?
It’s really easy to lose sight of that. Is 100 percent coverage attainable? Is that even the right thing to be doing? We get so caught up on trying to get these numbers in place, the same with…losing my words here…like complexity analysis…
Jade: Oh, like flog and flay, or whatever…
[crosstalk]
Clayton: Yeah. Cyclomatic checks, things like that. What do those numbers really mean to you? What are they trying to tell you? How do they further the conversation instead of become this place where we get all obsessed about the statistics of it?
Jade: Yeah. It goes back to when you have something like that ‑‑ like a flog or a flayer, some score, some number, or something ‑‑ it just makes it easy to throw that other stuff by the wayside.
It’s like, “I don’t have time to have that conversation. I’m trying to get my code coverage up.” It’s just like this thing and everyone can drive towards that, and then you get to a certain point and people are kind of standing around like, “Hmm, wait a second. Are we doing something wrong here?” There’s a cycle for every different kind of team. Maybe it’s every six months or every three months, or whatever.
People realize, “OK, these tools, they sounded really cool three months ago, but I don’t know. What are we really getting out of them?” I think everyone has some 20/20 hindsight every now and again.
Derek: Yeah. One other item for me is tools around process. I don’t know want to name names, because I’m not trying to sway one product versus other. I think most digital tools to deal with a Scrum process, track user stories, points, velocity, and backlog management, a number of those things. What I see a lot of teams do is they get so obsessed on the tool that they do one of two things: they either want to use a tool because they want to lose accountability.
If you put everything on index cards, and you create some, I want to say, “ritual” around it, but there’s some visibility, and there’s some tactile kind of writing and some wiring of the brain happening, a lot of people back off of that and say, “I really don’t like cards,” either, or, “It hurts my hand too much to write them all out,” or, “That takes too much wall space,” or, “They’re just going to be recycled, and you’re killing trees,” whatever.
But I usually see the teams that start to do that, they really focused on trying to either shirk accountability, like, “Don’t treat me like a kindergartener and make me write on a stupid index card with a giant sharpie and put it on the wall for everybody to see. I’m not in kindergarten anymore.”
Or they like tools so that they can legalize behaviors. They can start to say, “Oh, you’re trained in this,” and they want to steer the conversation onto the fact of your average velocity over the last 39 sprints has been X and get legalistic about that, opposed to saying, “What’s the root cause of that?” or, “How can we improve to deal with that?”
It’s more of the, “Let me see what you’re doing, and let me compare myself to what my team is doing to your team.” What are some of you guys’ thoughts about using digital tools and process?
Jade: I was actually thinking about this the other day. I’ve had the same kind of experience, where I was trying to have something out with someone, and they were complaining about, “Oh well, we’re just wasting these cards, just wasting time, because this is really simple stuff, blah, blah, blah.”
For whatever reason I never really went down the path of, “This is a waste of time.” I just took it as, “This is a reasonable idea, whatever. Just go with it.” I was thinking about the digital tools that exist now, could you still do this process 50 years ago? 100 years ago?
If you’re just doing cards, writing things down, and having conversations, go back to ancient Egypt. You could still do the same thing. But, if your process is dependent on, “Well, in order to be successful or have some measure of this or that, then we need to have these digital tools that require us to keep track of this, do these calculations.”
It just seems that there’s so much overhead, but, again, if you go back how we started this, if you go back to the idea of, “Well, let’s just have this tool, and, if something is going wrong, look at the tool,” I think people will get too far into that, and they forget that there really can just be really simple stuff. You could just be having conversations and writing something down on paper. It sounds so simple, but what else do you need?
Clayton: I don’t want to manage a Scrum team in ancient Egypt.
[laughter]
Derek: I don’t know. The pyramids were a pretty successful project, if you ask me.
Jade: Yeah. You could whip them, too.
[l
