Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Jake Plains discuss:

• Ticket Driven Agile
• Cross team collaboration

Transcript

Jade Meskill:  Hello. Welcome to another episode of the Agile weekly podcast. I’m Jade Meskill.

Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich.

Derek Neighbors:  I’m Derek Neighbors.

Jake Plains:  I’m Jake Plains.

Jade:  Clayton, I wanted to let you know that I submitted a ticket to your backlog to record of this podcast, but I never heard back.

Clayton:  If you would have attended the prioritization meeting on the third Tuesday of the month, which may or may not have passed. I’m not sure what week of the month it is. You would have known that it has been assigned to a BA and they are currently tasking it for release in the next sprint, which may or may not get released to production in whatever two weeks the sprint length is. I’m not even sure, I’m just a BA. [laughs]

Yeah, it’s getting done.

Jade:  Awesome. [laughs] So what we want to talk about is, ticket‑driven Agile. We’ve been running into this a lot in some of the larger organizations that we’ve been working with. Where…

Clayton:  If you have [inaudible 01:15] you may be suffering from…

Jade:  Yes

[crosstalk]

Derek:  Our version one.

Jade:  What’s the problem with this ticket‑driven Agile that we’re seeing?

Clayton:  The big part is that, let’s talk to someone and come up with some solution for solving some problem that I have. Or we need something, let’s talk about it. There’s no interaction. There’s no conversation, its processes and tools.

Derek:  So when we went back to this little thing called agile manifestos that had…Maybe two, three, maybe four top things we could look at and if the first one was individual interaction over process and tools. There’s a whole lot of interaction that doesn’t happen between actual people when…

Jade:  I saw the log on that ticket. There was tons of interaction. There is like logging and services interacting. It was really cool.

Derek:  One thing I found is, it’s very easy when communication happens be a tool to not seeing human being on another side of the tool, both ways.

The persons submitting the ticket doesn’t see the human being on the other side who might have a bunch of other stuff that is actually higher priority, is under stress, or maybe on vacation, whatever they don’t see that.

At the same time, the person on the other end isn’t able to feel the pain or have empathy for whatever the ticket is being supported to them.

It escalates the frustration on both sides to the point where when our first interaction actually occurs outside of the tool is a, “Fuck you! Why aren’t you doing what I want.” and “Screw you! Why are you demanding stuff of me”?

Tension is now, in an all time high, before anything’s ever even happened. There’s all sorts of assumptions that are made, all sorts of guesses and there’s no human empathy. I think that it just escalates more and more to the point where that becomes a default culture where it’s just like, “Don’t talk to my team.” Like “Just submit a ticket.”

It also becomes, “Don’t bother talking to their team because they’re just going to tell you to submit a ticket.” It just completely dehumanizes work in a lot of ways. I think that’s a dangerous place to be.

Clayton:  Yeah. I think to the honey do list. I think I’ve got this list of stuff that I haven’t done. It’s been in the list forever. It used to be where it’s like, “Hey, you need to do this.” It’s like, “Yeah, add it to the list.” or “I’d submit a ticket. Give me a ticket, my honey do list queue.”

But now, when it’s more of a like, “Hey, will you help me solve this problem”? It’s like, “Yeah. OK or we can always talk about it.” “Well, I don’t want to do that because x, y, z or I can’t do that right now.” But when I just submit a ticket, it just goes to the list and it never gets looked at.

That’s why we made a joke about the prioritization meeting. The stuff just goes in the list and then if you’re around you might get prioritized, like you were saying, Derek, just the level where you might get the work on this week. But the second that you don’t show up to the third Tuesday of the month prioritization rally, then you get bunked down the list and you’re forgotten about.

Jade:  You forget to bring your lobbyist.

Derek:  A lot of it too is ‑‑ I might go back to the game that I see people do a lot. They’ll do it a lot with kids where it is, “I want you to write down the instructions on a piece of paper, ‘How to make a paper airplane.’ Then, I want you to hand those instructions to your classmate and I want them to build the plane without asking any questions from you, only following your instructions.”

This always fails spectacularly. We think it’s going to be totally different because we entered it the digital rules into the digital tool and handed them across. A lot of times a ticket comes across, or a work request, or whatever and it’s like, “This person is an idiot. They don’t even know it.” I’m reading some instructions that I’m probably completely misinterpreting and don’t have nearly any of the facts on and I’m making all decisions and judgments based on that. I think that is dangerous too.

Jade:  So how do companies get there?

Jake:  How do they get to that?

Jade:  How do they end up in this position?

Derek:  I think some of this is fire fighting culture. What happens is everybody just comes and attacks me with stuff. It’s really hard because the last person that screamed at me, I do their stuff than the person that came to me first gets pissed off because their stuff didn’t get done.

Now, I’m in this dilemma and I don’t know how to solve this dilemma. Everybody’s mad at me all the time. Then along comes a magic tool. I can learn to say no. The way I can say no is, “No, I can’t do that, I’m busy. Go put it in the tool and we have an ability to do this.” We talk about this and scrum all the time.

The sprint is sacred, it’s a commitment. Don’t interrupt the commitment. I think people are well intention when they start down this road and they say, “This is a way to shoot the team from people that come in and bugging them to do stuff and actually let them take a whole sprint to get something done before.”

But it quickly turns into, “I don’t want to have a conversation with you, just go put the stuff in the bucket. Now, I’m teaching you to put the stuff in the bucket. Then the fire fighting culture still re‑emerges because we know that when we put something in the bucket, it’s going to take four sprints to get it done but this is really important.

What we do is we learn these insidious little ways to go to your manager, go to another team or do something to basically force you to deal with the issue that’s in your bucket that is longer that I’m willing to do with which totally submarines the whole reason why you were telling people to go put things in the bucket.

Now, you’re pissed and you’re right back your fire fighting culture yet you still pissed everybody off because you’re forcing them to go put stuff in the bucket.

Clayton:  One of the other things that contributes to this is siloed work or siloed styles of doing things. Rather than saying, “Oh, can you do that”? Like “I know you want me to do it, I don’t have the [inaudible 07:11] with you. I can’t do it right now.” “Is there someone else that can do it”? “It’s putted in the queue because I want to be the only one that can still do it.” Or maybe I don’t even think on those terms but I know I am the only one. There’s no possible way anyone else can do it. It has to be me.

Derek:  I would say that the way that I see this really creep up is in organization don’t know how to thin slice their work meaning that their taking really big increments of work that take almost entire sprint. Means that they have no ability to deal with anything else coming in.

Then teams that are not cross‑functional in a highly siloed where only one team in the whole organization can do a certain type of work. When I have problem with my product but I’m dependent on your DBA for it, I’m blocked. I’m really stressed out and I want to get you to do the work for me.

I’m not allowed to do it. Now, you create queuing for whatever team has the lowest throughput and the most request are the longest cycle time is the team that starts to get backed up and starts to have the behavior of, “We’ll go create a ticket for it.”

“I can’t deal with this. My throughput’s not in. I’m so slow at what I’m doing.” Instead of saying, “Hey, can I teach you how to do it so that next time you don’t have to wait for me.” That doesn’t exist in this organizations or the team that doesn’t want to let go of that magic keys and teach somebody else.

Jake:  I think the convenient thing is that when you have the non‑agile or commenting control style especially with the developers. The developers get the work from their project manager and tells them what to do, I think the stuff just fits in so nicely.

A ticket can come in and then you have this nice little package this task item that you can just give to people. There’s no conversation. If it started out as a conversation then it would stay a conversation longer. The second it goes into the tool, it’s just like tractable task. I think that’s how they get treated, like, “Do the task.”

The person doing the work, especially if it was command and control and other “doing agile,” they’re just being told what to do. They don’t even think about it. They might say that this seems dumb, I don’t know why I’m doing this. I did this four times last week, we probably shouldn’t do it again. But “Whatever, it’s a ticket in my queue I got to do it.”

Jade:  Imagine, we’ve started with great intentions. We really cared about agility and somehow it’s evolved in ticket‑driven agile inside the organization. How do you change it? How do you escape that? If you’re in an organization at some scale…

Derek:  Throw the tool away immediately. Stop relying on the tool. That’s the easiest way to force you to deal with those issues. Usually, what people say is, “There’s no way we can scale if we don’t have like this.” If you have more demand coming in you, then your throughput can handle. That’s the real problem not the tool.

If you say, “We can just put it down in a quick little spreadsheet or something that’s real basic, a piece of paper or something.” The minute that you have more stuff to do than fits on the back of your neck and to‑do list, that’s probably a pretty reasonable smell that you’ve got other problems other than the tool.

That you’ve got a team that can’t work fast enough for the demand that’s being created by them. What can you start to do to fix that problem?

Clayton:  It’s like if someone wants to start eating healthy. The easiest thing is if you just say, only eat things that are whole foods, that came out of the ground looking like that. Or not processed.

If I want a pizza, and I had to make that from things that were whole foods, that’s a lot of effort and work.

Jade:  What if I go to Whole Foods? [laughs]

Clayton:  OK. Go to Whole Foods…No. If I want that stuff, and I had to make it all myself, that would really suck. I would think, maybe there’s some other way I could get this craving for what I have.

Every time I told someone, “submit a ticket,” I actually had to write a card and put it on a board and look at it all the time? I would be like, crap, is there some other way we could not put this stuff on the board?

Which I think the ideas of, maybe someone else could do this work. Or, I don’t know, is there some way we could automate this? Or more than one person looking at it at the same time.

Like, oh hey, I did that last week. I have a script for it that I have never told anyone about. Because I don’t talk to anyone, ever.

Derek:  The other thing is that it forces you to deal with the truths that are there, that you want to lie about. If we’ve got a product that’s say, really shitty. A whole bunch of defects are getting submitted all the time, and that’s what people are coming to us with.

We’re saying, just throw it in the ticket. Just throw it in the ticket. We don’t have to experience any of that pain. Even if the pain is simply having to write it down and put it on a board, or do something.

We can tell ourselves a lie of, “Our product’s really not that bad. It doesn’t really have that many problems.” Because, basically, we’re just throwing everything in the corner.

Nobody goes in that closet where everything’s being thrown except for one person, who’s the person that opens the closet and takes stuff out and throws it at the developers to do.

Where if you start to expose that, you start to go, I don’t like living in this filth. This filth sucks. Why are we adding new features, why don’t we clean some of this filth up? It starts to expose some of that.

Jade:  I know we’ve covered this in other podcasts. What does the ideal look like? If we want to get away from this, we’re moving toward something that is more about agility and less about Agile Tools.

What does that look and feel like? If we’re in a company of 1,000 people, how do people work together? How does cross‑team collaboration work?

Derek:  In a product you have end‑to‑end ownership. Again, one of the big reasons you have a whole lot of this ticketing, throwing back and forth, is you’ve got a product that spans multiple teams, instead of having the product be succinct enough that a single team can own everything from end‑to‑end.

When you get end‑to‑end ownership on a product, that prevents a lot of, “I have to hand part of my product off to you, everything I do.” That minimizes it.

If you have more of a zero defect type of mentality that says, we consume the trash as soon as it comes in. As soon as we eat a meal and we have a wrapper, we throw it in the trash. We don’t throw it in the corner and then someday later take out the trash.

That starts to minimize that process. If you do those two things, that goes a long way. You still are going to have to deal with other teams in a big organization.

If you can be more API‑driven in those interactions instead of a monolithic, your code depends too much on my code but we can do APIs or versioned APIs.

Are those things that helps made it so that you don’t have as much of the ticket request type of behavior happening. Your design is more contained to a product team, and there’s just some communication about hey, what does this thing look like, and we can do it?

The problem is, most organizations don’t have any of those things to start with. My question would be how do you start to get those things into organizations?

Jake:  Another big part of it is the prioritization thing. Priority stuff is always so hard. Everyone has such a hang‑up about it. If you had some better way to make more sane choices when you were doing prioritizations so that it wasn’t based on politics, or something negative like that.

It was more based on what’s the shortest quickest thing we can do to get some feedback, or whatever the case is. Or based on something the customer said. Getting that stuff figured out, I know, is very difficult. I think everyone I’ve ever worked with that had anything to do with prioritization always had a really hard time with it.

I think that goes a long way. The concept, like Derek mentioned, of having smaller teams. Where I think right now, there’s lots of big organizations where no one…If I were a developer on a team that was working with something, and I was dependent on another team.

The idea of maybe me and someone else on the team approaching two other people on this team and spending some time coming up with some solution together in a collaborative sense, and contributing that back to both projects? When you live in the ticket‑driven Agile world, you don’t do that because it’s not a ticket. It’s not how you do it.

Derek:  Our sprints aren’t in sync, how could we do that?

Jake:  Yeah, exactly.

Jade:  We’re really talking about following Conway’s law. We’re talking about reducing unnecessary communication pathways, streamlining everything, and reducing dependencies, so that the product reflects our communication.

Derek:  Yeah. I think a heavy amount of autonomy is in there. A team could go to another team and say, hey, can we bear on this? Even though we’re not on the same team, let’s do this.

We get too rigid in our process. Then that would prevent it. I’d like to do that with you, but I’m in the middle of sprint. Your sprint starts are different from our sprint. Not possible.

We have to schedule it four weeks ahead of time. The other thing that you said that really resonated for me is most companies that have this problem are not close enough to their customers.

When you have trouble prioritizing, what that means to me is you do not have a connection with your customer. Or you’re absolutely guessing what your customer wants. If you’re close to your customer and are actually listening to them, you probably have a much better idea of what your priority is.

Jade:  Great. Thanks for listening to the Agile Weekly Podcast. We’ll get you next time.

[music]

Announcer:  Is there’s something you’d like to hear in a future episode? Head over to integrumtech.com/podcast, where you can suggest a topic or a guest.

Looking for an easy way to stay up‑to‑date with the latest news, techniques, and events in the Agile community? Sign up today at AgileWeekley.com. It’s the best Agile content, delivered weekly for free.

The Agile Weekly Podcast is brought to you by Integrum Technologies, and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com, or subscribe on iTunes.

Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline. It’s free. Call 866‑244‑8656.