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.

[laughter and crosstalk]

Clayton:  That’s true.

Jade:  …with a Scrum whip.

[laughter]

Derek:  For me, the determining point was when I heard somebody say, “Well, we couldn’t do that, because our tool doesn’t do that.” I don’t remember what it was. It was like, “Oh well, mark that as zero,” or, “Change to a Fibonacci sequence,” or, “Put your estimates in ideal hours,” or something, and the response from the person was, “Well, but our tool doesn’t support that.”

Jade:  That’s why I love digital tools because it gives me something to blame other than myself.

[laughter]

Derek:  To me, our tools are just a distraction, for the most part. I think back to what you’re trying to get to Clayton, is, when we really get to the roots of what we do, how we do it, and why we do it, I think anytime the tools become a significant part of the conversation, I have to question, are we using them as a scapegoat of some kind, either blaming them for something, or “Look! A pony”! If we should use vim instead of Emacs.

Let’s stop talking about what’s really important and start talking about something that’s…

Jade:  I came across a blog post this morning that was like, “We’re this successful web shop,” or whatever. It was a blog post on how you get set up with Z shell, rvim, blah, blah, blah. All these other tools. I’m picturing someone going to that site and being like, “Whoa, this is totally awesome!”

Then they’re going to spend five hours getting all that shit set up, and then they’re going to go back to work and be like, “Hmm, OK. What was I supposed to do today?”

Clayton:  And, “I don’t know how to use any these tools at all.”

Jade:  Right.

Clayton:  Now I’m going to spend the next month figuring out how to become an expert at these tools, and then maybe I’ll get some work done.

Derek:  I’ve definitely gone through that cycle in my career. I definitely think that good tools are important and understanding your tools is important, but this is one of the things, for me, on the craftsmanship side that I get a little worried about.

A lot of people, when I look at the craftsmanship movement, they really start to say, “Well, in order to be a good gardener, I’ve got to have the perfect shovel. In reality, I think, to be a good gardener, a really good shovel helps, but I think you can be a really damn good gardener just using your hands.

Clayton:  That’s like you need an expensive guitar to be an awesome guitar player. That’s not necessary.

Derek:  Right. To me, how I interpret craftsmanship is being able to tell the difference and the caliber of the guitar is important, but being able to say, “Well, I can’t do good work because I don’t have a good guitar,” to me, it starts to sound like a cop‑out. It starts to sound like an excuse.

We’ve come to this place now that we’ve got so many different competing processes, frameworks, and movements at foot that I think, right now, sometimes it’s hard to be a good software developer, because there’s so much noise that it’s hard to get distracted. You’re either paying too much attention to the process or you’re paying too much attention to the tools.

What we’ve forgotten is that there’s a customer and there’s a value that we’re trying to deliver. I think that, to me, how do we get back to the roots of saying, “That’s what it’s really about. It’s about the people, the conversation, and providing value.”

Clayton:  It’s about moderation. It’s about finding those points where, “Yes, this is helping us solve a problem.” Maybe some of our team is on site, so having some sort of digital tool in place is required, because that helps facilitate communication better to our distributed team.

That is a perfect reality in these days, and it would be a good reason to go down that road. But it’s about finding that balance of, “Well, let’s not try to run the entire business and the entire process through this digital tool. Let’s use it to communicate the things that are hard to communicate at a distance, and everything else, let’s make sure that we keep those things, because that’s the most effective way.”

When managing the tool takes more time than getting the work done, that’s where you have a serious problem that you’ve got to deal with.

Jade:  Yeah. If you imagine a Venn diagram where one circle is introverts and the other circle is “I wrote my own something”…

[laughter]

Jade:  …they’re basically on top of each other.

Clayton:  I want to see that.

Jade:  Yeah. To be fair, a lot of software developers, when they hear about, “Here’s this new process,” and the process is difficult, because it requires things that I’m not good at or things that make me uncomfortable, the way I can make it easy is if I make a tool that bypasses those difficult things and, “Now I’m doing kanban, and I don’t have to talk to anybody,” or whatever.

People go towards that route because that’s how they make the process easy, even though that’s not actually going to make the process easy.

Clayton:  Right. That’s how they deflect.

Jade:  Sure. Yeah.

Derek:  The last thing Kennelly just posted that really was interesting to me was, “Assume you got it wrong.” I think that that’s a good life principle if you always operate. It’s, “I’m the stupidest guy or gal in the room, and I’m probably doing this wrong.” To me, it sums up the whole “Inspect and Adapt.”

If I’m constantly thinking, “I’m doing this wrong,” I have to constantly be asking myself, “OK, what am I doing wrong?” What are some of you guys’ parting thoughts here?

Jade:  I’ve had countless number of times where I have been at the end of a planning meeting, and I thought, “Well, I totally understand what they’re saying.” Then I repeat something back, and it’s like, “That is totally wrong,” and I’m like, “OK.”

[laughter]

Jade:  It’s just going over things, and that kind of mentality, even when you think you really got it right, just using different language too, I think, a lot of times, you think you got something right because you’re thinking about it in a certain way using certain words.

Then, if you say it back, ask a question, or phrase it differently, then there’s some new little thing that comes out, but I think that’s just great advice in general but also for any actual process.

Clayton:  Yeah, I agree. Just repeating things back and explaining them in your own terms, the way you understood it is one of the best ways to gain that clarity from all aspects of this process. Interpersonal communication on your team, to dealing with the product owner, all that stuff, it really is all about that communication and finding effective ways to communicate.

[music]

Derek:  Until next time, we’ll see you.

Jade:  Thanks.

Clayton:  Thanks.