The Agile Weekly crew regularly discusses topics related to agile, scrum, kanban, extreme programming (XP), software craftmanship, systems thinking, retrospectives, teams, culture and software development.
Do We Need Agile Process Frameworks Like Scrum?
Jade Meskill: Hello. Welcome to another episode of the Agile weekly podcast. I’m Jade Meskill.
Roy van de Water: I’m Roy van de Water.
Derek Neighbors: And I’m Derek Neighbors.
Agile Process Frameworks vs Individuals and Interactions
Jade: I thought today, we’d talk about something, maybe a little controversial. Do we need frameworks?
Roy: Like Rails?
Jade: Maybe like Scrum. What do you guys think?
Derek: No. Yes. No.
Roy: It’s one of those things where they’re helpful to get started by get in your way after a while, but you think they get in your way a lot sooner than they actually do.
Derek: I like to say, if its individuals and their actions over process and tools. Why is it the first thing that we default to add to lists are hey, you need to learn a bunch of process? I think, no, they are not necessary.
However, it’s very hard to do things well if you don’t have any discipline. What process does is it allows you to learn how, as a team, to be disciplined about the work that you do. It helps highlight issues that you have that can help you improve. Basically it builds off of work that people have done before.
We know that all these things tend to really keep teams from performing well. If you’re not cross‑ctional, if you don’t have a concept of time boxing, if you don’t have a number of these things, you tend to struggle.
We’re going to go ahead and put those things before you. Learn how to use them, and as you learn how to use them, you can shed them away and probably still get really good results.
I’d say, yes and no, I don’t think you need process. Do I think that it’s hard to be good without having some guide rails to explore how you work? Yes.
Agile Process Frameworks as Guide Rails for Novices Only? (Dreyfus Model)
Roy: I think some of it comes down to pragmatic thinking and learning talks a lot about the Dreyfus model and how early on you need rules because you don’t have enough knowledge to make your own decisions. But that rules ruin experts, and all these people that have lots of experience are now hindered by having to follow these rules when they should be trusting their intuition.
Derek: People tend to find themselves being experts far before they’re really experts. That’s another problem there is. I call it the so f*****g agile. We’re so f*****g agile that we don’t need to do XYZ. I can turn on the dime. I can respond to anything. I was just like, Yeah, so you’re in chaos. That’s really great.
I don’t consider that agile. Never getting anything done because all you do is respond to every stimulus that comes your way does not make you good. It makes you undisciplined. I think that that’s difficult thing.
Roy: I think that’s the careful distinction between thinking that you’ve arrived, that you’re there and that you’ve finished adapting Agile or whatever or finished improving and the idea of, I think I’ve grown these rules but I still need to improve and try new things all of the time because I’m not even close to where I want to be yet.
Derek: Yeah, so the litmus test I use is if somebody believes that the rules don’t belong to them and they don’t want them. They’ll throw a fit if they have to follow rules, they’re probably not really a master. If somebody says, I think that these rules could be bent but I don’t really have a problem with the rules and if it’s going to cause you all sorts of grief to not adhere to these rules, then fine, I’ll adhere to them.
I generally find that’s the person that’s probably OK without actually having rules because what they’re saying is, I don’t think the rules hinder me so much that I can’t be effective, but I do think I know the rules well enough that when they need to be bent in certain ways, I could get more performance out of them.
Where the amateur tends to say, I just don’t want the rules at all. Any r
The Trade Offs of Organic vs Prescriptive Agile Coaching
Jade Meskill: Hello. Welcome to another episode of the Agile Weekly podcast. I’m Jade Meskill.
Roy van de Water: I’m Roy van de Water.
Clayton Lengel‑Zigich: And I’m Clayton Lengel‑Zigich.
Prescriptive Agile Coaching Trying a New Approach
Jade: Clayton, you’re trying a new approach to coaching a team you are working with. We wanted to talk about that a little bit. Tell us a little bit about what you’re doing.
Clayton: A little bit of background. The team is this collection, I wouldn’t say misfits, if you’ve seen the movie “Bad News Bears” it’s kind of like that.
Roy: Wow. I have not.
Jade: [laughs] Imagine that you have.
Roy: Is it like “Breakfast Club”?
Clayton: In that there are people in the movie, yes. It’s the same thing.
Roy: Is it like any of the three “Star Wars” movies?
Clayton: OK. There’s this collection of misfits and the approach I have been taking was I wanted to be prescriptive about some things. I go back and forth between organic learning or being really prescriptive. I thought I want to be kind of prescriptive because I want to accelerate things, but I don’t want to be prescriptive about stuff like process. I don’t want to say like, “We have to do stand-ups” or “We have to do Scrum” or “We have to have a product owner.”
But I thought, “What if I’m prescriptive about the principles and the values?” As far as being prescriptive goes, that has actually gone pretty well. Things like being open about what we’re working on, visualizing the work, collaboration, and all those kind of things. Then the other approach I’ve been taking that’s actually probably had the most benefit there’s two things.
One is I’m pretending like they’re already an awesome team. When topics come up, rather than saying like, “I’ll ask a question about something like, “How would a team handle this?” Rather than saying like, “A high‑performing team would do X, Y, Z,” I’d say, “Oh, I think maybe if you guys did this, that would work.” They look around. The next part that comes in is “You can do anything you want.”
I always laugh when Jade does the, “You can do anything you want, but there are consequences.” I’ve been trying to get them to believe in this kind of fantasy land where they live in this reality where they’re already awesome, and they can do anything they want. Some of the things that I’ve done on accident that have helped a lot, we set up pairing stations. One of the things that I was being prescriptive about was collaboration.
Rather than trying to work on a bunch of these different projects all at once with a bunch of different people siloing, I said, “Hey, let’s set up a pairing station.” I actually did that for them and made it really easy to use them. It worked out in my favor that no one’s machine was set up to work on any of the projects, and the only machine that was was the pairing station. I just grab [indecipherable 2:27]
Jade: This was a team that hadn’t paired before? They were not
Clayton: Yeah, they’d had a little bit of exposure but not really.
Part of the pairing station problem that we had was the monitors were really bad. I went out one day, and I just bought new monitors. I came back and they were all like, “Wow. How did you get new monitors? You didn’t go through IT.” I’m like, “Yeah, I just went and bought them”. They are like “you can do that”? I wasn’t trying to make a case on this but I was like “Yes, I can, I’m an adult. I went to the store and I purchased them and there was this transaction and now we have new monitors”.
It was totally an accident but that was I think the first time they saw “Oh, wow, you really can do anything, there was this thing that I thought was impossible but then you did it”. All the conversations we have b
How Praising Effort Incorrectly Negatively Affects Your Culture
Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.
Jade Meskill: I’m Jade Meskill.
Derek Neighbors: I’m Derek Neighbors.
Roy VandeWater: I’m Roy van de Water.
The Love of Lazy
Clayton: Today we are talking about my favorite thing, being lazy.
Jade: Oh my gosh, that’s my favorite thing too.
Roy: Do we really have to talk about it?
Jade: I don’t know.
Clayton: [laughs] I don’t want to think about it. That’s too much.
Jade: [laughs] Good thing we can talk without thinking.
The Obsession with Rewarding Effort and Hard Work
Clayton: So many more jokes to be made.
This topic, Jade and I talked about this at lunch. It sounds like, Jade and Roy, you’ve been talking about this a lot. The concept stems from a lot of the clients that we’re working with.
We see these teams where they do a whole bunch of work, work, work, work, work, work, and they get praised for all their effort. At the end of the sprint they didn’t really deliver anything of any value, they didn’t really ship anything, the customer’s not delighted. But boy oh boy, they worked hard, and everyone in the room is clapping for them.
That feels really disingenuous. I think I heard someone the other day talk about how they stayed up till 5:30 AM tweaking these servers. I thought to myself, “Man, if I had to do that, I would be very upset. I would probably find some way to automate it.”
Roy: I’d shoot myself in the face.
Clayton: Yeah, that was my next way of saying that.
The Hero Culture
Jade: I remember living in that world, though. I was definitely part of the “Hero” culture. I could always be counted on to work the extra hours, or do whatever it took to get the job done. I’ve wizened up since then.
Clayton: I think it’s interesting because I think we have an “Automate everything” mentality, but there’s so much stuff now that…I used to do that, maybe be the hero, or you want to work the extra hours or whatever. It felt good to do that, like you were contributing a lot, but now it just feels dumb. I’d feel stupid if I do that.
Jade: I do too. Roy and I were talking about it the other day. I said, “If you find yourself working that hard to get something done, you’re probably working wrong.” It is so easy to get away with automating a lot of things, not having to do that much work. The problem is, there’s definitely a stigma against being perceived as not working hard.
Separating Value from Effort
Derek: I think my goal in life lately, maybe it’s why I’m a little more interested in robotics lately, is to replace myself with some form of automation. That is the pinnacle. I think what happens is, people do think that, “If I’m not doing something all the time, people are going to think I’m not valuable.”
I keep saying, what is it that makes us think this way? I can’t remember if it was Carlos Segura , or a designer of some kind. He’d said something very profound to me, at one point during a talk.
They basically said, “I make three million dollars for giving somebody a logo, and that logo only takes me about an hour or two worth of effort, to actually make the logo. My value is in knowing what to make for a logo, and that’s why I’m worth three million dollars.” The guy who makes the Nike Swoosh, we can all laugh at, “Man, that’s so simplistic!” Think of how valuable that is, or the Coca Cola logo, or whatever.
We focus on things that are very low value, and we think that we just have to put in a ton of effort to get any kind of result. I like to say that you have to put in a ton of effort to become an expert, and to become good, to know what the right logo is to do. But that’s not the same thing as, then every logo thereafter, you have to put in tons of effort to get there.
I think that’s the misnomer, is people just
Automated Testing, Everything That Can Be Automated, Should Be Automated
Jade Meskill: Hello. Welcome to another episode of the Agile Weekly Podcast. I’m Jade Meskill.
Roy vandeWater: I’m Roy vandeWater.
Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich.
Derek Neighbors: And I’m Derek Neighbors.
Automated Testing Struggling to Go Fast
Jade: Very nice. Derek, you had something you wanted to talk about. What was it?
Derek: Yeah. I’ve been doing the work with a number of teams, and one thing that I’m starting to see emerge as a pattern is the team’s struggle to go fast. They struggle to work particularly within the Scrum framework a lot of times. Not only are they siloed where they got developers and QA that are separate, but where they don’t have a lot of automation. This could be automation around deployment.
This could be automation around testing, so maybe they don’t have an automated testing suite. Or if they’ve got some automated testing suite, there’s still some manual regression happening. Even if they have a fully automated testing suite, they’re not running it automatically.
They’re not having continuous integration, or it takes an enormous amount of long time to build. What I’m finding is it’s very, very hard for them to see what performance looks like, because they can’t get over the concept of their current reality. The current reality is, “Hey, it takes five days to run the test suite. There’s no way we can have a one‑week iteration. That’s just impossible. It takes us one week just to test, once the developer’s done with a feature.”
Have you guys seen instances, where maybe the current reality or the lack of automation makes it so teams just find…I had somebody specifically today, tell me, “That’s really nice that you stand up there and talk about a 10 minute build. Frankly, there’s no way you’ve ever done that before, because I’ve worked for five different companies, and none of them have ever been able to do that. I find what you’re saying impossible to believe.”
Jade: [inaudible 02:06] we have a 10 second build?
Roy: Yeah. I agree. I’ve struggled so hard to get a build to take 10 minutes. I don’t believe it’s possible.
Derek: In their current reality, I understand that. If you’re a manual regression tester, and you’ve got a fairly complicated suite, it’s taking two or three days to run a single test plan. I can understand how it feels impossible that you could, with any level of comfort, run a test suite under 10 minutes that made you feel like you weren’t shipping crap.
Roy: We’re working with the team right now, but we’re not working with working microphones.
Letting Technology Get In The Way
Jade: That’s right. We are working with the team right now that a single test takes two weeks of constant computation, a single test.
Clayton: I’ve seen that in a lot of instances where, the technology gets in the way. If you’ve got a java applet that loads a Swf, how do you automate testing of that content? That seems like this impossible thing. I think a lot of people say, “It is what it is, throw my hands up in the air. What else are we going to do but, let those hourly regression people slave away at typing in commands and looking at the screen”?
Roy: Along the idea of trying to test a flash out, I think that’s one of the first mistakes that immediately causes your test suite to get larger, and take longer, regardless of whether it’s manual regression or automated testing. That’s when you write the test case last, after everything is done.
Test Driven Development Helps Reduce Some Problems
Derek: When you write the test case first, you end up using solutions that are easier to test. You don’t run into those things.
Clayton: That’s one of my favorite things about doing, not even just TDD, but just test first. Where you have to take into account what easy to test and what isn’t. I’m working with
Agile Team Standards, Finding the Right Balance for Efficiency vs Innovation
Jade Meskill: Welcome to the Agile Weekly Podcast. My name is Jade Meskill.
Derek Neighbors: I’m Derek Neighbors.
Roy vandeWater: I’m Roy vandeWater.
Clayton Lengel-Zigich: I am Clayton Lengel-Zigich.
The Efficiency vs Innovation Problem
Jade: Derek you had a topic that you wanted to talk about today. What is it?
Derek: Yeah, something I’ve seen a lot lately is when teams start to really get agility they really start to get high performing. One of the things they tend to do is go around roadblocks. They tend to start to basically, maybe choose some things that the higher powers in a large organization aren’t comfortable with them choosing. There becomes this divide that starts to say, how come you’re not following standards?
Whether those standards are set or whether they’re not set. Whether it’s an architecture thing. Whether it’s a language choice thing. Whether it’s a process thing. You name it. At what point does being agile in supporting the best ideas, and moving forward, and having the people closest to the work make the decisions about the work start to compete with centralization and efficiency?
The problem is if everybody uses .NET, then we get the benefit of people can jump from team to team, or we get all the benefit of being experts in .NET. But if you’re doing Ruby and I’m doing Java and you’re doing .NET and you’re doing C# and you’re doing whatever, now we lose all of this efficiency.
There’s this tension between “We’re trying to be innovative and just go as fast as possible” versus “Don’t you want to be efficient, and have standards that we get benefit, or this economies of scale?”
What have you guys seen in that area? Where do you sit on that sort of thing?
Jade: When you started talking about this I remember a time when our team had started to deal with some of this, our Integrum team, and tried to standardize on certain libraries, and certain techniques, and things like that.
We kind of went through this phase, exactly what you were talking about. From what I recall it was a total disaster. We were even using the same language at that point in time.
Derek: If you guys would all just use Emacs I wouldn’t have been such a [inaudible 02:19] about it.
Jade: [laughs] It really hampered the ability for teams to make the right decisions that were right for the project that they were working on. It became this whole committee situation, and in the end we completely abandoned it, because it was not functional for what we needed.
Alignment on Best Practices to Minimize Pain, Openness to Explore
Derek: I see a couple of benefits and problems with it. I think that it’s nice to have things standardized. The thing I can remember at the time was, everybody was setting up servers a different way. When I had to deal with a problem with some client, and I went to go log into the server, shit was all over in different directories. People were using different stuff. When you really talked to them, there was no like, “Oh, we did it this way, because of this.” It was just, “Oh, I don’t know. I liked Apache, so I used Apache even though everybody else was using Ngnix.
Great. Add in an extra four hours to me, figuring out what the problem was, because everything was non-standardized. I think one of the things that we started to do that worked really well, was to treat things more like an open source project. If somebody had a good idea, people would support that. If people wanted to fork it or do something else, there wasn’t a whole lot of, “No, you can’t do that.”
But if it bit somebody else in the ass, people were not nice to you about it. It’s like, “Hey. If you weren’t going with the best idea that everybody had, fine, that’s great. Do your own thing. But don’t expect a whole lot of support when you’re out on the island all by yourself, and you’ve gotten yourself into trouble.” I remember one distinct incidence whe
Multiple Commitments and Multitasking in Agile Organizations and Teams
Jade Meskill: Hello, welcome to the “Agile Weekly Podcast”. I’m Jade Meskill.
Derek Neighbors: I’m Derek Neighbors.
Roy vandeWater: I’m Roy vandeWater.
Why Do We Fall for the Multitasking in Agile Trap
Jade: Today, we wanted to talk about the dangers of multitasking in agile and maybe a little bit about multiple commitments. Roy, we’ve been having some trouble with this lately.
Roy: Self-imposed trouble.
Jade: Yeah. We should know better but we still fall for the trap. Why do we keep trying to multitask?
Roy: I don’t know. I think it’s our arrogance and thinking we’re different, and that somehow it’s going to work for us when we know it doesn’t work for anyone else.
Jade: So, because we’re really good at this, we can multitask in agile when all other humans can’t.
Roy: Right, even though it’s miserable and no fun at all.
Jade: What do you think Derek? Have you struggled with multitasking in agile?
The Organizational Multiple Resource Trap of Splitting People’s Time
Derek: I’m too dumb to do one thing, much less two things at the same time. I see a lot of teams struggle with it or actually organizations. Well, I see teams and organizations. I see organizations do it with the multiple resource trap.
I think of somebody is this logical thing that has 100 percent. Because I think of them as this logical binary bit of 100 percent, I can take 10 percent of them and give them over here, 30 percent and give them over here an 60 percent and give them over there.
On paper that sounds really fantastic, but for whatever reason it just doesn’t ever seem to pencil out quite right. I see that trap a lot.
Tearing a Person in Half is a Powerful Metaphor
Jade: Interrupt you real quick. That reminds of a cool exercise I did once with a group of managers, who were really struggling with understanding why nothing was getting done. I had them write out an individual’s name on an index card. I had them do that for their entire team and then I had them go and layout all the projects that everybody was working on. We put the projects up on a board and then I had them say like, here’s John.
How much of John is working on Project X? They said, oh about 20 percent. So, I tore about 20 percent of that index card off and you should’ve seen the look of horror on people’s face that I’m like tearing this person into pieces.
I stuck that up by the project and said all right how much is on this and that? We went through and by the time we were done there were these tiny little scraps of people everywhere all over this board.
Because they had way more projects than they had people and that visualization of that problem really sunk in, that holy crap we are really doing something very very wrong.
The No Projects Movement Time Fallacy
Derek: I think that’s becoming a common trend very similar to the no estimates hoopla, I think you’re starting to see a no projects thing emerge, which is…
Jade: Is that from you? [laughs]
Derek: No, I said it a few years ago and kind of dropped it, but I think people are picking it back up. I think what people are realizing is that when you do things by project. Projects ramp up, and ramp down, and have overlap. You have to start tearing people. Pretty soon when you do that, you get 10 percent of people and the problem is that it’s never that clean.
When I say “Jade, 50 percent of your time will be on this, and 50 percent on this other thing, and Roy, 50 percent.” What happens is the two projects both need 100 percent of you at the exact same time. It’s not one week I need 50 and one week I need 50 and it works out great. I need all of you right now, and the next week I don’t need you at all. It never is during the same time, so you just get into this total chaos that starts to ensue.
It’s crazy to see how much it helps people to not have that burden, to not be a slave to multiple masters. When they can just say, “I’m d
Short burst conversations on relevant topics
I like the style these guys use of posting short, conversational podcasts on relevant topics for agile and corporate software development in general. I don't always agree with their point of view, which means they are probably picking worthwhile topics and eliciting some good discussion and points to think about.
These guys are doing a great job! They bring up a wide variety of topics that we’ve all engaged in before, but their points of view and arguments are extremely well communicated, and informed.
Great content for someone trying to get their organization to agile
I'm one of three developers on a team trying to be agile inside a much larger defense contractor organization. Most of the discussions in this podcast are relevant to my daily work. I really like the fact that this discussion goes beyond the discussions you'd get from a scrum training class, and instead really focuses on the real goals behind the practices.