Agile Weekly

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

• What happens when someone has central control

Transcript

Derek Neighbors:  Hello, and welcome to another episode of Agile Weekly Podcast. I’m Derek Neighbors.

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

Jade Meskill:  I’m Jade Meskill

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

Derek:  We’ve got another fantastic, hypothetical situation.

[laughter]

Derek:  You may spot this in the wild, I don’t know. We’re talking about things that could potentially maybe happen, someday, to some teams.

Say you had a czar of a department, or a unit, or a job function.

Roy:  Like a real Russian Tsar?

Derek:  Yeah, like an architect…

[laughter]

Jade:  I’m a Marxist, sorry.

Derek:  In the hypothetical situation, we would probably see this as being an architect, or maybe be a designer of some kind. When I say designer, I mean the chief of the companies, the [inaudible 00:55] top guy.

Jade:  Or the head programmer?

Derek:  The head jock honcho.

Jade:  On the team, the technical lead or something?

Derek:  Not even that. Above the technical lead, the top of the food chain. They have this stance that says, “The only thing that can done can only go to production if I have approved it.”

Roy:  You’re saying everything has to go through this guy?

Derek:  Everything has to go through this gal. She is totally 100 percent, “The design, every pixel has to be done by me,” or “Every single method has to be approved by me if we’re writing code.”

This person works in a large organization, thousands of people per se, and lo and behold, they can’t go to every planning meeting.

The good news is they have some mini‑czars that they can send out to these planning meetings. They can go to these planning meetings, and help the developers and the designers do things.

Then what happens is all sorts of decisions happen in a planning meeting. When these mini‑czars come back to the big honcho, the big honcho says, “Nope, I don’t like it. It needs to be this way.” Now they go back to the team and have to tell the team, “Sorry.'”

[crosstalk]

Derek:  …What does that look like? What happens? How do you fix that? How do you rectify that situation? What are the downsides to that stuff?

Roy:  First off, is there anything wrong with that?

Clayton:  Yeah, I’ll take the devil’s advocate approach. The reason that all the design has to go through that one person is because if you want to maintain a consistent brand experience for the end‑user, you can’t just let people ‑‑ especially developers who don’t have any design sense ‑‑ to go off and do a bunch of crazy stuff.

Roy:  There’s a bunch of awesome examples where I’ve seen exactly that with Google. In fact, I’ve heard, Derek, you complained about this specifically that Google has all of these products out there of totally different experiences, that are totally not integrating because they’re all being developed in isolation.

Derek:  Ever since their designs are [inaudible 02:56] left…

[laughter]

Derek:  They have not been on‑brand.

Jade:  I’ve seen these on the development side, too, where you’ve got all these dumb programmers that we hired that are up there writing a bunch of crap. If they could just do it like me, everything would be so much better.

Derek:  Yeah, where do you think our tech‑level of that comes from?

Jade:  Yeah. [laughs]

Clayton:  I suppose we pay these people six figure to be morons.

Derek:  The dumbest, highest paid people, we have.

[laughter]

Roy:  I get that. The guy at the top, his neck is on the line if should go south, he wants to make sure that everything goes north. Right?

Derek:  Yeah, it’s pretty scalable, they are able to ship a lot of production software this way.

Clayton:  That’s a trade‑off. If you go through this bottleneck where one person has to approve everything, obviously everything goes very slowly, and you don’t ship very often.

Jade:  And you redo a lot.

Clayton:  Yeah, you probably use a lot of rework, as obviously the market’s going to change, and you’re going to have to go back and fix things and change your strategy. But theoretically, everything looks pretty good, and it’s pretty close to being “perfect” when it does ship.

Roy:  I guess that depends on their value system then. Do you value the ability to move fast, to make changes and respond to changing requirements in the changing world? Or do you prefer to have a perfect experience? Because I could see value in both of those.

Derek:  Yeah, if a lot of people really applaud Apple and Steve Jobs and what he did ‑‑ he certainly was not interested in shipping on a very tight schedule and going very fast. He was much more concerned about shipping perfect products than he was shipping bad products more frequently.

Roy:  Right. Another example is like Rolls‑Royce or something, where, I don’t care if it has the latest and greatest features, but…Hold on, let’s be clear here. I’m not buying a Rolls‑Royce.

[laughter]

Roy:  I could see people don’t really care about [inaudible 04:46] features, they care about every product being extremely high quality. I don’t know if they actually have this, but I could see them having a philosophy like the CEO hand‑checks every single car before it leaves the factory, because they insist on having that premium experience, and that everything is perfect.

Jade:  Apple’s an interesting case, because they’ve shipped a lot of great hardware. They shipped a lot of really poor software that is not consistent and not very good.

Derek:  You’ve obviously used their online store before.

Jade:  [laughs] Yeah.

Clayton:  I’ve always had a tough time with the Apple comparison. I think that’s the first one that people jump to, but no one ever really acknowledges the difference in hardware.

Jade:  It’s much harder to fix hardware once it’s gone up the book.

Clayton:  Yeah, so that’s different. That’s something that we should clarify.

Derek:  When I look at this hypothetical situation, the thing that I think is the biggest pain for me or the biggest thing that I see that people aren’t talking about, is what does it feel like being a team member who goes through a planning meeting with a group of people and comes up with a solution and an idea only to, an hour later or a day later or two days later, say, “Uhh, what you’re doing is really stupid and really dumb. This is the right way to do it. Throw away everything you’ve done and go do this other thing instead.”

What does that feel like as a team member, do you think?

Roy:  I can see two parts to that. First off, we talked a lot about autonomous teams. I would feel like, as a team member, a large part of your autonomy gets taken away if someone comes back and says, “You have to do it my way.”

If it’s taken from the standpoint of, “Hey, have you considered using other options”? And they are truly better ideas. If you follow the core commitments and you choose to always seek to better an idea and to accept any idea no matter where it comes from, then that sounds like it would only be a positive experience.

I think that how that interaction takes place, and the attitude of both parties, has a huge impact on how that’s going to go down.

Clayton:  I would feel pretty useless and like my time was being wasted. I would probably not even bother attending. Or if I did attend, it would just be for show. I would probably not even be paying attention because, really, what difference does it make?

Roy:  But there is a difference. Clayton, if I came to you. Let’s say you plan on a Monday and I come to you on a Wednesday. I say, “Hey, I saw what you guys planned out on Monday. Have you considered using other possibilities”? Would you have that same reaction?

Clayton:  If you said, “Had you considered these other possibilities”? We had some dialog, and I said, “OK, let’s talk about it next Monday.” I think that would be one thing. If you said, “Put the brakes on. Really think hard about these other choices, because you’re doing them no matter what.” Then I would feel like, “What’s the point. Why did I waste that time”?

Jade:  I can tell you what it’s like to be on the other side of that. I’ve been that person. It sucks. You can’t trust anybody. You are paranoid and you need to be…

Roy:  Just to be clear, what side are you talking about?

Jade:  The person who’s the bottleneck. Who…

Roy:  Oh, I see.

Jade:  …is changing things for everybody.

Roy:  And insisting that your rules be followed?

Jade:  Yeah. It’s a very crappy position to be in. You don’t sleep well. You’re not relaxed. You’re always stressed out because everything is going wrong around you all the time. You don’t trust anybody. I think that’s really where…that’s the core of the issue. You don’t trust anybody.

Derek:  In this particular hypothetical, there’s also a middle person. We’ve not talked about that middle person. Not only is the person that is doing the work probably leaving frustrated…

Roy:  So you’re talking about the Vice Czar in this, right?

Derek:  The Vice Czar goes into this thing thinking, “Oh, I totally represent the attitudes and the patterns and the thinking of my boss.” We go in and I walk out thinking, “Man, this is all going to be really good.” Then I go back and they say, “Why did you make this decision? You’re letting them do that? I can’t believe that”!

Now, not only do I have to feel like maybe my boss doesn’t trust me, but now I have to go deliver that news to a whole group of people to say, “Hey guys, even though I said that this was probably the right thing to do, as it turns out, the Grand Czar does not agree with me.”

What does that got to feel like?

Clayton:  You lose face with the other people. I know that I told you that it was good, or that we agreed that it was good, but it turns out that it’s not. So either I can play that off as, “The czar guy is a real jerk. Man, what an asshole! I hate that guy too.” Or you would have to just hope that people aren’t thinking, “This person is really stupid. They don’t understand what their boss wants. Man, I’m not going to bother asking their opinion anymore.”

Roy:  Right. Even the boss is probably getting frustrated with them. They’re coming back with ideas representing the team. It’s probably not what the boss wants in the first place. They’re never going to think the same way. So this person is probably just getting shit on from both sides.

Derek:  So we’ve got the hypothetical. We’ve got some of maybe how it feels to be all of the roles in the hypothetical. How would you go about fixing it?

Roy:  In my opinion, if you can figure out some way to have the team earn the Czar’s trust and rid the organization of the Czar, not rid of the person but rid of the role, I think that will go a long way. Somebody who is insistent on all of these best practices, good coding styles, good design, or whatever, they should be going out and championing all of those things and explaining why it’s so important and really convincing people and winning them over rather than telling them what to do.

Jade:  A lot of times they do have a lot of really great knowledge and sometimes even some special insight that other people don’t have, but you’re right.

They should be going out and helping those other people to gain that skill and also experience things from the other side of the fence.

The things that are changing during planning or the real complexities on the ground of dealing with this on the fly, those type of things so that there is some empathy for what the people are going through while they’re out dealing with these situations.

But again, it comes back to building trust with those people. You believe that they’re doing the best thing that they can.

Roy:  It gets tough though when you set up a system like that in which you’re like, “I’m the one who is going to decide on the design, so Clayton don’t even bother wasting time coming up with designs or whatever.”

“Don’t even bother coming up with the method definitions because I’m going to shoot it down and give my own implementation anyway.”

Now all of a sudden Clayton hates me, and it’s going to be really difficult for Clayton to earn my trust because he is going to be trying to get away as much as he can to please the people that are breathing down his neck without getting my ire.

He is going to be subverting me, which is going to cause me to trust him even less like that’s just going to be a feedback loop.

Clayton:  There are definitely cases where people get in this situation like what Jade described like no trust and I don’t think most people would want to be in that, but there are some people who do enjoy the aspect of controlling everything.

They want to be the hero and they want to be seen as the smartest guy in the room and all that stuff.

I would say that probably is a pretty big component in a lot of these cases compared to the person who really doesn’t want it to be that way all the time, but it’s just like, “Oh, woe is me,” it just happened to be that way.

There is some aspect to that. I think unwinding some of that desire for control where they don’t feel like all of their self‑worth at their job is based on whether or not they got all the answers right all the time. I think that could go a long way.

Derek:  When I look at it, Steve Jobs might be a good example. I didn’t know Steve and I certainly didn’t see him work, but I would…

Roy:  Me and old buddy Steve, yeah.

Derek:  I think that if I were to…

Roy:  I call him Steve.

Derek:  …guess how he operated, he trusted his people. Because I don’t think he could get the results he got without trusting them. What he wanted to control was the essence of the spirit of the products that were put out.

Not necessarily how they were built and so to me the difference is you come back from a planning meeting and I say, “Oh my God, you’re doing all the stuff wrong and this is how you should have done it.” I don’t think that’s how Steve operated.

He probably operated in a “I’m going to let you do whatever and when you show it to me, if it’s crap, I’m going to say it’s crap, but I’m not going to ship that and fuck you go do it right, and when you get it right, we will ship it. Until then, leave me alone, don’t waste my time.”

“Why did you call me to this fucking demo that sucks this bad”? What I think is very, very different than saying, “I’m going to tell you exactly how to do every little thing.”

I might tell you at the demo to say like “I’m not doing that and I had expected this.” And I think that’s a subtle difference, but that’s very different than trying to control how everybody does their job.

Instead of saying here’s the bar of expectation and I’m going to make you live up to that, I’m not going to tell you how to live up to it.

Jade:  I think that’s right.

Derek:  How do you get somebody to get to the point where they’re allowed to let the essence of what their standard is hold but not have total mistrust.

Jade:  I think there are some systemic problems in that as well that that person is probably being held accountable for those decisions by their people.

Getting some understanding put in place there is a big help. To help their boss see that like they don’t need to be held to that.

They need to be held to the standard of they’re making everyone around them better and helping them achieve that essence and not being a control freak.

Because usually it’s people that don’t want to do that. They end up in that situation because of some externality.

Derek:  Right, fear usually, they’re afraid of something.

Roy:  I wonder if people that are successful at it and managed to climb their way to the top might not be the ones that enjoy it though.

Jade:  There are people that enjoy having that control like Clayton said, and those people might not be able to help them.

Derek:  All right. See you next month.

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

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

• Simplicity

Transcript

[laughter]

Clayton Lengel‑Zigich:  It is hard doing that every week.

[laughter]

Derek Neighbors:  You don’t do it quite as good as Jade does.

Jade Meskill:  All right, go Roy.

Roy van de Water:  Hello and welcome to another episode of the Agile Weekly Monthly Podcast. I’m Roy van de Water.

Jade:  I’m Jade Meskill.

Clayton:  I’m Clayton Lengel‑Zigich.

Derek:  I’m Derek Neighbors and joining us today is the improv group.

Roy:  In the room next door.

[laughter]

Jade:  Yelling very loudly.

Roy:  Today we are talking about thinking simply, instead of thinking complexly. Jade, you and I have been…

Jade:  Accused of being simple?

Roy:  Accused of being simple.

[laughter]

Roy:  Can you tell me a little about what that idea means?

Jade:  Sure. We’ve been trying to…

[shouting in background]

Jade:  These guys are really… [laughs] yelling in there.

[laughter]

Roy:  I’d like to denote that they were entirely quite for the last 45 minutes before we walked into this studio.

Derek:  It’s like they’re Chicago trading for [indecipherable 1:10] .

[laughter]

Jade:  Buy! Buy! Sell! Sell! [laughs]

Derek:  You do the savings, I’ll do it.

[laughter]

Jade:  We’ve been working on some concepts of trying to write very, very small, simple applications, taking the UNIX philosophy and applying it to web applications to avoid the over‑complication that tends to arise in larger systems.

Roy:  What does an over‑complication look like?

Jade:  Usually a system where the responsibility is not very well delineated between either modules or different parts of the application. It tends to be very messy and sloppy, where it’s hard to tell where something…There’s no discrete functionality, I guess is the best way to say it.

Derek:  The way that I think about it is, if you had a web application where the code that displays the page where you enter in the details about a job is in the same place as the code that makes the…Say the job in a database in the same place in the code that schedules the job, in the same place in the code that runs the schedule of job, in the same place in the code that…They’re all in the same place.

Roy:  It sounds like everything is in the same place, it sounds pretty simple to me.

[laughter]

Derek:  Right, until you get everything in the same place, and then something goes wrong, or you want to change something. We have this problem with the Agile Weekly podcast or Agile Weekly website, where we had a bunch of things that were all clinched together.

If I took the approach of a normal, say, Rails application, like the standard Rails way of doing things. When certain pieces of the system got a little too big, or too unwieldy, it was hard to…it seemed like it was simple because it was all in the same place, but the real simplicity came when we broke those out into little pieces.

Then you have these…you’re going back to [indecipherable 3:08] sampler, mentioning the UNIX philosophy, with these little teeny pieces that all did their one little thing really well. They all just worked together.

Roy:  So why wasn’t it obvious to be that way in the first place?

Jade:  Because in the beginning that would have actually been more complex.

Roy:  So how do you know when you are doing something complexly instead of simply?

Jade:  I think when it becomes hard to explain, it’s probably too complicated.

Roy:  Is that like the metaphor ideal, like you should be able to describe whatever you’re building as a metaphor, and as soon as your metaphor circuit is breaking down that means that you’re putting too much in there? Is that…

Jade:  I think that’s a good way of putting it. If it’s not something that you can explain in a simple, conceptual way, it’s probably gotten a little bit out of control.

Roy:  Is this idea of complexity versus simplicity something that is on the overall project, or is it something that you see replicating down to the individual components of a method, or a class, or something like that?

Jade:  It’s an important recursive idea that happens. If you are being simple with the very small parts of your system, it’s easier to be simple at the larger scale as well.

Derek:  I think developers in general…they find it easier to think in these terms when they’re maybe down in the class with the [indecipherable 4:31] methods. I think that’s where they live, and all that stuff. Then you go up a few levels and even talking about what features you’re delivering.

I think a lot of developers might understand that concept at that level, but then it gets in the features and it’s like, “Well, the product guy said just build this stuff, and like well, OK, whatever, I don’t care.” Where I think that’s the even more important part, that’s an equally important part to be having this discussion about simple…

The planning meetings that we’ve been involved in lately for sure. I think we’re constantly driving towards trying to find something that’s simple, but not too simple, or not too simplistic. That’s a really hard thing to do.

Jade:  Yeah, I think being simple is hard.

Roy:  So this is the type of thing that I might solve using design patterns, like, “Can I just throw those at this problem?”

[laughter]

Jade:  We have an observer. Let’s find out…

[crosstalk]

Clayton:  I think the interesting thing to me, it’s always easier to add complexity that it is to remove complexity. When you start to get that Zen peace, it’s way easier to say, “Let’s start super simple and we can add what we need to add,” which is a very hard discipline to build.

Even if you’re talking product. That struck it for me. Can’t say how many times you’re talking about a feature and you’re up there at a whiteboard drawing it out, and somebody’s like, “Well that’s just too simple.”

At the end of the day, if you give this to the developers, it might turn into a two‑week feature request even though it sounds so simple right now, on the surface. As human beings we like to overcomplicate everything all the time.

Roy:  What drives that, though? Why do we want to overcomplicate things?

Clayton:  Some of it is uncertainty, or, we have this need for completeness. If we only say we’re going to show X, it’s like, “Yeah, but Y and Z and A and B are all available to us, too. We have to show them.”

“Why? What if we just showed X? What if X is enough? That is all that feature needs, why do we need the…”

“Because those other things exist, so we have to show them.” There’s very much this, because we can, we should, mentality.

Derek:  Another thing we see in our work is that people have an aversion or misunderstanding of iterative development. It’s like, if we don’t do this now, we’re…

Jade:  You mean incremental development?

Derek:  Yeah. If we don’t do this now, we’re never going to do it. If you guys don’t plan every single thing that we think we know, then we’re totally screwed. You guys are going to forget it.

To be fair, I bet you there’s a lot of product people out there who have teams that maybe aren’t the most reliable and don’t deliver what they say they’re going to deliver, and all those things.

When someone were to come in and say, “Hey, we’re going to do some really simple thing and ship it real soon,” it’s like, “Yeah…I don’t believe you.” Like, I’m not going to take that risk.

Clayton:  To me, it sounds like there’s a little bit of the 85‑15 rule, where you can deliver 85 percent of the value with 15 percent of the effort. Then you spend the other 85 percent of your time delivering the last 15 percent of the value.

I have worked with different product people, designers and architects in the past, where they want to get all 100 percent, because they know that if you spend 15 percent of the effort now to deliver 85 percent of the value, you’re never going to spend the other 85 percent to deliver the last 15 percent.

Which may be a really awesome business decision, but you’ll never be 100 percent as good as it could be.

Roy:  Some of it is, building off Clayton’s response there, is, there are a lot of teams where if you say, “OK, fine, let’s just do X.”

You say, “OK, let’s do Y.” “OK, let’s do Z.” Then you say, “OK, let’s do A.”

Then they’re like, “We’re going to have to re‑evaluate the whole thing. If you would have told us up front that we had to do A, we would have totally built this in a different way. Now that you want A, we just have to throw away the last six months’ worth of work, and start all over, and if only you would’ve told us.”

Once they get trained for that it becomes, if I know anything I must disclose it now and tell you that you have to build it into the app, because if I disclose it later you may come back and tell me, “Oh man, we have to throw everything out and start again.”

Clayton:  By disclosing everything up front and insisting that it all gets done, the product owner is really trying to maximize his choice later on down the road. His ability to choose later on.

Roy:  They’re trying to mitigate their risk, I believe. If they disclose all that and say we need to do all of that, then they think they’re mitigating the risk of somebody coming back later and saying, “Oh, we can’t do that because you didn’t tell us.”

In reality, what they do is increase their risk exponentially, because they make it so it becomes almost impossible to deliver what they’re asking for.

Jade:  The cognitive load becomes much more to deal with and “grok” all of those additional features when they’re not needed.

Derek:  It sounds to me like then you’re going to try to build a system that’s overly architected just in case you have to build any of the number of features you’re told you have to support.

Roy:  One thing recently that clarified this a bit more for me was that we had a situation where we wanted to deliver some features that would have been nice to have a database.

Having a database was a non‑trivial thing, so we used the file‑system. We had a table with a row and a column in it. That’s all there was.

Derek:  A folder with files in it?

Roy:  Yeah. We had a folder with files. That was sufficiently complex for what we wanted to do. I think some people hear that, and they think, “What are you, f‑ing crazy? You can’t use the file‑system…”

[laughter]

Roy:  “…Use a database, that’s crazy.” What we understood was, right now, for what we’re trying to do, for this little slice, that’s what we need right now. We acknowledged that that is not a long‑term solution, but it’s going to be as long‑term as it needs to be for what we want to do with it.

Jade:  It was very simple to replace.

Roy:  Exactly.

Derek:  I think where this started to come and play for me was when we started to cross the chasm, so to speak, in doing a lot more mobile development.

So things that we thought were pretty trick and pretty sleek and pretty simple and pretty small started to fall down really quick when a customer would say, “hey by the way, I need an android version or an iPhone version of this.” and I was like, “oh shit, like dude like how in the, man!”

And so when it got to the point like “OK, let’s make everything like API and we’ll have the front end consumed of the web version consume that API and hey now we can have the iPhone version.”

Jade:  Anything can use this API

Derek:  API right like it started to like I think click a little bit more just even in that that you could kind of separate this concerns a little bit better.

Then you can start to say “OK how about make perhaps even smaller and smaller,” and keep slicing those so that they are easier and easier to replace, so when you do find something new you might not have to rewrite the whole system to do something. You might be able to rewrite a little piece of the system to do something which is a lot less risk and a lot easier to do.

Jade:  That’s kind of where [indecipherable 11:27] and I got into writing these micro‑applications that had very discreet functionality.

We were having trouble, even with that simplified view of things of just having an API and a web service that was still wasn’t good enough. There was still too much co‑mingling of functionality between different classes and you know, the abstractions were good enough.

We took a crazy stance and tried to work on like how can we build the smallest possible thing to do this one job, and then chain all of those things together as needed?

Roy:  I felt like that worked for those instances I am curious to try more places and see how well it runs across the board.

In that case it was a project that only ended up being a collection of five or six of these smaller apps, but when you start to build a more complex user experience where you have a whole store form or something where the user [indecipherable 12:24] component you try to keep all of those pieces separate. I wonder how well that’s going to play together.

Clayton:  I feel pretty confident in it from the next example like; pick any five UNIX commands. It could probably do a bunch of stuff. If you chose wisely.

Derek:  Yeah, It does fall down at certain point though. What I mean by that is, there’s a whole lot of things people do, they don’t do with Unix commands any more. You could use “set OK” and “grip” to do a whole lot of things.

Jade:  Everything

Derrck:  But you probably open up “vi” or “sublime” to do it instead because the interface is easier even though its [indecipherable 13:00] all mashed into an application than a whole lot more than those simple things.

I think there are this kind of. It is nice to assemble them small‑ly. Into small little apps that interact but when you have to chain too many interactions together, the complexity of remembering what and how to chain things starts to become cumbersome.

Clayton:  That and when there’s like a whole bunch of apps that you don’t even know existed.

Roy:  Yeah

Clayton:  So you start rewriting them yourself

Derek:  Yeah. What tends to happen is when you have things that have common things you start to see those assembled into other apps.

I would say that OK and grip get used within most editors the developers use today. Because they make sense to kind of bundle natively into an editor rather than a drop out to a shell and do them. I think the work that those things did and put in place are straight up stolen and re‑used inside of those editors.

Jade:  It’s like when we talked about, we built a simple app but at some point it became too complicated. It was simpler to take a different approach of writing smaller, more complicated apps. Think this is the contrary example of at some point that becomes absurd. The interactions are too complicated.

Derek:  Right.

Jade:  Now you find a simpler way to merge those things together.

Derek:  It goes back to; it’s always easier to get more complex.

If we’ve got the set the OK, the grip, and we need to put them all together like we know those things really well now and so we know how to assemble them into an interface or into certain things a lot better than if we would have tried to build those things as part of the bigger complicated thing to start with.

Jade:  I think that’s where some of the ideas around, like hexagonal design can come into play. Where you’re composing complex systems out of simpler modules and simpler pieces.

Clayton:  We’ve been talking a lot about in terms of software, but this same stuff applies to process things.

You can take the components and do them very well and you can build some sort of process that works and maybe it gets too big sometimes or maybe you decompose or whatever, but it’s not just whole scale, you know.

From a coding example, jumping straight into some massive java architecture thing and that’s the same thing as like what you’re going to get on the juror train and see if this mother app…

[laughter]

Clayton:  …Or it’s like trying to get a good user story. I am like “let’s try and get good at talking to each other as a team first.”

Derek:  Let’s get good at working together.

Jade:  Yeah, let’s try those things first and then you know, you can juror me to death.

Roy:  Hey I will see you next month

[music]

Presenter 1:  Is there something you would like to hear in the future episodes, head over to inagram.com/podcasts or you can suggest a topic or guest.

Presenter 2:  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 agileweekly.com. It’s the best agile‑content delivered weekly for free.

The agile weekly podcast is brought to you by inagram technologies and recorded in gangplank studios in Chandler, Arizona.

For old episodes check out inagramtech.com or subscribe on iTunes.

Presenter 3:  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‑2448656.

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.

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

• How to get more cross functional
• How to overcome the challenges of working with very different skill sets
• Asking not listening

Roy van de Water, Jade Meskill, and Clayton Lengel-Zigich discuss:

• What is the right pace for change in an organization

Transcript

Jade Meskill:  Hello, welcome to another episode of “Agile Weekly Podcast.” I’m Jade Meskill.

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

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

Jade:  Today we wanted to talk about, when you’re making change inside of an organization, whether it’s at the team level or the management level, the organization structure, change takes some time. Regardless of how fast or slow, it takes some time to happen. How long is a reasonable amount of time to wait for change to happen?

Clayton:  What if we start with this scenario? What if we changed as fast as possible so that no one is uncomfortable?

Jade:  That’s going to be pretty slow.

Roy:  Yeah, I’m not cool with that.

Jade:  I feel like I’m OK with a lot of change, but it certainly makes me uncomfortable, a lot. If I waited for myself to be comfortable, I know that I would never change.

Clayton:  What is it about being uncomfortable? If you’re saying that change makes you uncomfortable, you maybe get uncomfortable when there’s some change. What is it about that make you OK with being uncomfortable in that context?

Jade:  I’d say for me is knowing, based on my previous experiences, that there is probably something better on the other side of that change, even though there is discomfort in the midst of that change.

Clayton:  Yeah, I think I would say that I am probably in the same boat. I have past experiences where being uncomfortable, and going through some change is how I got some result I wanted.

Roy:  You think that maybe if you don’t have that experience or that knowledge, that the end result is going to be better. The harder you push to try to make things go faster, the more pain or uncomfortableness you experience. It’s like, “I don’t want to push any harder, because then it will just make it worse, and it will get more and more painful, and there is no ceiling.”

Clayton:  I like Indiana Jones in the “Last Crusade.” I am willing to step off that ledge where it looks like I’m going to fall in the ravine, because I know that the invisible ledge is actually there. I’m going to be able to walk across the chasm.

Jade:  The chasm. The first time you did that…?

Clayton:  The first time I did that, it was like in the movie, where I was like, “I’m going to fall my death.”

Jade:  Somebody had to get the sand for you and throw it across?

Clayton:  Yeah, there you go.

Jade:  A prerequisite to this episode, “Go watch the movie.” No spoilers, we won’t tell you how it ends.

[laughter]

Clayton:  There’s something from that. I know from experience that I probably discount this in others. At some point in time I went through the pain and suffering of being very uncomfortable and changing in it. It worked out OK.

I’ve done that multiple times. I’ve got great results from that. I’m totally on board and I’m happy to do that.

Other people who have not gone through that experience, I don’t think I give enough credit to how hard that is. I know that I’m very willing to do lots of changing and maybe change very fast.

I get frustrated when other people aren’t willing to go. Not even the same space, I understand that. They’re not even, to me it feels like, willing to go half as fast or a quarter as fast.

Jade:  Something I’ve noticed that’s interesting is people that are uncomfortable with change, they think of change as the change.

If we’re going to do something different or try something different, we’re moving from one state to another, then that’s it. I find myself being very comfortable with knowing that, the faster we change, the faster we’re going to change. If we change and it’s not working out, I know that we’re going to change quickly to something else.

Do you think that factors into people’s comfort level with being afraid to experience that change because they feel it’s going to be a permanent situation on the other side?

Clayton:  I would say so, yeah, especially if you’ve been doing the same thing or something similar for a long time. That’s maybe how you got to where you are now. That makes it even harder.

I read a good article where people were talking about how in the Agile community, we can’t just go discounting managers and say that managers are stupid people, and they’re so dumb and why don’t they get it?

Obviously, they did something. They work inside some system and they’ve gone to some level in that system using whatever they had to do. That’s the world they know.

Obviously, they’re not dumb people. They didn’t just stumble upon being a manager, but they did something to get there, based on the rules in that context.

Roy:  Like being born to the present.

Clayton:  The management class?

Roy:  Yeah.

[laughter]

Clayton:  I guess I can’t talk about that. There’s a whole swath of people out there who are managers of Agile teams that got there somehow.

Maybe you disagree with that system and you think it’s an antiquated way to work. Whatever, but they did something. They’re not totally stupid.

To go in as an Agilest and say, “We’re going to change everything, and change is good, and you need to accept it,” blah, blah, blah, that’s so foreign. That’s not how everything has worked before and it’s like you’re discounting everything that these people have done so far as if it’s just throwaway.

Jade:  The complexity of the reality that they live in.

Clayton:  Right, exactly. I think that’s another factor that we don’t consider with change. That’s one of the reasons why people go slow, is that you’re having to do this whole context switch.

I think some of it’s a mindset thing, too. If you’re a fixed‑mindset person, the world is the way it is, for whatever reason. You shouldn’t change because it wouldn’t work. You’re not meant to be that person.

Roy:  In fact, you desperately try to hold on to the old way because that’s the only world in which you can survive and thrive.

Clayton:  Yeah, that’s the one that you’re good at. You want more of the thing you’re good at.

I would say that people that have more of a growth mindset are probably more willing to say, “OK, you want to do something that sounds totally radical? I’ll try that for a while,” because to them, it’s not the end state.

Jade:  What happens if we turn this scenario around and say, we change as fast as the most aggressive person? What happens then?

Roy:  All right, now we’re talking.

[laughter]

Clayton:  I don’t know. Why does that appeal to you, Roy?

Roy:  It goes fast.

Clayton:  For the sake of going fast?

Roy:  Well, you get there faster.

Jade:  Do you?

Roy:  I don’t know, maybe you don’t. I got a feeling that that would make the majority of people extremely uncomfortable, probably beyond whatever their limits are.

Jade:  Would they be completely dysfunctional at that point?

Roy:  I don’t know. They’d either be completely dysfunctional, or maybe just totally leave, or even mentally check out and just not be able to cope.

Jade:  Just reject the reality that’s happening around them?

Roy:  That’s what’s interesting. If you took an individual that worked for some backwards organization and threw them into a completely different organization, even if he didn’t choose that, I feel like that individual would adapt very quickly. There would be some uncomfortableness, but it would be relatively minor.

Now, if you were to do the opposite case, where you have one person going to an organization and radically changing that organization, everybody has to change. That is way more painful, if you try to do that at speed.

Clayton:  I think going as fast as the most aggressive person, I would say there’s probably a good chance that you’re going to throw the baby out with the bath water.

Jade:  It feels reckless, to me.

Clayton:  Yeah, exactly. If I’m doing it just for the thrill of speed, I want to get to whatever the next state is, in my opinion, as fast as possible. I think you probably risk losing people, insights or whatever, that would be beneficial to the whole group, because you’re trying to go so fast.

I would also say it’s a two‑way street. The person that wants to go super slow and be comfortable, the Agile community is very good at trying to analyze that problem of why is this person wanting to go slow, what are they afraid of? Blah, blah, blah.

Then the people who want to go as fast as possible, there’s fears on that side, too, that we don’t address. I would say the people that want to go as fast as possible are probably not very common.

Roy:  They’re probably afraid, too. They’re afraid that the change that they want will never happen, so if they don’t go fast enough…

Clayton:  There’s some reason that they want to go so fast.

Roy:  It would be like “Speed,” where if they drop below 50 miles per hour, the bus explodes.

Clayton:  I haven’t seen that yet, Roy.

[laughter]

Jade:  We’ll save you the trouble.

Clayton:  I’m trying to go through Sandra Bullock’s entire catalog.

[laughter]

Clayton:  I think we probably ignore the fact that there are a lot of reasons why people want to go super fast. I’ve seen that in organizations where people get the bug to change something and they say, “Oh, cool. This is an opportunity to change everything.”

For whatever reason, they’re unhappy with what the status quo is, and they want to change everything. I agree. It seems reckless. I’m not sure where we’re going, but we’re not here anymore.

Jade:  We’re not stopping to find out.

Clayton:  Yeah, exactly. We’re going as fast as we can.

Roy:  Doesn’t that sound fun?

Jade:  Sometimes, maybe.

Roy:  You don’t know where you’re going to end up, that sounds like a great time.

Clayton:  Yeah, I guess it depends where you end up.

Roy:  No, it doesn’t. It’s not about the destination. It’s about how you get there.

Clayton:  I would have a lot of fun going on some adventure, but then if we ended up in the middle of nowhere, I’d be like, “Hmm. The honeymoon’s over, I don’t want to be in the middle of nowhere any more.”

Jade:  Yeah, I’m the same.

Roy:  That makes you lame.

[laughter]

Jade:  We have an interesting mix on our little group. Derek’s not here with us tonight, but Roy and Derek are much more on the aggressive side. I’m definitely on the more conservative side. I think you’re there with me, too, Clayton.

Clayton:  I would say I’m more concerned about I want to go somewhere. I’d go on an adventure, as long as it’s the one I want to go on.

Roy:  I’m the exact opposite. Your thing of, “I don’t know where I’m going to end up, but if I end up in the middle of nowhere, I’m going to be upset,” that’s every weekend for me and I’m not upset.

Clayton:  Right, that is true.

Jade:  Then we’ve had some good experience in our past of changing rapidly, trying new things, doing things. Why does it work for us?

Clayton:  There is something about the fact that we really actually believe in iterative approach to things beyond building software. You had started out by saying we’re OK with changing because we know that’s not the end state. It’s just the next thing and it will help us change faster. I think that’s a big part of it.

Also, the fact that we’re willing to call a duck a duck and say, “Hey, look, we tried this thing and it failed. That doesn’t mean we’re failures.” Maybe the actions we took or the outcome we had was a failure. It wasn’t what we expected or what we wanted, but that’s OK. Let’s try a new thing.

Those are two things that have made it much easier for us to be successful, but I would argue that maybe starting out early on, it was super painful, probably had a lot of fallout and wasn’t as successful as maybe we remember it, so.

Jade:  I remember the early days being terrible, going home so frustrated and upset every might. Yeah, it definitely wasn’t an overnight thing that happened. It took years for us to get to that point.

Clayton:  I would say also, having multiple perspectives. Coaching a client that is going slow and watching it unfold at a certain pace, maybe a pace that you’ve already spent a lot of time going, it’s much easier to see it happen. To them, it’s happening at 80 miles an hour, but we’re watching it at 8 miles an hour and so it seems like a slow‑mo.

Roy:  I’ve seen this racecourse. I know every turn. Let’s beat this up and get to the end.

Clayton:  Well even if from a cooking perspective, you’re not really concerned about getting to the end, but you are interested. At least you have different perspectives on, “There’s this corner coming up. How are they going to handle that? I remember that and I remember it being precarious.”

Roy:  It doesn’t strike me as, “Nobody cares, get over there.”

Clayton:  Yeah.

Jade:  How would we help people who have realized that they need some level of change in their organization at some part of their organization? How are we going to help them find that right speed that they need to be going, not too fast, not too slow, being effective, but not reckless?

Clayton:  I think there’s just course correction that probably has to happen. I don’t think that you’re ever going to get it right. It’s really hard to dial it in the first go.

Roy:  It’s really hard to dial it in on any go.

Clayton:  Right, so I would say chances are, if things seem like they’re going well, then maybe that means you’re going too slow. If things start feeling like they’re totally out of control, maybe you need to slow down a little bit.

There’s probably something. A big component is probably just having the self‑awareness of, “Am I being afraid or is this actually working?” Or, “Am I out of my comfort zone or am I just telling myself that?”

Roy:  I think it’s like that, being wary of and aware of the idea of recoil, as well. Like that feeling you get when things are going successful and it’s almost creepily successful, where you want to back off because all of a sudden…

Jade:  You start becoming negative about it, just because something in you is forcing you to deny it that it’s happening.

Roy:  It’s almost like emotionally hedging your bet in case it doesn’t actually end up being as successful as you think it is.

Jade:  Yeah, I’ve seen that a lot. We still do that a lot.

Clayton:  I would say, for me, a phrase that I had read a long time ago that I like is, “If you want something that you don’t have, go do something that you haven’t done before.”

If I want some outcome where I think that my organization needs to change and this is the way we need to go, I probably can’t do that if I’m going to do the same thing I’ve always been doing. I’m going to have to do something different.

Chances are that something different means being uncomfortable to some degree. My rule of thumb is, I know I’m not improving or excelling, or maybe going as fast as I know I should be, if I’m not uncomfortable.

If I’m pretty comfortable every day, going into the office kind of thing, I’m probably not getting any better. That’s like a self‑awareness check of, “Am I uncomfortable today? No, not really.”

Jade:  I think one of the key ingredients is getting a small group of people who trust each other, who have different perspectives to be able to work together. That’s one thing that’s worked very well for us is, we are very different and we look at things differently.

When things are happening, we’re all bringing a different way of perceiving what’s happening to the table. Then we can argue and yell at each other, and get passionate and emotional about those things, but it’s not personal because we trust each other. We know that we’re trying to do something together, something better.

Ultimately, the best ideas tend to surface out of that, because it’s not just one person’s idea or perspective that is being dictated out to everybody else. That’s a key ingredient, finding that right speed.

We can meter ourselves because some people are going to be pulling, some people are going to be pushing, some people are going to be holding back. We’ll find that right speed as we go.

Clayton:  I agree with that.

Roy:  Cool. Yeah.

Jade:  All right, well, thanks for listening. We’ll catch you next time on the “Agile Weekly Podcast.”

[music]

Jade:  If 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 a way to stay up to date with the latest news, techniques in the Agile community? Sign up today at agileweekly.com. It’s the best Agile content, delivered weekly, for free.

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

Announcer:  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.