Episode #148 – What’s a Culture Fit?

Agile Weekly — Thu, 25 Jun 2015 06:00:09 +0000

Derek, Clayton and Chris slowly remember what they were talking about… Oh ya! Culture Fit! Including mono-cultures, hiring, diversity of ideas and behaviors enforcing culture.

What if we could instantly see the status of our automatic test build without having to tab out of our editor?

For our Ruby on Rails projects we use Guard to monitor file changes and instantly run our specs. We had previously written the initial tmux notifier and using other notifiers that guard provides, yet it wasn’t quite good enough. We practice ping-pong pairing and red-green-refactor in extremely tiny iterations, there is a lot of tabbing out of the editor to check the status of guard.

We wanted to know at a glance: Has it even started running yet? What was the previous status? Is it running a focused spec or the whole spec suite?

Unfortunately the Blink(1) was out of stock (and still is as of this writing), which made it hard to replicate on other machines and spread to more teams. I kickstarted the BlinkyTape project and it recently shipped. The BlinkyTape is even more amazing, and much more visible. We wrote an Arduino sketch, a ruby gem, and an easy way to integrate guard.

We have quickly become addicted to this setup and find it slow and difficult to work without it. I can’t wait to see what amazing ideas others have.

Here are some sample shots of what it looks like in action.

The post Instant BDD/TDD Feedback With BlinkyTape appeared first on Integrum Values and Principles

We value courage. Be transparent with our team and our clients. Have the strength to say what they need to hear, not what they want to hear, but be open to other people’s feedback and opinions.
We value dreams. Dream big. Empower others to achieve their goals, maximize their potential, and change the world.
We value love. Care for people enough to help them see their potential. Confront conflict head on, and commit to resolving it and strengthening your relationship.
We value family. Treat each person on our team as a family member. Trust them, confide in them, and support them without fail.
We value excellence. Demand the best from each other and our clients. Never settle for mediocrity.

Transcript

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

Derek: I’m Derek Neighbors.

Clayton: I’m Clayton Lengel‑Zegich

Roy: And I’m Roy Van De Water.

Jade: Guys, today we wanted to talk about an article that will be published in Agile Weekly tomorrow.

Roy: Product tie in there.

[laughter]

Jade: Subscribe to the Agile Weekly Newsletter at AgileWeekly.com. Written by Allan Kelly, the title is, Commitment Considered Harmful. I know we have no opinions or thoughts about this, so this might be a very boring podcast.

Roy: I’m curious, why is commitment considered harmful? By who, maybe is a better question?

Jade: Allen has to say that he has seen through some of his interactions with clients and other people, that…this is a quote from him. Commitment protocol for filling an iteration is actively damaging for software development teams in anything other than the very short‑run.

Derek, you’re shaking your head.

Derek: I don’t know. Maybe it’s too many years of therapy coming out.

Jade: Too few?

[laughter]

Derek: If I follow the trail…when I first saw this article, I immediately thought that it was part of the no estimates crowd shtick of stuff.

Jade: He specifically states that he does not follow the no‑estimates crowd.

Derek: Yeah, but I certainly thought it was going down that route. What I tend to see is this pattern of, there’s something, there’s something, there’s something, and it’s all rooted in two things. Every software manager is evil and the people will manipulate the system or me.

To me, going back to McCarthy’s core protocols and the perfect boss, I expect to work in a place with fucking adults. At some point, how long can we basically say, the boss might manipulate me? Well then go to a fricking job that doesn’t have a boss that manipulates you.

That’s got nothing to do with commitment. The boss that’s manipulating you with commitment or estimates is going to manipulate you if you don’t have commitment or estimates either, because they’re a manipulating asshole.

Roy: Yeah, that argument’s just too broad. You can replace whatever with, there’s this thing that some people have used, so you don’t do it.

Jade: Let’s step back a second, though. We do a lot of consulting. We’ve been to a lot of companies. How many have you showed up at that are full of fully functioning adults?

Derek: Not a ton, but I think my problem is attack that problem. Don’t attack the lack of commitment as being a problem. I hear commitment. I hear estimates. I hear accountability. I hear all of these things.

The very first thing that was thrown out here is, “Well, you can’t have commitment, because people will game it.” Well, people will game anything. So if you have a culture that is OK with people gaming things.

Roy: We talked about it in the past that‑‑what is it? I think, Jade, you quoted somebody that said, “96% of a person’s ability to self‑improve is dictated by the system.” Do you remember who that was?

Jade: W. Edwards Deming.

Roy: There you go. That may be the same problem in this case. What if it is a culture of a commitment that is holding these people back from becoming the adults they can? Because they are currently being rewarded for making false commitments or for gaming the system.

Derek: Right. I would argue that in that point they’re not really making commitments. The word ‘commitment’ is being bastardized to control somebody to say, “You have to tell me how much you’re going to do,” and then I’m going to threaten you, or lord over you, or manipulate you.

Jade: They’d beat you with a stick.

Derek: Beat you with a stick, beyond that. Well, to me, that’s not a commitment. A commitment is me saying what I really can believe, and me truly believing in that and doing that. That’s not somebody else saying, “Hey, Jade. I want you to commit to mowing my lawn tomorrow. All sorts of bad things are going to happen if you don’t mow my lawn. You’re OK with that, right? Your job is depending on it. You’re OK with it?”

I feel like to me, that’s not a fair thing for commitments, or for estimates, or for anything else.

Jade: No. I think that what we would argue if we were working with a team, and they said, “Well, we’re doing commitments.” I think from our point of view, we would say, “OK. Why don’t you look at the work that you do?” Maybe the team, they look at one story, and they say, “This is all we can do.”

The manager, I think the way that people abuse commitment, and say, “Hey, you guys have 150 hours over the next sprint, that all you are going to be working on this.” You have to have 150 hours of work to do.

I think we would say, “If you want to commit to doing 20 hours of work, and that’s all you want to commit to, that’s all your going to commit to.” That’s an acceptable scenario, as far as I think we’re concerned with how commitment works. That’s now how most people… Bad managers aren’t going to abuse that, and so that comes out his commitment is bad.

Derek: What about the idea though, if you’re feeling rushed, and that making the commitment is the most important thing above all else, like keeping to your word, the idea that you allow quality to suffer because of that. That you might choose to take some shortcuts or to cut some corners, because you are trying to push it out the door.

You don’t necessarily do all the good practices that you want to have, and maintain a quality suffer project. Those things will buildup over time to create a ton of technical debt that you can no longer maintain.

Jade: Yeah. That’s just part of, I think, if you’re committing to doing something and you have some standard for what it needs to be done. If the standard of done means half‑assed, then, OK, fine. No, that’s not really how you want standard done.

I think that is part of the bigger picture of, “What does it mean to be done?” If we’re going to rush through something, are we really done? Did we really “hit our commitment”? Probably not.

Derek: I think that it’s kind of the straw man out there, right? People like to throw it out. I see so many teams that have no sense of commitment that have really crappy quality.

Like to me, those things are not linked. I think what happens is when somebody is forcing you to the trough to drink water and really just slams your head in, you’re going to do stupid things. But I don’t think that’s because commitment is bad.

I would say that a team that is truly committed and committed in everything they do, they say, “Hey, we’re going to have…we’re going to write tests first. We’re going to make sure that our product owner is happy with the work that we’re doing. We’re going to commit to all these things and we’re going to commit to do what we say we’re going to do.”

You can’t say, “We finished everything, but it doesn’t meet the product owner’s requirements and it’s not tested and it’s not…” because at that point you don’t have a commitment either.

Jade: But technically, it’s done.

Derek: I know…

Jade: The way you said, the phrase, “Do what you say you’re going to do.” I think that was a big shift that we had an [sp] integrim of the concept. It sounds so simple, right? Do you what you say you’re going to do.

I think that’s really to me is what commitment means. I’m going to say I’m going to do something and then, I’m going to do it, but that’s not easy.

Derek: No. It’s not easy and I think commitment isn’t easy. Like committed to do something is difficult, right? But it doesn’t have to be this, you know, abusive tool.

Jade: I think to me the thing that I really love about Agile when it’s done really, really well is it becomes the truth killer. So if you can go around and say, “My team is so awesome. I’m so awesome,” and all this stuff and make all these promises and never, ever fulfill them like you’re just a lying piece of crap.

Who can trust you? Whereas, if you say, “Hey, I can only do this really, really small thing,” but I think a lot of developers have problems with this because when they say, “Oh yeah, I can do this. I do this,” and somebody says, “OK, so you’re committing to that and I’m going to kind of hold you to that. Let’s talk about it at the end,” and then, you can’t do it.

The developer doesn’t say, “Man, maybe I think I’m way full of myself and I should not commit to nearly as much, less time, next time. I should commit to half of that, because I didn’t even get close.”

Instead they say, “Well, the problem was this and the problem was that.” Everybody else in the world was the problem and it wasn’t me.

I think that’s just…if you’re honest with yourself about wanting to improve and you really want feedback, the only way you can do that is to measure yourself. So if you’re not saying, “I think I can do X,” and then, going out and doing it and measuring can you do it, how the hell can you improve?

Derek: So we can go from the standpoint of commitment adds at least some level of stress to the…

Jade: True, it does.

Derek: …to the developer, right? Because now they are kind of freaking out about this promise that they made and trying to keep it. But what positive benefit does a commitment actually get?

If I’m a developer making a commitment, what benefit do I get by, other than stressing out about it? Is that stressing out, is that the benefit that I get? That I get more accurate at estimating sounds, I get more accurate at committing sounds great.

But getting better at committing if committing itself doesn’t give me any value, am I just getting better at something that doesn’t matter?

Jade: I think you can build some trust. Or if you say you’re going to do something and you do it and you repeat that multiple times, you can build some trust that when you say you’ll do something, you’ll do it.

I think, it also is a discipline thing. Having a commitment, I think, helps you be disciplined. Discipline, I think, is a very difficult thing to have in software development.

A lot of teams lack that and I think that’s just another mechanism that helps reinforce that.

Derek: I think the other thing is commitment is a two‑way street. It’s not just the developer who’s committed. The idea is that I’m saying, “I will do this if you don’t bring in anything else to me to do during this period.”

Jade: Like the [sp] Schrum?

Derek: Yeah. I mean, I think it’s part of the whole contract. So when people say, “Like we do Schrum, but we don’t do this and we don’t do any of this stuff.” It’s like, “Well, how can you even live up to the basic premise of Schrum, which was we’re going to agree to do X, Y, Z, you agree to leave us alone?”

One of the things I’ll add is any developer out there that thinks that estimates, commitments, everything else are horse crap, come work for me and let’s talk about how we pay you. Is every week I’ll decide what we pay you?

I’m not going to tell you what you get paid until after you’ve done the work and it’s entirely negotiable up to me whether I think you deserve the money or not. You may get money. You many not get money and you’re going to be happy about it.

That’s what you do to every damn product owner you work with when you have no ability to say, “This is what you’re getting.” They’re spending money on you. They are giving money to you to do a job.

If you don’t do what you say you can do, and you continue to extend…this is why so many companies have problems is contractors or independent third‑party companies where they get to the point where they’ve not delivered what they said they were going to deliver and everybody ends up pissed off and everybody gets sued.

This is why this happens. I think it’s almost juvenile or naive to think, “Why can’t we just meander and do whatever we want and you just pay us?”

Man 2: This state of affairs would be totally unacceptable in just about every other industry.

Derek: Sure, it would be.

Jade: What is it about software development that allows people to think that that’s OK?

Derek: It’s creative. It’s an art. It’s an unknown magic. I give money to this group of people that have weird social habits. That I do not understand and I have never experienced them before. They do some magic.

The type of the keyboard and magic happens. Then, they have this thing that I cannot possibly understand how it works. I could never possibly do it myself. I couldn’t learn how to do it.

So, I just have to keep appeasing the magic over here.

Jade: But this happens to people that do understand that world as well.

Derek: That goes back to the hope thing, then, right? If people are hoping that…at the beginning of this, you could have the worst possible sprint and have a retrospective where you’re talking about all these terrible things.

A lot of times when the sprint planning starts the next time, it’s like, “OK, we have a clean slate. Everything’s in the air for this time. Everyone is very hopeful.”

Because people want to be hopeful, right? They want to think that this time’s going to be different. So they repeat the same mistakes.

Jade: Robo Roy did you have something to say?

Roy: If I hold this is in, maybe it’ll get better. It’s getting better.

I think that’s one of our things is we don’t see ourselves as developers. Often times, it’s somebody delivering a service of some kind and having an output. I think failure is OK.

I think it’s entirely OK, but the failure shouldn’t be that we aren’t able to deliver something. It’s whether what we deliver or not necessarily is usable or meaningful, right?

We should be able to deliver something that somebody can learn from. The business should get something at the end that they can put into practice and say like, “Oh, this is right or this is wrong.”

Derek: Do y’all know the [inaudible] you’re saying?

Roy: Yeah.

Derek: I’m just going to sell it now.

Roy: I think ultimately we just…as practitioners if we could do what we say we’re going to do, that would go so much further than where we currently are today, it’s not even funny.

Jade: So how do we get there? We’ve got two minutes to solve this problem.

Derek: Hey, I didn’t commit to anything. I would say the best thing that I think works for teams if they want to improve commitment is basically really take a deep dive in look at what it means to do what you say you’re going to do and also, understand that you can say you’re going to do smaller things than other people want you to do.

I can commit to less work than people want me to commit to and if I can do that and have success and build and learn and inspect it to death and improve, I think that is a better long‑term outcome than basically lying every time and not ever fulfilling my promises.

Jade: Is that part of the major problem?

Roy: Yes.

Jade: Is that people can’t reconcile that fact?

Jade: Yes.

Derek: They don’t feel empowered to say no to those things. Either by themselves or by some other constraint.

Roy: I think they are stupid on purpose, too. Most teams I see are still doing two week sprints, still doing like…I mean, if you’re not able to do what you say you’re going to do, go to a smaller block of something and say like, “If I say I’m going to do this in the next two hours, can I really do it.”

You’re much better off at failing at doing something in two hours, then you are failing in doing something in 10 days or 15 days.

Derek: I was working with a team and I ripped down the board and said, “Show me what you can do in one hour.” They couldn’t do it.

Roy: I think that’s a big problem. I don’t think it’s a matter of not allowing people to be creative or not giving them license to do something.

I think in teams that are high‑performing, they are not doing a bunch of planning. They are not doing a bunch of estimating, but they don’t need to because if they say, “Hey, we can deliver you something kick‑ass in four weeks.”

There’s trust that they’re going to do it in four weeks. I don’t have to think twice about it, right? Where you have to get into the legalism of things are when there is absolutely no trust.

The problem is the only way to build trust is to do what you say you’re going to do. Until you can do that, you’re screwed.

Jade: Tell us what you guys think about commitments. Any experiences that you’ve had with teams or yourself, failures to commit, all of these things.

You can find us on Twitter @Agileweekly, and on Facebook, facebook.com/agileweekly. Talk to you next week.

[music]

Announcer 1: If there is something you would like to here on a future episode, get over to intergramtech.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 agileweekly.com. It’s the best Agile content delivered weekly for free.

The Agile weekly podcast is brought to you by Integram Technologies and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integramtech.com or subscribe on iTunes.

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

The post Episode #115 – Commitment Considered Harmful? appeared first on Episode #114 – Sprint Failure appeared first on High Costs and Negative Value of Pair Programming

Transcript

Clayton Lengel‑Zigich: Welcome to another episode of the “Agile Weekly Podcast.” I’m Clayton Lengel‑Zigich.

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

Clayton: Today we’re talking about an article that we came across, it was this week. It’s called the High Costs and Negative Value of Pair Programming. It’s by Capers Jones at the Namcook Analytics blog, we’ll put that in the iTune net.

Basically, it’s, like a white paper almost, about why pair programming is harmful, and it’s not really a good idea, and you shouldn’t do it, or at least, you shouldn’t do it yet, until you do lots of research about it. It struck a chord, I guess. We came across the post on Twitter, and it kind of generated some buzz on there. Then, we talked about it internally, so we were hoping to share our ideas.

The first point that I thought was, that resonated with me was the author makes mention that para‑programming is something that came out of the non‑scientific. It wasn’t measured very well in the Agile community. I would probably give him that, that the Agile community has lots of things that we do that are not necessarily based on hard scientific evidence, a lot of its just anecdotal experience. That’s probably a fair statement.

Roy: It becomes very difficult, too, though. I think we’ve had something that we’ve run into in the past, right? Where it becomes, because of the nature of every team being different, different projects being different, the codes bases being different, like a lot of the para‑programming and not just para‑programming, a lot of the types of practices that teams are experiencing with are very difficult to measure in a scientific way. It’s very difficult to have a control group that’s identical except for this one variable.

Clayton: The thing that was…while I agree with that general idea that the Agile community is very unscientific about how they measure things, I felt the way that they went on about, goes without measuring things in the article was kind of lame because they just made up a bunch of stuff and put it in Excel it seems like. I don’t know. My guess is you have to take a healthy grain of salt.

Roy: The thing that I thought was most interesting in the beginning is that the author tries to make the point that there are a lot of different scenarios about para‑programming that were not considered in most cases. He goes through all these different examples of single programmers using static analysis versus expert single programmers compared to average pairs and novice pairs compared to all these ten different permutations of all these different things.

Which, I guess, there are probably not many organizations that have all of these things and they are only going to have two or three at most. I thought it was odd that you go so far out of your way to make a big point of not comparing all these things, especially when there probably isn’t a whole lot of opportunity to compare them all?

Clayton: I thought the static analysis bit was interesting because he specifically talks about the number of defects that a single programmer using static analysis produces versus two pair of programming produce. I think the ratio is something like a single programmer using static analysis develops one defect for every 15 that the pair programmers develop? I guess maybe I don’t understand what static analysis is, because I don’t understand. Do you mind explaining real quick?

Roy: The idea that static analysis is going to evaluate your code and find defects for you? I have written plenty of defects that static analysis wouldn’t have caught. There’re plenty of things that static analysis would tell you that wouldn’t be defect that you could spend a bunch of time fixing. That seems like it’s just a silly thing to even bring up.

Static analysis can be important and it can hint you in the right direction and help you find different things with your code. The idea that it’s like this great tool for finding defects or even a tool for finding defects seems like a stretch.

Moving on, another downside the author states for pair programming is that it won’t scale. The example that he gives is a huge software project with 500 engineers. How could you get them to pair? How could you hire another 500 more people? Which seems odd, because any software project that had 500 people working on the same thing that sounds like a nightmare, no matter what you’re doing.

Clayton: Right. Exactly. You are going to have so many people doing many random things and wasting a ton of time, even pair programming at that point when you have a project that big, it becomes unmanageable.

Roy: If it’s 500 people across an entire organization all working on different things, then you could still pair. There’s nothing that says you couldn’t, the idea that it wouldn’t scale? That seems kind of silly.

Clayton: That’s the mindset difference, right? Because he’s thinking from the perspective of “I have 500 people and I need to maintain my current productivity level, which means I have to hire 500 more.” Instead of saying, “I have 500 people and that means I have 250 pairs.”

Roy: That’s a good point. Kind of the next thing that is the problem with pair programming is why hasn’t this been tried with other business functions or other job functions? They talk about architects and BAs and testers and all these other things which, if you talk to those who are actually doing pair programming, they have tried to do some form of pairing with people who are not just software developers.

This one stuck out to me as someone that has kind of betrayed the experience the author has with pair programming and the idea that no one has tried that before.

Clayton: In fact, in my experience, the biggest gains from pair programming come when you have the most different types of experiences combining. Say, you have a graphic designer and a programmer, or something like…as different as possible.

Because, if you put two people that are almost identical in front of a computer, the most you’re going to get out of it is maybe a slightly lower defect rate, because one of them is proofreading what the other one is writing.

But, if you have two people that have totally different ways of approaching the problem that gives the pair a greater diversity of options to choose from, and it makes it more likely that they might pick the right one.

Roy: The thing that struck me as the biggest bullshit indicator of the whole article was that one of the measurements that’s used in this calculation is lines of code. The measurement is how fast is an expert single programmer, based on how many lines of code they write?

That’s what is used in all the economic calculations. I wouldn’t doubt that pair programming is probably more expensive, and probably slower, than single people working on things, but that’s entirely ignoring all the other benefits that you can get.

If you’re just doing lines of code, if you’re working on a software project that all that matters is that you’re just pumping out lines of code, then just hire a bunch of monkeys and they can just pound on the keyboard. You don’t need pair programming at that point.

It seemed like an odd comparison. I would even say that if your software project is so simple that you can just crank out lines of code, then you probably don’t get any benefit from pairing as far as collaboration, or redundancy or anything.

Clayton: You probably don’t get any benefit from collaboration of any form. You should probably just outsource, and try to get your code written as cheap as possible.

Roy: Right, because if all it really takes is that you just are pumping out code, then you can just replace that person with someone else, and it doesn’t matter. But, that’s not the case, I think, in most software organizations.

Clayton: I was going to say, how many projects are actually out there where you can just put anybody in front of it and pump out code?

Roy: A lot of people try and do that, especially, I would say, shops that are doing outsourced software development, where they’re solving the same problem multiple times. They probably do just have a set way of doing things, where they could get pretty close to just pumping things out, and it doesn’t really matter who’s working on it.

But, for most organizations that are developing either products for customers or developing products for internal customers, where there is a need for that collaboration and giving some creativity, and having that redundancy, so that you don’t have the single point of failure with the one person who knows everything…

Clayton: That’s true. That’s one thing that’s not really acknowledged all that much. I believe one of the lines in that article states something about like, “If you look at the data in Table three, you can clearly see that the most efficient course of action is to hire a bunch of individual expert programmers.”

If you’ve followed many of our podcasts in the past, then you’ll know that that does not really fly very well with the way we like to work, and that that sets organizations up for failure, because you end up with all of these single point of failure where if any one of them…Each one is a link in the chain, and if anyone is gone, then the organization falls apart.

Roy: The single expert programmer is usually a hero and a cowboy. They are the ones that are going to stay up until 3:00 AM heroing some solution for some problem, and then they’re going to cowboy‑code their way…

Clayton: They’re pumping out lots of lines of code.

Roy: Yeah, exactly, and they’re going to cowboy‑code their way through everything else.

If you ask any IT hiring manager, the idea that you can just go pluck expert programmers off the street…which, to the author’s credit, he does make the point that that probably only makes up about 10 percent of the hiring pool that’s available, the programming talent.

I feel like that advice is…”You should only hire expert programmers” is like telling your little sister, “You should only date guys that are really nice to you, and that are financially secure, and that treat you with respect.” That’s not going to be everybody in the world. That’s probably not very good advice, right?

Clayton: I don’t want my sister dating everybody in the world, though.

Roy: I agree, but the idea that a hiring manager is just going to go out there and find some expert programmer and say, “Hey, we can solve all of our problems by hiring three of you, instead of having a few pairs.” That seems silly.

Clayton: It’s short‑sighted, too, to think of things in terms of moving faster because you have a pair, because it’s a single person moving faster. If you have a single person making poor decisions, and maybe moving very quickly but creating this monstrosity that’s going to be impossible to maintain, sure, you’re moving faster for now, for the next few weeks.

But then, all of a sudden, when defects come in or change requirements come in or whatever, and you start needing to adapt the system to meet the new demand, that’s all of a sudden when things start to slow down, because you didn’t slow down to begin with.

Roy: Yeah. The way that the example is set up in the article, it’s very tipped in favor of the single programmer, and not in favor of a more, I would say, real‑world scenario, or at least a scenario that we see with our clients that have a dynamic application or a legacy system, or they’re trying to build a new product.

They need lots of creativity, and they need that collaboration, so that they can get lots of different ideas, and so that there’s the redundancy. Those are the things they need. They don’t need people just pumping out code.

Clayton: That’s, I think, we see in almost every organization that I’ve ever worked with. The biggest problem has always been with figuring out what to build. Not building something quickly. Building something as fast as possible has never been the issue.

Roy: I would say the other thing, I think, that we see a lot is there are scenarios where saving money is a beneficial thing. I think this article comes from the standpoint, the fact that they bring it up in the very beginning, that Agile is sort of not very good with economics.

Or at least, that’s the claim they’re making. Drives to the point, I think, where all they really care about is the bottom line. Which, you know, I think if you spend enough time in the community you realize that going faster and more better, faster, cheaper. That line, which is, I think, how a lot of people view Agile, maybe Scrum especially.

Clayton: And Lean as well.

Roy: Especially with Scrum, if we can do Scrum, then our teams will be faster. They’ll be cheaper. They’ll be better or whatever. If that’s the only thing you’re driving for then I think this article is appealing to you. If all you care about are dollars and cents.

Clayton: Maybe Agile isn’t for you if you’re doing that.

Roy: Right, and that’s why I would say that you probably don’t even have the culture in your organization to support para‑programming if all you care about is the bottom line. Because there’s no way you could look at a pair versus a single person and determine that, “Oh, the pair is more expensive, but that’s OK.”

That’s not going to be your mindset. You’re going to think of them as, “This pair is more expensive,” and you’re not going to see the benefits that you get from para‑programming. So you’re just going to ignore out of hand which is who this article appeals to.

Clayton: Actually, it’s a huge disparity between thinking of these things as just a set of processes and tips and tricks to try to make things more efficient or to make things better, rather than looking at it as a value system, where you are completely changing the way that the human beings within your organization interact.

Roy: You’re changing the way that people will write that software.

Clayton: Right.

Roy: The closing point about divided work. I thought this was just another one to seem kind of ridiculous out of hand as well. I don’t think there’s anything that you could compare between para‑programming, two people sitting down writing software like a software feature. I don’t think that’s comparable to military command whatsoever other than the fact that there are two people.

The idea that you would say, “Divided work can be harmful because look at these examples of things that don’t work.” They’re not the same thing. It’s apples and oranges at that point.

Clayton: Let’s look at it from the perspective of decision making ability, right? Where if you have two people sitting in front of a computer and they have to make a decision? They could potentially argue about it for half an hour to an hour. In the software development world, like arguing about something for half an hour to an hour is not big deal. But, I could understand in the military engagement that might be a huge problem.

Roy: Right. [indecipherable 13:04] means software is malleable, right?

Clayton: Right.

Roy: You and I could sit down and para‑program and we could come up with some solution. Then, maybe we go away for the weekend, we talk to some friend and they mention something that triggers an idea. We can come back and change that. There’s nothing. You can’t change sending your tanks into battle, and you can’t just do over. There’s no undo.

Clayton: But, it is pretty common to see, especially large groups get crippled by shared indecision. It’s like everybody wants to go in a different direction.

I can definitely see that extending all the way down to pairs as well, where two people with fundamentally different mindsets want to go in different directions. But, I think that ends up being a much large organizational problem in that probably speaks towards a lack of shared vision for the project.

Because of everybody is on the same page where their project’s headed, then the implementation details of going one direction or another, if they’re both headed in the same way, it doesn’t become as much of an argument.

Roy: I’ve seen that on teams where pairs will have very…especially, if you get two people that are very strong willed. They will have very different ideas of how the system should be architected or whatever the case may be.

But, when the team doesn’t have trust and they don’t have collective code ownership with standards, that’s when you get people who say, “We should use this library.” Then, the other person says, “No, we should use that one,” when really it’s the team that should basically be figuring out, “When we have to solve this kind of problem, we’re going to do it this way.”

[crosstalk]

Roy: Once you get over that problem, and you say, I think a great example that we always have with the old Integram was authentication stuff. There are 50 different ways you could do authentication and rails. We picked one and that was how we did authentication. That solved the problem of two people pairing and saying, “Well, my pet library that I think is really great is this one.”

Then, the other person saying, “No, no, no. We should do this way.” Then, it was you had two different ways in this project that were inconsistent with what the team thought was the standard, if you can get over those kinds of things. That’s how you can solve some of those problems that they might seem like problems with pairing, but I don’t think they really are.

Clayton: That’s true. I think every single one of the items you listed really speaks towards larger organizational problems that have absolutely nothing to do with pairing. Like if these are the things, if these are reasons why you don’t want to do pairing, then maybe you shouldn’t be doing pairing yet because your organization is not ready and your organization needs some significant changes before you do.

Roy: If you’re totally swayed by the economic argument, then you’re missing all the other benefits that you get. If that’s where you are then you’re not ready to be awesome. If I put my Derek hat on for a second, I would say, “It’s expensive and it’s difficult to be awesome and if you’re going to fall back on some excuse about how it’s too expensive with all these kind of bullshit calculators that you wrote in excel, then too bad. You don’t get a taste of the awesome.”

Clayton: Fair enough.

Roy: Thanks. See you next time.

Clayton: Bye‑bye.

[music]

Announcer 1: If there is something you’d like to hear in a future episode, get over to integramtech.com/podcast where you can suggest a topic or a guest.

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

Announcer 1: The Agile Weekly Podcast is brought to you by Integram Technologies and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integramtech.com or subscribe on iTunes.

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

The post Episode #113 – High Costs and Negative Value of Pair Programming appeared first on 7 Agile Best Practices that You Don’t Need to Follow

Transcript

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Derek Neighbors: I’m Derek Neighbors.

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

Clayton: Today, we will be talking about the much talked about Seven Agile Best Practices That You Don’t Necessarily Need To Do article. If you haven’t read it, it’s on the Agile DZone. It’s called Seven Agile Best Practices That You Don’t Need To Follow by Jim Bird.

We’re going to talk a few minutes on each of these. First one is test‑driven development. That’s one that somehow became synonymous with Agile teams, that Agile teams do TDD. What do you guys think? Do you have to do TDD?

Derek: No.

Roy: Yeah, I’m going to say that.

Clayton: [laughs] Next. Let’s explore a little bit why that became so pervasive. Why does everyone thing that you have to do TDD if you’re doing Agile?

Derek: Because there is a difference between Agile and good. So it’s like if you want to be good, you have to do TDD. If you just want to be Agile, like, “Hey, you don’t need to do TDD.”

Roy: Also, there’s a huge feedback component to Agile, right? It’s all about quick iterations and getting feedback early. I think test driven development is the programming embodiment of that. It’s the idea of asking for feedback before you even start coding and then, gaining feedback as you code towards the failing test.

Clayton: Do you think it would be fair to say that you would have to do TDD if you were doing extreme programming?

Roy: Yeah.

Derek: Yes. I would say you would. I don’t remember his full arguments on this, but I think it comes down to studies say TDD is not as good. If you know what you’re doing, then TDD is good, but if you don’t know. The only time that I really say that TDD should be super optional would be if your start‑up, you’ve got a limited amount of money and you have to meet the next date and slow at TDD because you don’t know how to do it.

If you are competent with TDD, there is no reason not to do it. If you are going to be long‑term with a project, then there’s no reason not to do it.

Roy: So part of the argument also talks about that statistically there’s an increase in complexity with TDD, oftentimes in terms of design, which I’d have to make assumptions, but I’m assuming it’s based off of probably not knowing how to do TDD properly, like abusing the crap out of mocks and spies and all of those patterns, and creating tests that are really brutally coupled to the specific implementation.

Derek: It doubles the lines of code, so therefore, it’s got to be twice as complex.

Roy: Right, when people, when teams get…

Clayton: Speaking of doubling, pair programming. Do you have to have two people working, do you have to do pairing if you’re on an Agile team?

Roy: No. I feel like you have to be doing some form of pairing, like it may not necessarily be pair programming. But like people working by themselves, that’s not a team. Like leave Agile alone. Like I feel like a bunch of people working by themselves in isolation is not a team. So I almost feel like there has to be a pairing component in terms of like pair‑planning or pair design or pair…

[crosstalk]

Clayton: So the only way you can do that is by pairing?

Roy: No. I suppose not. And I suppose they very specifically mean pair programming.

Derek: Yeah, because I go to a whole lot of planning meetings that aren’t paired but I think that the people there are co‑creating solutions together.

Roy: Sure.

Derek: Again that’s one to me just like TDDing. If you want to be good, you probably should pair. If you want to be Agile, you don’t have to pair.

Roy: Right. Some of the arguments are for the idea like, that some people don’t like to pair and some people will be slowed down by other people like that.

If I’m really good and Clayton sucks, [sarcastic] using a realistic example, [laughing] then what we would have is like Clayton would be slowing me down all of the time, which I think is kind of the wrong way to think of that, it’s like I’d be teaching Clayton some awesome new stuff that he doesn’t know yet… [crosstalk] …and that’s more important in the long run.

Clayton: They hit on or he hits on some of other common arguments about introverts versus extroverts and like smashing creativity and you won’t have time to be innovative and all that kind of thing.

Roy: Like you won’t have the opportunity to go heads down and really solve complex problems but arguably, if you’re pairing properly, you’re turning all your complex problems into simple ones and you don’t end up with those types of huge complex Rube Goldberg solutions.

Derek: I keep saying that you know the problem with exercising for me is that it leaves less time for eating ice cream and clearly this is a problem.

Clayton: OK the next one is emerging design and metaphor. One thing I don’t think a lot of people especially kind of the new Agile crowd I don’t think they really have embraced metaphor at all. I don’t ever hear people talking about the importance of metaphor not now at least.

Derek: So I can’t speak without using metaphors, like I think you have to have metaphors to be Agile.

[crosstalk]

Roy: They have to be sports metaphors.

Derek: Not always but usually, just because sexual ones aren’t very you know reasonable to do at work. I will remember a conversation with Chet, I believe about this, and I think they kind of said that XP dropped the metaphor at some point, and I want to say that the reason they dropped it is because it’s too fucking hard to do. Which speaks volumes for the shit that’s really good is hard to do. I think that people throw away the stuff that’s hard to do first.

Clayton: Like BDD. If you look at that, and you talk about “Let’s have ubiquitous language, and let’s have a shared language.” That’s really difficult. And there are a lot of times where people can’t even think of a way to describe some part of the system, so they just throw it away. [crosstalk] They give it up.

Roy: Exactly. You almost put it in the box of the metaphor: “Well this doesn’t fit our metaphor, so I guess we can’t do it.”

Clayton: Right. One thing that he talks about in the article is changing the metaphor, or having to get rid of it, or being pigeonholed by it. If the metaphor is meaningful, I think you can make it work most of the time. If you need to change it, I think you can have a good reason to change it.

Roy: It’s interesting to pair this up with emergent design because I don’t necessarily put those two in the same box in my head. Emergent design, the idea being “I’m not going to design this entire thing up front. I’m going to be able to build on top of it as it goes on.”

Clayton: Then that’s some of the fallacy that in Agile you never talk about design. This is, in practice, not true. I think if you go to high‑performing Agile teams, they’re talking a lot about design. They just don’t do the huge design up front stuff. But, they don’t not talk about it.

Roy: And, it stays flexible the entire time, so nobody’s totally stuck on a particular interpretation…

Derek: [sarcastically] How are you going to grow your architecture e‑peen if you have emergent design? Now, come on.

Clayton: There you go.

[crosstalk]

Derek: I want to back on this one a little bit. Look at some of the most prolific onbaoarding applications of computer history. If you look at Twitter, if you look at Facebook, if you look at some of these companies that have gone from zero users to several hundred million users in a very short period of time, all of their architecture was created using emergent design from a standpoint of they didn’t know what they didn’t know.

I believe there’s an article on this. We’ll try to see if we can get it in the show notes. Twitter had done a ton of performance testing. They had done a ton of load. They had done a ton of stuff where they could deal with literally hundreds of thousands of follows per second happening on the system. What do you know? Ashton Kutcher goes on “David Letterman” and says, “I want to be the first person to a million followers. Everybody go follow me right now.”

Total edge case in, “Yes, we support a hundred thousand users following another user, but we don’t support a hundred thousand people following the same user in a one second time frame.”

How do you deal with those things that come up? You can’t cover every edge case, and I think continuous deployment has moved us to a point where what you’re really doing is saying, “We discover by the feedback the system gets us.” And, we’re able to adapt and deploy so continuously and so quickly, that it doesn’t feel like we have architecture problems. I think this is something that the old‑school, old guard just can’t deal with. It’s like, “No, but we have to get it right the first time!”

Roy: I kind of feel like if you don’t have some form of emergent design you are, by definition, not doing Agile.

Derek: You’re screwed!

Roy: Right? Because, other than the human relationship and that component of it, I feel like the ability to pivot and change your mind as you gain new information is the fundamental core.

Clayton: What about daily stand‑ups? Roy, you just mentioned the human component. Getting together and talking to other people on the team on a daily basis. Is that something you have to do?

Derek: Is that what they said? I don’t know the wording. To me, if they said “daily stand‑ups,” no, I don’t think daily stand‑ups are mandatory. Do I think the people on the team need to talk to each other at least one time throughout the day? Yes. I think that is necessary.

Clayton: To really nit‑pick, I think what they’re really getting at is, “Does everyone have to stand up?”

Roy: We didn’t. We did an entire episode on whether or not you should stand up during a stand‑up. We came to determine that yes, you should.

Derek: I think it goes back to “Do you want to be good, or do you want to be Agile?” I think you could be totally Agile without doing any kind of formal stand‑up. I think if you want to be good, it’s just like using a white board versus using a tool. Can you do things without using white board? Sure. But, you get some benefits from the other one that you don’t.

Roy: I’m guessing that part of this is driven through experiencing bad stand‑ups that are a waste of your time. Because just like any other meeting, you can screw this one up, and make it a total waste of everyone’s time. Where it’s just like a status report, and I go, “Yesterday, I did X, today I’m going to do Y, no blockers.” Nobody is listening to each other. You’re totally defeating the purpose.

Derek: I see another one too with a lot of teams that are co‑located and within the zone proximity. “We sit next to each other all day long and we pair, so why do we need a stand up? We’ve got a physical board. We sit next to each other. We talk to each other every day. Everybody already knows what everybody is doing. Why the hell do we need to do a stand up every day?”

Clayton: I think what’s funny is that most the time those people don’t actually know what is happening.

Derek: No, they don’t. I see that too.

Clayton: Speaking of everybody knowing everything, what about collective code ownership? Is the idea that everyone can work on any part of the system and everybody knows the system to some degree? Is that a reasonable thing? Or should you say, “It’s OK that Derek doesn’t know how to do this right.”

Derek: Some people are too dumb to work on parts of the system.

Roy: Right, they shouldn’t be allowed to work on parts of the system.

Derek: People won’t say that, but that’s what they’re saying when they say that. “Not everybody is as knowledgeable, not everybody is a god like me.”

Roy: Actually this article does say something specifically along those lines and not everybody should be allowed to modify parts of the system.

Clayton: I think what they’re getting at is it’s not realistic that that is the case. It isn’t realistic that everybody on the team can work on any part of the system. To me that sounds like, why is your system so complex?

Derek: What it sounds to me is why do you hire stupid fucking people? If you have people that you hired to code and you don’t let them go to certain parts of the code because they’re not competent to go to the code, why are they employed by you?

Clayton: That’s a good point.

Roy: Or if you don’t let them go into the code because the person that owns that code is extremely territorial over it, then why do you have that territorial person employed, and why are you letting them boss you around?

Derek: I don’t know if you could be Agile without having collective code ownership. The first time you have to say, “Sorry, Clayton is on vacation, I can’t really deal with this problem.” By default, you are not able to respond.

Clayton: That’s true. You couldn’t respond to that change right?

We’ve heard that user stories are a representation of a conversation. Why wouldn’t you write every requirement as a user story? Is it un‑Agile to have a requirement on the system that isn’t a user story?

Derek: This one I think they’re pretty in line with. I think that the multiple formulas that exist out there are really good. I think they help people write good, small parts of the system. I think somebody could go write one or two sentences on a board and still get stuff done just fine, if you have the conversation. I think the actual card and the conversation are far more important than the stories themselves.

Roy: One of the values of a user story is that it can’t give you enough information to substitute for a conversation. I can’t write a user story that tells you everything you need to know, so you have to come talk to me.

Clayton: They talk about using a use case, or a test case, or a wire frame, or something which they are great examples of things you can add on to a user story as you have that conversation, but I don’t think it’s an and/or. If you were to say that you didn’t write everything in user stories, I could see somebody getting a little crazy with writing too many use cases, and then you go off the deep end in that regard.

Roy: Right, and then before you know it you have a full spec outline ahead of time so that we don’t have to spend this entire time arguing with the developers and negotiating someone’s criteria.

Derek: You get off the rails pretty quick, right? If you don’t keep it nice and short then we start assume, “Oh Roy, you’ve got 80 pages of Cucumber specs for me.” So I don’t need to actually ask anything about the system.

Roy: It’s all here.

Derek: Clearly you’ve thought of everything, right?

Clayton: The last one talks about relying a product owner. The single ringable neck and having one person that is supposed to be the gateway to the customer. If most Agile shops are doing some form of Agile are probably doing Scrum and they probably have a product owner. How did all the Agile people miss the boat on this one?

Roy: I kind of think it would be OK if there was more than one product owner. It doesn’t necessarily have to be a product owner as long as there is just one backlog. You still get into the problem of if you have this one backlog and you have two different people that are both your boss.

They’re arguing over what a specific story is supposed to be like. I can still see a ton of problems there. You have to have somebody that makes the final call. Somebody at the top of your organization has the authority to say this and not that.

Clayton: I think there’s a distinction between being the voice, the single point of contact with a customer and the person that makes decisions. Should the only person that ever talks to customers be one person and the product owner?

Probably not, and you should probably find lots of different ways to have that interaction and get that feedback. If you had more people talking to the customer and more people making decisions, I don’t think that’s what you would want.

Derek: This one is really odd for me in the sense of I’m starting to find that actually in some ways I believe that having a product owner is non Agile. Part of it is, I think that if a team, when I look at small startups and I see them do things with no product owner.

They really are doing things by committee. They really are doing things by unanimous decision. I think it’s because they have got strong vision, and they’re aligned. To me the need of having a product owner who is the one all that says, “I’m going to make the decisions so we can move forward.”

I think that’s almost a crutch that says that you’re not providing enough vision that the team is actually aligned behind the product, because if they were, you could get to a unanimous decision fairly quickly. You could be biased towards that action.

Roy: That’s a really interesting point. I hadn’t thought about it like that. The reason why we always think that you need a product owner is because you have dissenting viewpoints on which way to go.

That’s because tradition decision making is made by majority vote, in which case you have a bunch of people that aren’t happy. If you’re always unanimous, then you have a team that is acting as one anyway so it’s like it’s one single [inaudible 00:16:15] .

Derek: You probably have a much better product. To be clear, I think product ownership is very necessary is most organizations because they’re having to deal with them as a dysfunction to how they currently work. I think you could absolutely be on a highly Agile, adaptive, high performing team, and deliver great product, and not have a product owner.

Clayton: I think we’re out of time. Thanks guys!

[music]

Announcer 1: If there is something you would like to hear in a future episode, head over to integrum.com/podcast where you can suggest a topic or guest.

Announcer 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!

Announcer 1: 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 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)244‑8656

The post Episode #112 – 7 Agile Best Practices that You Don’t Need to Follow appeared first on

However, teams frequently don’t actually burn down this steadily. Often team members
know on planning day that they will be gone for half a day for a dentist appointment,
taking a three day weekend, or are going on a vacation that takes up half their
capacity for the first half of the iteration.

This causes the traditional straight line burndown chart to potentially tell the wrong story. It could give the appearance the the team is way behind, when the team actually has most of their available capacity at the end of the iteration. Or worse, the burndown chart shows that the team is on track, or even ahead, when they are actually in serious danger of not hitting their commitment because half the team will be gone on the last two days for a conference.

It is important for information radiators to communicate as much accurate information as precisely and obviously as possible. It’s all to easy to make the assumption that the team is perfectly on track, and the conversation about what will actually get done never happens. To help prevent stakeholders from being mislead, we recommend trying a stair step burndown chart.

Ingredients

1 Blank burndown chart for however your iteration looks.
1 Ruler
1 Sharpie
1 Green marker
1 Red marker

Instructions

Get the team’s capacity by day.
Draw a horizontal line on each day of the sprint, indicating how much of the team’s capacity is left in the sprint.
Label each horizontal line with the number of hours left. This makes it much easier to update the chart throughout the week.

What this does

Here is an example of a regular straight line burndown chart:

Eveything looks great, right? The team fell behind at first, but is starting to catch up and is now only an hour or two behind. It would be totally reasonable to for the team to believe that they will make up those two hours and should have little problem hitting their commitment.

One thing the team has forgotten though, is that two of their team members will be gone at a conference on Thursday and Friday. The stair step burndown tells a completely different story:

Now we see that the team is actually 16 hours behind, and the team only has 24 hours of capacity left in the entire sprint. This realization, while harsh, is much better to have on Wednesday, midway through the sprint, than on Friday afternoon. This way the team has the time to warn the Product Owner and figure out what needs to be removed from the sprint. The Product Owner is able to use that advance warning to plan for the following iteration, taking in to account that some of the work that was originally thought to be done this week is actually going to take up a sizable portion of next week as well.

In retrospect, this is a very minor adjustment to the existing burndown chart. There is something about burndown charts that allow you to omit tiny pieces of information and all of a sudden the same chart tells a completely different story. A burndown chart should not be a substitute for communication, but it should definitely be as obvious as possible. Anybody should be able to walk in, see it on the wall, and figure out what it is indicating, all without any Scrum or Agile experience.

Variations

You can get even more fine grained by stair stepping by half days. This can lead to some pretty interesting conversations about how morning capacity differs from that in the afternoon.

The post Stair Step Burndown appeared first on Episode #111 – Inspiring Personal Growth in Agile Teams appeared first on

What this does

By the end of the iteration, it is not uncommon to have the bullpen so polluted with red balloons that it becomes difficult to freely walk around. This highlights the devastating effect that a number of individual interruptions have on the iteration. By adding up the total number of balloons and multiplying by 15 minutes, the team can gain a pretty quick approximation of the actual time spent on all interruptions.

The post Interruption Balloons appeared first on One Hour Iterations appeared first on

It’s the end of the sprint. The team committed to half their capacity but somehow still failed to hit their sprint.

During the retrospective, the team decides that the problem lies in the quality of the planning meeting. If only we had more accurate times on our tasks, we would’ve known that this would take much longer than we thought. This also brings up the question, if there were tasks that took way longer than planned, how come nobody asked for help? Shouldn’t we be leveraging the power of teams in exactly these type of situations?

Maybe the team thinks it was due to interruptions. If we hadn’t constantly been interrupted with questions and requests from the rest of the organization, we would have actually been able to work as many hours as we said we’d be able to.

The question becomes: how do you know if either of these or other rationalizations are actually the reason the commitment was not met? Extreme Timeboxing describes a great way to measure how much time was spent on each task while providing some other, subtler benefits as well.

Ingredients

1 tasked out sprint. Tasks should have time estimates on them. Tasks should be written on actual (gasp) 3 by 5 index cards.
1 Black Sharpie
1 Red Sharpie
1 Green Sharpie

Instructions

Pick a timebox. The team should decide on the timebox at the beginning of the sprint. The timebox should be small enough to provide fine grained feedback, but long enough that maintaining it doesn’t have noticeable effect on the sprint work. We prefer to use 15 minutes.
Each pair grabs a task card off the wall
Each sets a timer (almost all phones have them) for the length of the timebox.
The pair starts working, letting the timer do its thing.
When the timer goes off, whoever is not driving fills in one black box on the task card.
If the time elapsed exceeds the amount of time estimated for the task, draw a red box instead.
Reset the timer and continue with the task.
When the pair is done with the task, fill in the remaining time left on the original estimate
in green boxes on the task.
Repeat until the sprint is done

What This Does

By marking the time spend on each task, the pair gets immediate feedback on which tasks went over and which went under. This makes it painfully obvious when a task goes way over the estimate because you’ll see a wall of red boxes that can be spotted from across the room.

The team will be able to measure how much time they actually spent on the tasks by adding up all red and black boxes up at the end of the sprint. It is not uncommon for a team to find that their capacity is actually far less than they thought it was.

Each time the timer goes off during the sprint, the pair is essentially asked “Did you work on this task for the last 15 minutes”. It becomes very difficult to mark a box if they know that they spent those 15 minutes talking to a manager, looking at YouTube videos,
or being distracted in some other way. You’ll generally find that teams are actually pretty good at estimating tasks, generally only deviating by one box on other side. Be wary though, because teams will generally perceive more red boxes than green boxes, even if there are exactly the same amount of each.

Red boxing presents the pair with a great opportunity to ask for help. Many teams that try this end up making a rule for themselves that the first red box means the pair is required to inform the rest of the team and ask for help. By making it something concrete, there becomes a boundary for when to ask. You no longer have the excuse of getting sucked down the rabbit hole and losing track of time. It is also no longer as much of a point of pride to avoid asking for help since the decision is taken away from you.

Lastly, by getting so much specific feedback in terms of time spent on each task, the team’s ability to estimate those tasks will start improving very quickly.

Variations

Using a centralized timer, rather than individual stop watches, gets the team on the same cadence. This way, when a pair realizes that they’re going into the red, the rest of the team is also taking a brief second to fill in a timebox and is much more open to being interrupted to be asked for help.

Instead of putting a numeric time estimate on the task card, preemptively draw outlines for each of the boxes. This way, the team is reminded to fill the boxes in, and you no longer need a green marker since you can just leave the outlines blank when the task is completed under time.

Agile in Design
Pen Sketching
Ideation and collaboration

Transcript

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Jade Meskill: I’m Jade Meskill.

Clayton: Joining us today we’ve got Kevin Goldman from 29th Drive. Hi there, Kevin. Can you tell us a little bit about what 29th Drive does?

Kevin Goldman: Sure. We design and sometimes develop software.

Clayton: We’ve actually done a little bit of work with you in the past. We wanted to talk to you today about design, and you mentioned design a little bit of software, and the Agile framework. What’s your experience with that?

Kevin: Jumping right into it.

Clayton: Yes, right away. It’s a 15 minute podcast. We’ve got to get going.

Kevin: Oh! Its 15 minutes. That’s good to keep in mind.

[laughter]

Kevin: Yeah, I was thinking about some things we could talk about today in terms of how we use some Agile processes in our design work. I think the thing that we’ve been using most, a process that we’ve been using most lately, is sketching.

When people talk about Agile UX, oftentimes they’re talking about getting away from deliverables, from traditional deliverables based on predetermined milestone schedules in a waterfall process. What we’ve been doing more and more, is really embracing the idea of rapid ideation, and using pen sketches to replace a lot of what we used to do, around flushing out our ideas in digital form.

Clayton: Like a Photoshop comp. kind of thing? Is that something that would maybe be the old way?

Kevin: Yeah. Let me describe it that way. Old way might be having an idea, wire framing it, iterating on the wire frames. Then taking the wire frames into visual design, iterating on the visual design in Photoshop. Then taking those visual designs, and then throwing that over the wall to the development team, and them developing.

Now what we’re doing is ‑‑ we have an idea. We’ll do a lot of pen sketches. We’ll bring in development right away, and actually do pen sketching with them, and start talking about the idea from end to end; talking about implementation, and all these development issues early in the process with design.

Instead of moving from the pen sketches into Photoshop, or the pen sketches into digital wire frames like an omnigraffle, we’ll move right from the pen sketches into prototype. The prototype might be built in Twitter Bootstrap. It might be built if it’s IOS, a prototyping tool for IOS or it might even be prototype to nextcode.

Clayton: Yeah one thing I’ve always, I have a background in doing what you described as the old way of the designer creates kind of stuff in Photoshop that’s very flushed out and very like final basically.

Throwing it over the wall and then slicing it all up and turning it into a website and I’ve always thought it was interesting that when you got to that low fidelity like pin sketches kind of thing where you could really sketch something out and the crumple up the piece of paper and start all over again.

That was so freeing and it made it so much easier to collaborate with the people that were editing, the traditional kind of design developer barrier like the mis‑communication that always happened, that seemed like it went away.

Kevin: It’s so true so that idea of collaboration I think is a big part of what development teams think about when they think about agile development. And the same thing with UX so you don’t have to be an artist to pen sketch.

Any of the stakeholders in the project can sketch an idea on paper. Customers, business, stakeholders, marketing analyst, anybody can sketch on a piece of paper. And so by making that the medium it allows the design process to be a little bit more inclusive.

Clayton: Can’t lower the very so you don’t have to be a designer or artist or something.

Kevin: Yeah and we’ve gone so far as to work with new customers or even existing customers and encourage them to bust out the pen and get their ideas out on paper and send them to us or a lot of times we work remotely with our customers so they’re not here in town so we don’t have the ability to just sit next to the person and flush out ideas but we’ll use sketch cameras.

There’re these great little IP Vogue cameras that sit on your desk, they’re only $79 and if we’re using a Google hang out or a go to meeting it allows us to show what we’re sketching on the screen and through the go to meeting or Google hang out. So we’ll send those cameras o our customers so they can do those same things back and it creates the concept of having a white board, but doing it remotely.

Clayton: That’s pretty neat. Have you found that your customers are embracing the idea, are they resistant to it? Do they not want to jump into what they consider your domain, the design territory?

Kevin: Yeah, there’s a lot of, there is a. For people who aren’t designers, there’s a feeling that their sketches aren’t going to be pretty. There’re a lot of disclaimers. I’m not an artist, I’m not a designer. That’s OK. We’ve gotten some really great ideas and sketches from non‑visual people.

Jade: What’s it been like working with the designers like the people that maybe used to do it a certain way and having to adapt into this, even like you said, using Twitter which drafted current prototype, I’ve worked with a lot of designers who were very comfortable creating things in Photoshop, but when you get more clear towards the front‑end, they’re actually writing something that actually works and you can look at, they didn’t want to do that necessarily. What’s your experience with that?

Kevin: I can only speak from my experience in the team, the people that I’ve worked with, and all of us have some degree of understanding the front‑end code, some more than others.

In some cases, a designer of the team might be able to create an entire prototype by themselves and they’re very familiar with all the latest CSS3 and familiar enough with Java script to get some of the basic interactions working, and at other times, we just have to collaborate.

If the designer on that particular project isn’t as comfortable, then we just pair them up with one of our front‑end developers so that they can really work day‑to‑day throughout the day on this task of creating the prototype.

Jade: What’s like transition period been for you guys in making this change? Is it something that you were able to pick up pretty quickly or has it been a few months that you’ve been learning as you go or what’s that been like?

Kevin: It’s been a constant evolution. In some ways, I want to say going back 15 years when I started doing design work because you’re always in the process of designing the design process, if that makes any sense.

Jade: Sure, yeah.

Kevin: I say with pen sketching, we’ve really been getting back into it. It was really a part of my early training coming out of industrial design. There’s a culture of sketching in industrial design, and then of course, there’s whole lot of years where I used only digital tools and now with the team that we built at [indecipherable 07:47] drive, which is relatively new, we’re really looking for new ways to collaborate when we started to pen sketch more, it really gelled and it was very quick.

Clayton: What do you think is the biggest contrast that you see between moving towards this new maybe more agile direction versus the old way that you did things, the more waterfall, lot more hand‑off, and more formality around that?

Kevin: The contrast between them?

Clayton: Yeah.

Kevin: Without sounding like a bunch of hype, I think the more agile processes in pen sketching in this collaboration that we’re talking about creates better ideas quicker. It really allows you to generate a lot more ideas, so therefore find the bad ideas more quickly and invest your time into the good ideas more quickly.

Jade: Why do you think it allows you to do that?

Kevin: The pen sketches, no matter what, specifically looks sketchy. It’s just so fast, you can’t get bogged down in pixel pushing, even if you’re doing what we call Greybox wireframes, which are very low fidelity wireframes. If you’re in OmniGraffle you inevitably just end up spending a lot of time trying to figure out how to invert an object, you have to search in through help and menus.

If it’s a pen sketch, you’re going to just sketch that in a few seconds and be done with it.

Clayton: You’re not as tied to the concreteness that a digital tool might give you.

Kevin: Yeah.

Clayton: Some of that formality of presenting it to your customer and having them review it, all that stuff tends to add overhead and really changes the interaction that you have.

Kevin: Totally changes the interaction. With pen sketches, they never confuse the sketch with something that might be final and that happens a lot in design where if we present a wireframe, we know in the industry what a wireframe is and what to expect out of a wireframe, but sometimes a customer, they might just wonder why everything’s grey. We’ve actually heard that.

Jade: I don’t actually like this color palate.

Kevin: Why is every button grey or why is that font not consistent? They get caught up on those things. But a pen sketch is so far removed from the final that whole confusion or misinterpretation of what you’re trying to communicate is not an issue.

Jade: I always try to ask like practical questions, maybe I’m a project manager or I’ve got a team that has some developers and some designers and we’re doing it the old way, what advice would you give to someone like that, who wanted to try and do something that was a little more collaborative?

Is pen sketching the first steps? You just jump into doing that or what would you suggest that person do?

Kevin: Yeah, pen sketching is the first step. The sooner you can knock down that first hurdle of that first person drawing their first line and feel it, that they don’t have to be an artist, the better. It’s very quickly that people, I think, get over that. The other thing I would recommend is we do something called a design studio, which is an old concept that also comes out industrial design.

The idea is that you get a bunch of stakeholders, designers, developers, whoever is on the team together for a half a day. Let’s say two to six hours and you have either a whole product concept or part of a product that you’re trying to develop and you work together collaboratively to flush out the idea for that section of the product.

What we do, the way that we’ve structured a lot of the design studios is we’ll have an introduction and that’s lead by, usually it’s a lead designer on the project, who will give the context and constraints for what we’re trying to solve.

Then, we’ll do, let’s say a half hour where everybody goes away and pen sketches their ideas for how to solve that problem. Then, you come back and each person gets five minutes to present their idea to the team.

Then, you repeat that process sometimes two, three times and what happens in two or three hours, you get 40 ideas of how to solve a particular problem. Even more importantly, you get everybody on the team on the same page about what that process was. What worked, what didn’t and you get this building of ideas on top of each other. You have an idea, triggers an idea in my mind and then, we build on that.

Jade: Agile talks a lot about continuous improvement, so I’m curious, what’s something that you think you might try in the future to improve on this process?

Kevin: Oh, man.

[laughter]

Jade: I didn’t mean to put you on the spot.

Kevin: Just about everything so down to how we can communicate better in the sketches with call‑outs and interactivity and how we can communicate those ideas, more of a how we can…Sometimes, we do need to have a snapshot of what happened in that design studio, so we can refer back to it.

Often times in the design studio, there’s a lot of hand waving that goes along with the pen sketches, so we’re trying to figure out to capture that. I think there’s a lot of room for improvement there. Working remotely with customers is just how it’s done these days. I think there are just a lot of places where we can improve in our work with people remotely.

Estimating projects is always very difficult, probably on the development side as much as it is on the design side. We can definitely try to improve how we set out expectations for how we bill something, how we structure timelines in advance of actually doing the work.

That’s a big shift. One of the biggest, especially for service companies who are in‑house. If you’re basing your bids and your timelines off of waterfall deliverables, it’s very easy to say, “This milestone is this much and this much and this much. It happens on this day, this day and this day.” When you follow a more collaborative approach, it’s not as clear cut at the onset of a project.

Jade: You have to go into more value based fees…

Kevin: Exactly.

Jade: …and it’s a lot more difficult to sell.

Kevin: Exactly.

Jade: Kevin, we really appreciate you coming down. To be fair, just so everyone knows, we asked Kevin yesterday if he could… If you’d like to record a podcast and you said, “Sure.” So we said, “Come tomorrow.” It was a little short notice, but we appreciate you making it out here.

Kevin: Yeah, thanks for having me.

[music]

Announcer 1: If there is something you would like to hear on a future episode, get over to integramtech.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 agileweekly.com. It’s the best Agile content delivered weekly for free.

The Agile weekly podcast is brought to you by Integram Technologies and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integramtech.com or subscribe on iTunes.

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

Transcript

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

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

Drew LeSueur: I’m Drew LeSueur.

Clayton: Today, joining us, we’ve got Peg Haustetter. Peg, you wrote an article about, basically the gist of it was getting started with Agile. That’s a real popular topic with people who are interested in Agile, or listen to the podcast, and things like that that we come across a lot. What was the motivation of writing that article?

Peg Haustetter: The company I work for is Systems Evolution. There are a few project managers that were going to clients that had not really been exposed to Agile, and [inaudible 00:46] to do, how to get started.

We developed a team, and in that team, we started putting together some slides that they could present at their customer. One thing led to another, and we decided to write an article that we published in our [indecipherable 01:05] . That article took all those slides, and all of those conference calls and meetings that we had, to try to get a little Agile primer to all of our members, and we came up with the article.

Clayton: I noticed that you mentioned things like sprints and iterations. The stuff that you’re describing is like Scrum, although you leave some parts out. I was curious if that’s something that maybe Scrum is in your background, or if that’s maybe your preferred methodology that you like to use for projects, or if that was even intentional?

Peg: I am a Certified Scrum Master, so those are the types of projects that I have run. We intentionally left it out because we didn’t want to really sell a flavor or a certain methodology [indecipherable 01:58] article, so that people could relate to what they’re currently doing.

Or to realize that not every company is doing something that’s purely Scrum, or purely any kind of methodology that a lot of them are mixing [indecipherable 02:17] some of their worth all on trying to do it all at the same time.

Clayton: Is there anything that…You mentioned the waterfall, transitioning from waterfall or using that as a benchmark. In your experiences there, are most companies that you find that are trying to transition into Agile, are they doing waterfall now or do they not even have a process?

What are those hurdles, the biggest problems that you find that people face when they are trying to make that transition?

Peg: I do find that the clients that I have been at, they’re larger companies, and so they generally do follow the waterfall. I think the biggest hurdle is trying to get the business team [indecipherable 03:05] involved. They are all about defining the project, and agreeing to the requirements, and then throwing it over the wall, and “Call me when it’s done.” [laughs]

To try to keep them engaged and daily [inaudible 03:22] challenging for the [indecipherable 03:25] to get them in a room to do demo, or let them play around with whatever we’re delivering that sprint. That’s a huge hurdle, if I can get two or three of them in the room.

I think that in the end, the team that you’re working with [indecipherable 03:42] happy with the process once they’ve realized how it’s working, but to get them initially engaged is a challenge.

Clayton: I had overheard the conversation from a product manager and the product owner of a Scrum team the other day. The gist of the conversation was, “I really like this whole Agile thing and it’s great, but we really need to balance being Agile with getting things done.”

Peg: [laughs]

Clayton: I thought that was interesting. I was curious if you’ve heard anything like that, or what you’d say to that person?

Peg: [inaudible 04:19] is that maybe they’re not [indecipherable 04:22] their sprints correctly, because the whole idea is that you are getting things done, and you’re getting them done quicker, you’re getting them done so you have eyes on them, catching any issues, [indecipherable 04:34] put in the wrong place, the wrong color, some little small thing.

People are seeing it right now, if they see that the data’s coming out the wrong way in the field, they see it, you can react quickly and correct it, and then move [indecipherable 04:53] hang around with somebody that’s doing Agile. Go to a class, try something!

Clayton: You mentioned in the article that people like taking a hybrid approach, or maybe combining two things together. There is some talk in the Agile community of a “Scrum bond,” or something, trying to combine Scrum and Kanban together.

Have you ever seen anything like that be successful? Or are you more getting that as a way to introduce the organization to Agile, they might need to do more of a hybrid of their traditional technique, plus some more Agile concepts?

Peg: The things that I have experienced [indecipherable 05:42] methodology, a lot of it is because their compliance departments won’t allow…They don’t really understand the documentation. They still require tons of documentation, tons of certain types of testing, depending on what the product is, and then what sector that you’re working in.

I was working in the medical [indecipherable 06:11] sector. Obviously there’s a lot of regulations, a lot of paperwork, a lot of checklists. You still have to do a lot of those types of documentation while your development team is developing in the Agile methodology, but you still have to support all of the traditional [indecipherable 06:35] .

In some of those cases, in my case specifically, the PM had to produce more documentation than my team, probably wrote in code in some of those projects. I think it depends on the organization, and its will to let go of some of that.

The regulations that drive why we do things [indecipherable 07:02] piece of software. I think it’s learning, and I think it’s learning all the way around. It’s not just for the companies, but if they’re regulated, it’s for the regulators. They have to understand. They need to look back and read all those documents again, and see if there is a more streamlined approach.

Clayton: Do you have any opinions on starting Agile at the team level, and then growing it from the team level up to the organization level? Or do you feel that starting at the organization level and trying to get the higher‑ups thinking in more Agile mindset is better? Do you have any opinion on that, or maybe you’re still trying those things?

Peg: I’ve had more [indecipherable 07:57] both the opposite ways. The medical device company I worked at, we were doing it at an organizational level. It came from the top down, and we happened to be the first project, but they were pushing it across the organization.

I think it was six [indecipherable 08:20] everybody was on‑board. There was lots of training. People went to all of the training, the displays, they went to [indecipherable 08:36] reviews and things like that, so they got engaged.

Currently I’m at a client that, first they were trying it more on a project‑by‑project basis, doing an evaluation to see if that project fit into that mold. That was a slow burn. Just a few people would try to do it. Now, they [indecipherable 09:05] organization.

I think that’s more successful, because when the management is on‑board with it, then everybody gets the right communications and training so that they can move forward with it.

Clayton: One thing that we’ve found is that the organizational culture seems to play a very big role.

I was curious if you’ve also noticed that, or if you have any techniques or ways that you’ve tried to guide the organization culturally? Maybe they’re used to this waterfall, or more of hierarchical management style, and that transition to Agile can be upsetting from a cultural perspective. Is that something that you’ve noticed?

Peg: It is something that I’ve noticed, and it is baby steps. You just have to really spend a lot of time guiding, and getting them used to so much interaction. The first couple of projects that I’ve done in Agile, the business, it was just really hard to pull them along.

IT was all for it, we were gung‑ho [indecipherable 10:19] all the meetings, and didn’t want to be involved. It is a big cultural change. You have to just keep guiding them, and showing them all the advantages of being more participatory.

Clayton: The article seems to talk from a…Maybe it’s geared towards a project manager, or someone who has a holistic, or has a higher‑level view of the organization of the project.

If me and a couple of other developers are on a software team, and we’ve been reading a lot about it, and we want to be an empowered, self‑organizing team, is there any different advice you’d have for someone that maybe is at that level of the organization?

Peg: [laughs] Yeah, there is. If I was writing this article, or talking with the development team, I would have taken a totally different approach. They already know the pitfalls, [laughs] they know that it would be better to have a team that plays on your strengths, and really jumps in and helps each other out, so that you’re not so stuck, spend hours [indecipherable 11:38] .

This methodology really does get everybody’s creative juices flowing, and I think developers thrive in this [indecipherable 11:57] . Somebody that you don’t really know how much they’re producing, or how quickly they can produce until they are standing up every day, and telling you everything you’re doing, and it’s contagious.

If I was writing this [indecipherable 12:14] mentally different approach.

Clayton: If there’s one big takeaway that you’d like people to get from the article, the piece of advice that everyone wishes that they knew before they started, what’s the one big takeaway?

Peg: I would recommend that, especially your first few Agile projects, that you would bring someone in‑house that has some experience, that can help your, if you have a PMO, depending on the size of the organization, but that can really give some guidance to the department, or the organization of the department that is [indecipherable 12:55] managed other projects.

Somebody that, if it’s a consultant, bring them in. Somebody with this real‑world experience, that’s already experienced some of the bruises along the way, so that you can have a more successful [indecipherable 03:14] and a more successful experience.

Clayton: We’re getting close to the end of time here. Is there anything you’ve been interested in lately? A book, or a blog, or any conferences or books that you’d like to promote, and let the audience know about?

Peg: I always took my training from Mike Cohn and reading Mountain Goat Software website, his blog. There are lots of books that he recommends, and I do find that all the books that Mike Cohn recommends do really help you in estimation or writing user stories. There’s quite a few tools that he has on his site, so I would recommend people [indecipherable 14:03] probably go to Mountain Goat Software.

Clayton: Peg, we thank you for your time today.

Peg: You’re welcome.

Clayton: As always, we invite the audience to check out the Agile Weekly Facebook fan page, where you can talk about this episode and other episodes as well. I think that’s about it, so thanks again, Peg.

Peg: Thank you.

[background music]

Man 1: 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.

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

Man 3: 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.

Man 4: 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.

The post Episode #82 – Implementing Agile with Peg Haustetter appeared first on Agile Conference

Join us this Fall for the first Agile conference in Arizona. Agile Open Southwest is a regional event for agile practitioners. Perfect for those curious about adopting agile principles. Excellent for those that already agile practitioners. Suited for experts training and coaching others. Assemble and meet new people while sharing your work and thoughts. It follows the Open Space format so it will have topics relevant to those attending. Expect technical topics. Enjoy management topics. Quality assurance will surely be represented.

When: Friday November 16th, 2012 (8:00am – 5:00pm)
Where: Chandler Gilbert Community College (Chandler, AZ)
Cost: $75.00

Register Online Now!

This event is capped at 75 people. First come, first serve.

Interested in being a sponsor? Get more information.

(The El Toro Sponsorship includes a mechanical Bull!)

The post Agile Open Southwest 2012 – Agile Conference appeared first on Episode #81 – Spike Stories, Estimating Before Planning and Blocked Stories appeared first on Agile Open Southwest – Friday November 16th, 2012 – http://agileopensouthwest.com

Who Should Attend?

Anyone currently working with, interested in or otherwise involved in the Agile community will benefit from the conversations and relationships generated during this event.

What To Expect?

As an Open Space event, the conference content will be created organically by the participants as the session convenes and throughout the day. For more information about the Open Space format, visit http://www.openspaceworld.org.

When is it?

Friday November 16th, 2012. Registration and breakfast starting at 8:00AM with the closing session finishing at 5:00PM

Where Is It?

Agile Open Southwest will take place at the Chandler-Gilbert Community College Pecos Campus (2626 East Pecos Road, Chandler, Arizona 85225-2499 – map) in Chandler, Arizona. Lodging is available nearby at the Hampton Inn & Suites Gilbert, Hyatt Place Gilbert and the Crowne Plaza Resort Hotel San Marcos.

The post Announcing the Inaugural Agile Open Southwest appeared first on Episode #80 – Demanding Technical Excellence with Declan Whelan appeared first on Episode #79 – The Leadership Mindset with Christopher Avery appeared first on Episode #78 – Leanpub with Peter Armstrong appeared first on Episode #76 – Managers and Developers Growing Apart with Gil Zilberfeld appeared first on Episode #75 The Learning Organization and Scrum with Derek Wade appeared first on Episode #74 – Lean Startup with Aaron Eden appeared first on Agile Open SoCal

Transcript

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

Drew LeSueur: I’m Drew LeSueur.

Jade Meskill: I’m Jade Meskill.

Roy: Joining us today is today is Woody Zuill. How’s it going, Woody?

Woody Zuill: Real good.

Roy: You’re currently at the Agile 2012 conference, right?

Woody: Yeah, I sure am in Grapevine, Texas. It’s really, really nice here.

Roy: Have you seen anything totally awesome there in the last few days?

Woody: Yeah, I’ve gone to a lot of sessions, and they’ve been great. As a matter of fact, it’s really nice to see, in person, some of the people that I’ve read books and followed for so many years. A few of them are old friends now, but some of them I’d never seen before. I think the top thing for me, so far, has been a little one hour session by Robert Martin on clean code. As you can imagine, he’s always good with that stuff.

Mary Poppendieck, who her and her husband, I guess, wrote that Lean software development book, which I’ve put to great use over the years and completely worn out several copies. Eric Meade, I just saw a session by him just a few minutes ago on decision making. It’s a lot of eye opening stuff.

Overall, I think what I’m seeing is that people are really moving forward beyond just the simple Agile ideas, and trying to figure out some bigger problems. I’m enjoying that a lot.

Roy: We had talked to a previous guest, I think that was helping to organize the event, was telling us that there was going to be a much bigger focus on the technical side of things. Have you been seeing that a lot or is it…?

Woody: Yeah, there’s a development stage. I think it’s called development practices stage, and I’ve gone to several of those sessions. But I haven’t been able to go to all of them. They were doing like a code retreat today, and so that’s kind of interesting. I wasn’t able to stop in on that, but those are very code and coding practices focused sessions. That’s sort of my focus. That’s where I think I bring the most value is knowing about that stuff and bringing that to my team and things like that.

Jade: You wanted to talk about Agile success.

Woody: Yes, Agile success.

Jade: What does that mean for you?

Woody: Over the years, I’ve been doing what you might now call Agile since 1998. You add up the years, and when I was first introduced to it the TMI was on. I knew nothing about it except for what I had read, but the TMI was on, what I would consider ultimately successful. They were extremely good at cranking stuff out of extremely high value.

As I watched what they did, I said, “I just want more of this.” Then I went out into the real world, and looked for projects that either people were saying they were doing agile or wanted to do agile. I very rarely found anybody being effective. They were either hoping to do agile or wanting to do agile, but they just hadn’t gotten there. I’ve been through a lot of those things.

Going to these conferences, and these things like the open agile and all the user groups, I’ve talked to a lot of people who are still trying to figure out, “How do I get this working for me?” I put together a little talk just on what I would consider the main things, which is the agile values and principles. It always seemed to surprise people that these things existed, which really bothered me.

That’s sort of where you should start, that’s what you gives you a way to judge, “Is this practice I’m doing helping me? Am I thinking in the right way to get where I want to go?” It’s kind of like something I think I learned when I was a young man, or actually a teenager, and this very, very old guy that I knew, he was in his 80s when I met him, and he was really, really genuinely good. He was good to everybody, he treated everybody nicely.

Then I knew some other old people who were pretty crabby all the time. I started noticing they either leaned towards being crabby or leaned towards being good. Not too many in the middle, who were sort of half‑crabby/half‑good. It dawned on me that you kind of gravitate toward what you allow yourself to be, and so I’ve held that through my life. I want to always lean towards the good if possibly can, so, when I’m old people can say, “You know, he’s a nice old man.”

That’s my goal in life. That’s sort of what the agile success talk was about, if we lean toward the agile principles, then whatever we decide to do for practices are going to hopefully be agile. If they’re not, we’re going to hopefully, more than anything else, adopt that idea of retrospectives or reinventing ourselves continuously. If you really adopt at least that one principle, you’ll hopefully get better as long as you do it in a somewhat consistent manner.

Jade: What were people’s reactions to that proposition?

Woody: What happened is the people that were trying to do agile, but hadn’t even caught on to the idea that values and principles are what should be guiding us, although that seems fundamental to me. Once I started doing math talk then people come up and say, “We’re already trying to do all these, but we’re having these other problems.” I ended up, eventually anyways, adding some of my own principles and values. That sort of an important thing is there is the agile values and principles were kind of locked down quite a while ago. We might…

Roy: That doesn’t sound very agile.

Woody: Exactly. We got to be ready also to sort of adapt. We’re the inventors. We’re the innovators. No less soul than anyone else. We have to take responsibility for our own process where we are headed. I kind of gave myself what I would consider three new maxims.

I had to come up with something, because they already were using values, and they’re using principles. I figured I will use some other terms for the moment anyways I’m calling a maxims. But one of them is this. It’s in the doing of the work that we discovered the work we must do.

If we trick ourselves into thinking we can figure out what we are going to do before we actually do the work, we’re always going to fail. That to me is a critical maxim, and that is my focus every day as we do the work. We are going to discover the things we didn’t or couldn’t figure out before we started doing the work.

Jade: I really like that. Do you have a good story where that maxim came true for you?

Woody: Sure. I’ve got tons of them, so don’t get me started. A good example is in a very simple little project I was working on, there was a couple of features that we wanted to do, and they’ve written out exactly what they wanted. I should change it what I just said.

Their requirements for this project were dozens of pages. That’s none of my rules. I don’t like to call things projects. We’re doing development let’s say we’re doing software development not software projects. Projects is like making a deck or making a model airplane. All the instructions are there, and you got all the parts, put it together. See, now I’m going on and on. But here is the thing, they put together these huge documents, and the team kind of got blocked on actually getting any work done.

They got to the point where they were making no progress, and they were starting to break the already working project that was in production. They weren’t keeping very good control of their source code, so they were really getting into a mess.

What we did is we just sliced off ‑‑ I like the term sliced off ‑‑ a little bit of function that will give them some value today. If they could have it today they could be making more money with this little built functionality. I said, “Well, let’s make a little prototype of that.” That’s another thing. You always have to call things a prototype because nobody understands that we’re working on a real project little bit at a time. But if we make a prototype, that makes sense.

We made a little prototype. They took a look at it. They said, “We want to change this, and we like to change that.” We have written a little bit of functionality based on their nice instruction in their requirements document. It should have been correct, but this proved to them, I think, real quickly, without of saying anything that those document really weren’t the final say on what this was supposed to be. It was in the making of this little feature, it wasn’t much.

I can’t tell you what it was. It’s kind of a proprietary thing, but this little feature that they start discovering what they really wanted to do. But bottom line of that story is after we got about the first five or six really top features all the rest to that thick document went away. They didn’t even ask for even ask for any more it. They switched to another chunk of functionality they wanted to work on. That’s the real value of agile. Maximizing the amount of work that we don’t do, that’s really a wonderful saying. There we go. You want another maxim or…?

Drew: Yeah.

Roy: Let’s go to the next one.

Woody: The next one, I think, what I’ve been seeing a lot is projects, and I hate to use that term, but these are projects where they want the promise of agile. The big part of that is responding to change, but you can’t really do that unless you really have easy to read codes that easy to maintain and easy to grow. My next thing is embracing the change is impossible if your code is not easy to read, easy to maintain, easy to grow and easy to change.

I learned that stuff from my little brother, who is also a programmer. Everything else is secondary. If you don’t get that in there, you’re not going to be able to do agile. It’s got to be easy. Because, you know, when somebody comes in and says, “Wait, wait, we’ve got to change this thing.” Have you ever heard this one, where they say, “Well, you should have told me that in the first place, because now we can’t really change it without pushing the deadlines out.” We don’t ever want to have to use that excuse. Does that make sense?

Jade: Yeah, that’s great.

Woody: I always ask that. Does that make sense? It’s probably kind of a faulty thing to ask, because if you didn’t understand, I couldn’t tell.

The third maxim is really a simple thing. Remember, this is the advanced part of the course. This is not the basics, this is really advanced for people who are really trying to do this, and this is the maxim. Question everything. The main thing I question is the things that I think are the most true. Whenever I catch myself going, “No, this is the way things is,” that’s the thing I start questioning.

Why did I allow myself to get that rigid about something? But I question everything, like we were saying earlier, even the agile manifesto. Not that I need to change it. I just want to make sure I’m on track with it. If something doesn’t bring value I want to discover that. Maybe I can’t discover it, but I can keep questioning.

Someday, if somebody brings to me something I am doing wrong, I want to hear it, I want to evaluate it, and I want to change, if it turns out I am doing something wrong. I want to deliver as much valuable software as quickly as possible in a very sustainable manner. Not all projects are that way, or not all companies are that way. I don’t like to call these things projects, because I want to see them going on forever. Let’s keep adding value to it, as long as there is value that can be added. I probably used up our whole time already.

Jade: We’ve got four minutes.

Drew: The question everything, I like that one. It seems to go right in line with respond to change and also respect and adapt.

Woody: Oh, yeah. That’s the inspect and adapt right there. I just did it in different words so I could copyright it.

Drew: That’s good though. Back to your 12 page featured document story that you told us you know, that was something that you could have questioned right from the beginning.

Woody: Yeah. I would myself question it, but a lot of times when you get in an environment where this is the way they do business, you have to find a story that they can understand. They can’t understand the agile story often. This is the thing, Agile, although it really seems obvious to me, for whatever reason doesn’t seem obvious to a lot of other people.

What seems obvious is, “Hey, let’s make our plan and follow our plan, and we’ll get it done.” Everybody is excited about that, they think it makes sense. But I like more, from Napoleon’s rules of war or whatever he called them, the engage and see. Let’s get in there. We’ll get to wherever we’ve got to be. Let’s start a battle, and then let’s see what the enemy does. Then we can decide what we need to do.

But until we do that, you know, they’re ready to trick us with something. We don’t know what’s coming down the road. We want them to show their hand before we show ours. This isn’t really a war, but I like to engage, and then see what we get. That’s in the doing of the work.

Jade: That’s awesome.

Roy: I believe that you are working very closely with the group that’s organizing the Agile Open SoCal that’s coming up, right?

Woody: Yeah. That’s a great little conference at UC Irvine, that’s coming up I think that’s September 13th or 14th, that’s coming up pretty soon. You guys were at that last year, I remember.

Roy: Drew and I were planning to be there as well.

Drew: Yeah, it was a whole lot of fun. That was my first open space format, and I loved it.

Woody: Yes, that’s a good point. The first one you go to is always the best, the rest of them are pretty disappointing. I’m kidding. I think I’ve been to 10 or 12 of them now, and the very first one I went to was the scrum alliance, scrum gathering thing, and Diana Larson was the facilitator, and it just floored me at how wonderful it was.

Jade: Yeah, she’s great.

Woody: She’s great. The whole event was great. Then this one, I got a chance to get involved with it about three years ago, and last year I was the main host or whatever, and I jumped right on board to do it again this year. It’s a wonderful event at a very nice little venue. It’s very inexpensive right now. Through the end of August, there’s the early bird registration so you can save a little money, but it’s cheap anyway, it’s $250. Right now it’s $150 if this thing broadcasts before then. People can take advantage of that. It’s well worth going to.

It’s also small enough to really get to know everybody that’s there. I think that’s a wonderful advantage to these nice little conferences. This one here, the Agile 2012, it’s really great, but I’m just overwhelmed by the number of people. It’s huge. I don’t know how many people are here, but at least 1500 or something.

Jade: It’s a very different kind of conference.

Woody: For a small town guy like me, I get pretty scared.

Roy: It sounds awesome. I’m looking forward to being there, and hanging out with you.

Woody: This has been great guys. Anything else you want to cover?

Roy: No, that’s it, thanks for joining us.

Woody: I’m looking forward to hearing this and your broadcast. I guess you go out every week.

Jade: Yep.

Woody: Excellent. That’s why you’re called agile weekly.

Jade: That’s right.

[laughter]

Woody: Very cool. Thank you, guys. Thanks a lot.

[music]

Announcer: If there is something you would like to hear in a future episode head over to integrumtech.com/podcasts, where you can suggest a topic or a guest.

Looking for an easy way to stay up to date on 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 Integrum Technologies, and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com, or subscribe on iTunes.

The post Special Episode – Agile Success with Woody Zuill appeared first on Phoenix Scrum User Group (PHXSUG) has been expanding, offerring a North Phoenix meeting in addition to its south meeting (in Gilbert). Along with the great evening offerings, there will now be a morning event in a different format. We will use the Lean Coffee format that encourages discussion of many topics in a rapid-fire and focused way.

Do you want to be better at what you do? Are you using Agile or Lean and hungry for deeper conversation? Need your questions answered or just want to talk about how you can get better or change your organization for the better? Join us for Agile Lean Coffee. We will be using a Lean Coffee format to collect ideas and have rapid fire discussion.

When: Thursday August 30th, 2012 @ 7:00am

Where: Paradise Bakery (101 and Ray Road)

More Information: https://www.facebook.com/events/351342351612145/

The post Agile Lean Coffee appeared first on Episode #73 – Less Everything with Steven Bristol appeared first on Chandler Startup Weekend. Startup Weekends are weekend-long, hands-on experiences where entrepreneurs and aspiring entrepreneurs can find out if startup ideas are viable. Teams focus on customer development, validating their ideas, practicing LEAN Startup Methodologies and building a minimal viable product.

As a team we decided it would be a fun way to spend some time together and challenge our abilities. We told ourselves that we would either join a pitched idea and work as the development team or we would play with an idea of our own and deliver the product. Either way we wanted something that could be done within the short time we had together while leaving no pressure to continue past the weekend. We also knew we were slightly handicapped because we would NOT be working on Sunday.

The Wednesday before Startup Weekend we spent a fifteen minute time box on brainstorming some ideas. Here is the list we came up with:

* Meme Siri – Voice generated meme creation.
* People Near Me – Find people near you and engage them in conversation (specifically replace campaign door knocking)
* Hosted Curation – Move AgileWeekly platform to be multi topic
* Media Timeline – Show how media portrays events over time
* Two Face Opinions – Show how public figures contradict themselves
* Craigslist Car Scraper – Low cost car buying tool
* Lunch Decider App – Mobile app to decide where to go to lunch using core protocols

Friday night we showed up ready to jump right in to something. We got some dinner from Pittsburgh Willy‘s and then started listening to pitches. As the pitches were winding down we decided to keep it just our team because we would not be around on Sunday and to go with the Craigslist Car Scraper. At this point it was about 8pm and we found a room and got started.

We started out by doing a quick Agile Lift Off. This process took us about 30 minutes.

Vision: Allow vehicle buyers with less than $5,000 an efficient way to locate a new vehicle.
Values: Fun experience, Less BS, Less time on Craigslist, Best deals right away
Working Agreements:

* rotate pairs every hour
* ok to checkout
* hourly checkins
* deploy every hour
* no stories greater than 1 hour

We then did a quick story workshop in about 30 minutes to generate a backlog of stories. After creating the backlog we sorted it and started planning. It quickly became apparent that at no stories larger than 1 hour, that 1 hour sprints probably made sense. When breaking down tasks we made our smallest time box 6 minutes or 0.1 hours. Most tasks were either .1 or .2. We setup two clocks, one to measure iteration time (1 hour) and one to notify of time box (6 minute).

At the end of every sprint we would do a Core Protocol Checkin and then do a quick retrospective. After the retrospective we would take a break and play some NFL Blitz. Then right back into another planning (generally about 10 minutes).

We worked from 8pm – Midnight (4 hours) on Friday and 8am – 8pm on Saturday (12 hours) for a total of 16 hours including time for breaks, meals, etc. We had 3 sprints on Friday night and I believe 6 sprints on Saturday for a total of 9 hours of keyboard time.

This is what we produced http://hooptie.co

What we learned:

* we can still practice what we preach
* working agreements are important
* breaks and having fun increase sustainable pace
* things that look really big get small really quick when you break them down
* if you have an eye for simplest solution you can complete more than you think
* getting user feedback early is important and better than arguing to decide what to do
* sometimes good user feedback shouldn’t be implemented right away in favor of shipping
* that deploying after every commit is insanely powerful
* pairing is still an effective way to develop code even under pressure
* having a plan is still worth it even if you are only doing an hours worth of work
* iterations are powerful, the smaller the more powerful

The post An Agile Teams Lessons Learned from Startup Weekend appeared first on Episode #72 – How Management Changes with Agile with Esther Derby appeared first on Episode #71 – Managing Traditional Culture with Tom Mellor appeared first on Agile 2012 Special Episode with Mitch Lacey appeared first on Episode #70 – XP Practices with Arlo Belshee appeared first on @ourfounder and learn more about his company Modus Cooperandi, Inc.

Transcript

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton.

Drew LeSueur: I’m Drew.

Clayton: With us today, we’ve got Jim Benson. I might know him better on Twitter as ourfounder. We wanted to talk today about the cognitive bias and estimation. Jim, I see that you’ve written an eBook or Kindle book about plans and cognitive biases, under just biases in general and plans. Could you give us an overview of what it was that prompted you to write that book?

Jim Benson: Sure. My career actually started in Psychology and as I worked my way through being an urban planner where I built really, really large things, like subway systems and freeways. Later, when I came to software development, it was incredibly obvious to me that people just couldn’t estimate their way out of a paper bag.

Most of the breakdowns in projects regardless of what they were or who they were for, generally centered around problems with the estimates.

I started to look into reasons why that was and I started finding clues in psychology. The psychology of how we approach problems, how we gather information, how we make decisions, all of those combine to really muck‑up our estimates.

Clayton: OK. You know one thing, I don’t know if you are a part of this camp, but a popular mindset nowadays seems to be that estimates are wasteful. No one ever gets them right, so why bother doing them? Where do you stand on that?

Jim: Eisenhower said that planning was important and that estimates for it and plans were useless. I believe that the same thing is true, that estimation is indispensable and that estimates are useless.

Going through the exercise of estimating is actually rather important. When you change it to an active word instead of a physical object, going from an estimate to estimating, then estimating becomes something that you do constantly throughout the project and that’s much more helpful.

Clayton: That is an interesting way to think about it. Obviously there’s a lot of teams that, probably experienced the idea, they do some estimates and that gets held against them or something like that. But I agree that there is something important about that mental exercise.

Now, in terms of some of the biases or some of the more psychology things you hinted at, what are some examples there that you could give us about some things that some agile teams might face?

Jim: I’ll just start to cherry‑pick and I’ll come to the big one, maybe third.

The first one is something called the “availability heuristic.” When you look back on things that have happened and we pick out exemplars of either our fears or our hopes, and we then start to make decisions based on those exemplars. The worst part of this is an exemplar can be status quo.

What we found is that the error in estimates follow almost a perfect Pareto curve, or almost a perfect power curve. We start to feel that we’re very good at estimates because we actually do get them right, about right, or excusably right, about 80 percent of the time. The other 20 percent of the time, we perceive that we are dead wrong, so we say “If I could just get that last 20 percent right, everything would be fine.”

But it’s actually a natural power curve, it’s a natural law, especially in software development that we’re always going to fall prey to because there’s too much variation in our work for us to estimate accurately, a 100 percent of the time.

Clayton: Take scrum as a methodology that puts a lot of emphasis on predictability and timeboxes. Usually in most of the training literature there’s a lot of emphasis on the estimates, specifically Planning Poker.

On a scrum team, do you think they just need to find some way to overcome some of those biases and problems, and just deal with it? Or should they find creative ways to avoid those issues, or creative ways to do estimates differently?

Jim: I’ll start this by saying it is dangerous to ask me about Planning Poker, and then I will try my best to state this as distinctly as I possibly can. Planning Poker itself was devised to get around groupthink and other cognitive biases to play teams.

The theory behind it was, if you got people together and they in silence and at least cognitively separated from each other came out with like an opening bid for what the number of story points were for a given story, or a given task, or given feature, or whatever you are estimating against. That will overcome the bias. What happens in teams almost uniformly is that as they do planning poker over time, the teams’ estimates become more uniform.

People see that as a good thing because they see that the team becoming more accurate. But what’s actually happening is that the team is learning how everybody else learns. There’s a heuristic that is being developed within the team that says, when we as a team sees this, we do these things. The individuals stop acting like individuals and they start acting like a team and our time planning poker becomes less and less useful because the individual is sublimated to the will of the group.

A lot of people will argue with me about that because it’s a hard thing for you to swallow as an individual because you don’t feel like you’re doing that. But the actions of the coalescing of the estimates of the teams are very good indications that that indeed is what is happening.

Clayton: Is that something that, if you go back to the a typical or particular size scrum team, if they are coalescing on those estimates, does it really matter if the estimates are kind of…if they can come full circle with the group think thing…if they are using their velocity, maybe their estimates are all close to each other because they are all kind of learning maybe subconsciously however on those estimates.

But does that really matter in the overall schema of things or is that something that they should avoid?

Jim: It doesn’t matter because they are still going to be wrong 28 percent of the time, not because they’re wrong, so I want to make this clear that the people doing planning poker are not wrong. The estimates that they are doing for at least…say you have a three‑point story and you have six of them and four of them are right. Let’s say the three‑point story takes three hours to complete.

They do 3,3,3,3, and that’s fine, and the next one is 7 and the next one is 11. That is a valid distribution on our Pareto scale. All three of those different time signatures or time stamps are all valid for that three‑point story.

The problem is our commitment, the sprint commitment, does not take that into account. One of those three is going to end up taking 11 hours. It’s going to make people blow their sprint commitment and people are going to feel bad about that and then they’re going to wonder why and they’re going to try to fix it the next time but it’s not really valid to fix, because statistically that was a valid distribution.

Clayton: I would question that a little bit, Jim. You’re absolutely right if you look at probability theory you roll a dice, a three‑six‑sided dice or a six‑six‑sided dice and the number of times you’re going to get a distribution curve that’s just like what you’re talking about. But if the team were to do a commitment driven approach to planning I would argue that they would know that one three‑point story was 11 hours and one three‑point story was 7 hours before they actually made the commitment.

Jim: And that’s awesome. That’s completely awesome and I’m happy with that. The thing is that right now, this conversation we’re having is about a hypothetical team that is operating at a hypothetical level self‑awareness and most teams A, aren’t that self aware and, B, don’t have the luxury to backpedal when they find out that there is variation in their system.

Clayton: Yeah, I think that the real problem is that we’ve propagated for far too long on this community that yesterday’s weather is a good way when using story points to predict tomorrow and then actually ask teams to make commitments against yesterday’s weather.

And as any weathermen would tell you that they’re not probably willing to bet their jobs on yesterday’s weather and I don’t think that sprint teams should be doing that either and so how do we start educating people that if you’re going to take the time to estimate and if you’re going to take the time to use velocity, that you use the proper techniques to actually make it meaningful.

I would almost argue, to most teams, it is not even worth them taking the time to estimate, because they’re not doing release planning. They’re estimating for, I guess, just to make their boss feel they’re doing as much work as they say they can do, but it’s not being used for anything meaningful, so it almost defeats the purpose.

Jim: Yes, I would agree with that. I do want to make it clear that my dislike of the measure of story points doesn’t really have too much to do with agile or the active estimating. It has to do with creating a system that doesn’t translate well from one part of the organization to another.

Story points end up being integers. Those integers are communicated to people who try and interpret them, and they’re going to interpret them incorrectly, because, for the team, it’s a relative measure of what ideally would be bizarreness. That’s a 13‑point story, because it’s really quite bizarre.

But other people are going to uniformly interpret those as either money or time. That’s very dangerous, and it leads to a lot of unnecessary conversations and unnecessary meaning. I actually think that the active estimation is awesome, but the creating an artifact that can be so easily misinterpreted is dangerous.

Clayton: Is it really dangerous, or is it just being used improperly? One of the things that I would argue is that, I think, the reason why teams should probably use points if they’re going to estimate is because they are integers, and they can be used for things. The problem is the people used them incorrectly for a time.

If I try, as you stated earlier, say, how many hours is three points equal to, that is very, very dangerous, because three points, by itself, is going to be very highly variable. However, if I’ve got 100 three‑point stories in my backlog or in my release plan, I can probably get some normalized numbers out of there.

If I say, “Hey, for the last X number of sprints, we’ve been doing roughly X number of story points,” while still an estimate, I can predict the future to a degree ‑‑ several weeks or even a month or so out ‑‑ to be able to say, “I should be able to get roughly somewhere in the neighborhood of this.”

I think people get in trouble when they make them absolutes, when they don’t have the discussions around it, and then they take those numbers to be, “Well, you said you could do 30 story points, so I took 30 story points times 10 iterations, and, by God, you’d better give me 300 story points.” That’s dangerous.

Jim: Exactly.

Drew: You talk about the state of estimating. I’m wondering, what does that look like? If it’s not story points, what does that look like? Also, how did you apply that with the bigger projects like subway systems, or whatever, that you did?

Jim: I will answer that by skipping forward to [inaudible 13:28] , because, if we’re having a cognitive bias conversation, I should probably say something about cognitive bias. The one I’ll talk about really quickly here is the planning policy. The planning policy is exemplified by something called Hofstadter’s Law.

Hofstadter’s Law states that, when given a task, people will uniformly underestimate that task, even when they are aware of Hofstadter’s Law.

[laughter]

Jim: The planning policy basically says that, that we, as individuals, are really lousy at estimating, we’re extremely lousy when estimating for other people, we’re unbelievably lousy when estimating for ourselves, and we’re just super incredibly terrible at it when estimating for ourselves with witnesses.

When you get into a situation where you’re estimating, we have a lot of natural tendencies to underestimate the thing that we’re estimating. This has been tested by psychologists, social scientists, and behavioral economists around the world. It’s been shown to be a cross‑cultural, universal human condition.

Part of the reason for that, I believe, is that we don’t understand the role of variation in our work, so we don’t understand that Pareto distribution all along a three‑point story. Therefore, when we promise things to people, we promise them like, “Every time I do this task, it will take me three hours.”

In software development, we do not have that luxury. Our work is way too variable. What I replace that with is either cycle time or lead time with some sort of visual control. It might be a Kanban and it might be something else, but, if you have a system that can measure when you start working on a task, or a feature, or a user story, and, to the point that you finish it, that’s it ‑‑ cycle time.

It doesn’t care what excuse you have about why it took longer than you thought it would. What it will do is will say, “That task was a three‑hour task that I got interrupted four times, so it took me 12 hours.” I’ve got bad news for you. For deliverable standpoint, it was a 12‑hour task.

Replacing story points with actual statistical measure of what is completed and how long it takes to complete that thing is extremely powerful. When we do that, we get an added benefit. We used to have to say, “Well, this is a two‑point story,” “This is a three‑point story,” “This is an eight‑point story,” and so forth.

Now, we can say, “That story is too big,” or, “This story, I can do. I don’t care if it’s going to take me an hour, if it’s difficult, or I don’t care if this can take me 13 hours,” because, over the course of the project, the distribution of those stories from small to large is going to be relatively stable, is going to be relatively like it was in the last project.

We’ve been finding that that distribution is uniform or fairly uniform between projects, and, when we start to distinguish between things like a three‑ or a five‑point story, we run into something that’s called distinction bias, where human beings love to figure out what the difference of nearly identical things are.

When I’m doing this before a crowd, I can hold up two green pens, and people instantly, everybody in the room who’s looking at me, are trying to figure out what the differences are between the two things that I’m holding in my hand, and they’re both the same green marker pens.

So using a statistical measure that is impartial to our excuses and immune from a couple of these biases ‑‑ not all of them, but a couple ‑‑ helps us build more predictable models.

Clayton: The one thing that I could say that could be a potential downside to that is it requires you actually do the work.

If you’re trying to say, “Here’s a project that we might want to tackle, and we’re not sure how feasible it is. Developers, could you give me some ballpark so that I know am I looking at something that might be 6 weeks or something that’s 60 weeks. I don’t have to be precise on it, but I need a rough ballpark to know if it’s something I want to go, grab funding for.”

How do you do that in the cycle time model?

Jim: There’s two things, if you’re starting and you don’t have a cycle time, then you do a traditional estimate. If you’re starting and you do have cycle time, then you use your cycle time.

You can only start from where you are and the fact that you don’t have data yet doesn’t mean that you can’t collect that data. I’m particularly well known for hating metrics. I don’t like to use that many of them. Basically the only numeric metric that I use are the two that we’re talking about, and the reason for that is that most metrics are lagging indicators.

Right now, the question that you’re asking me is, “If I get this metric, that’s all well and good, but is it best going to be a real‑time indicator and more likely is going to be a lagging indicator.”

If you’re starting a big project, everybody is going to need to get around and they’re going to need to figure out what the level of effort assumed is for that project. After you have this information and perhaps before if you could run some spikes, you can start to figure out what that cycle time is and then you can say the things like, “I believe that the project you’re giving me or we agree that the project that you’re giving me is made up of these 50 initial user stories.”

You’re now buying an option from this team on 50 user stories. We agree to deliver 40 or 50 user stories. Between now and the completion of the project, which we anticipate given our current cycle time is going to be this date. We will do 50 user stories for you, and frankly, we don’t care what they are.

As we move through the project, we’re really not worried about what the specific user stories that are coming up are because we as software development professionals know that over the course of the project 80 percent of the features change anyway.

They’re basically buying a block of work as opposed to a product and assuming that their product will be able to be done within that block of work.

Clayton: I think we’ve definitely stepped into a very interesting conversation, but unfortunately, we’ve run out of time here. If people listening wanted to find out more about you or if there’s any books you think they should read or anything like that they should check out, where would they do that and what kind of suggestions would you have for them?

Jim: OK. The self‑serving parts are my name is Jim Benson, and I’m at ourfounder on Twitter, and I’m ourfounder on just about everything else that has ever been put on the Web.

We currently have three books out at Modus Press, one is “ScrumBan” by Corey Ladas and other is “Personal Kanban” by me and Tonianne DeMaria Barry and the third, which is specifically about these cognitive biases is called “Why Plans Fail,” and that’s just an eBook, it’s a little $2.99 eBook.

The Personal Kanban website, which is personalkanban.com has tons of blog posts and free information. My personal blog is ourfounder.com, and my company is Modus Cooperandi, which I’m not going to spell for you, but that’s what it’s called.

Clayton: We’ll use Google Suggest, how about that?

Jim: Yes.

Clayton: We also like to invite the listeners to check out the Agile weekly Facebook page where you can continue the conversations for these different podcasts and one that we have.

We wanted to say thanks for joining us today, Jim. We really appreciate your conversation.

Jim: Thank you guys. This is fun.

[music]

Announcer: If there’s something you’d like to hear in our 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 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 at Gangplank Studios in Chandler, Arizona. For all the episodes, check out integrumtech.com or subscribe on iTunes.

The post Episode #69 – Cognitive Bias in Estimation with Jim Benson appeared first on Episode #67 – Design Thinking with Jeff Patton appeared first on Episode #66 – Deloitte Digital Agile with Alex Sloley appeared first on Certified Scrum Trainer in Canada discuss adding new members to scrum teams:

ScrumMaster Tales
Storming, Forming, Norming, Performing
Disrupting teams with new members
Team hazing rituals and on boarding new members
Dealing with crises in Scrum
Avoiding conflict in Scrum?
Working agreements
Part-time Scrum Master
Neutral Scrum Masters

Transcript

Drew LeSueur: Hi and welcome to another episode of the Agile weekly podcast. I’m Drew LeSueur.

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

Drew: With us we have Mark Levison. Mark, tell us a little bit about yourself.

Mark Levison: I’m one of Canada’s two certified Scrum trainers. I’m based in a part of Canada called Ottawa where it’s already dark outside, even though the rest of you are still looking at sunlight. I have been in the Agile business one way or another for about 12 years now. I do a lot of writing on a blog, and these days I’m spending a lot of time writing about a Scrum Master named John, and all the problems I throw him as he and his team try to win their way through the Agile world.

Drew: The article that we read that caught our interest was “Scrum Master Tales ‑ New People on the Team” and you talk about John and he’s struggling with a new person who’s on a team. Can you talk a little bit about that?

Mark: Like any organization, John’s team grows and at the critical moment they decide they need a bit more senior technical help. They hire in a character named Kirby, and Kirby has over 20 years experience developing software. He thinks he’s seen and done it all.

It turns out that Kirby is very, very loosely modeled on me. Kirby strolls into the team and starts throwing his elbows around, he’s extremely knowledgeable and very skilled, but he’s not very human‑skilled.

He’s thinking a lot about what’s wrong with their code and very little about their personal needs and understanding how they came to that position.

Roy: I agree. One thing I liked about this article is we through around the concept of forming, norming, storming, and performing as phases of a team. You mentioned that when some person gets added onto the team, that process starts all over again.

Roy: For the entire team, not just for that individual right?

Mark: Yes. The way I illustrate this when I’m running a CSM course, I have a group of people sitting at a table, and by the time we’ve talked about this in the course they’ve already formed a fairly tight team. They’re often sitting a lot closer together.

I simply walk over as the instructor, pull up an empty chair, and jam myself in the middle of the table and start pushing people to one side. Of course, what happens is ‑‑ I don’t do it too rudely ‑‑ but that ripples around the table. People start to realize, that even though they weren’t sitting next to me, when moved in next to one of their colleagues, their position on the team got affected.

My claim is that you’ll have the same outcome when you introduce a new person to a technical team. Even the people who hop away, wind up finding their role changed as the new person comes in.

Roy: What’s the fastest way to on‑board somebody if you’ve got a new person coming in? How do you just rush through the forming, norming, and storming stages and get to performing as quickly as possible? Is there a quick path or is that something that needs to take its time?

Mark: I wish there was. It’s funny. It comes up in nearly every one of my courses and with nearly everybody. I have a little test at the end ‑‑ not the scrum lines test ‑‑ but my own personal test to make sure we understand what people have really understood.

In every course, I can guarantee you at least two people will answer the question about conflict ‑‑ to which the answer is conflict is natural and cannot be avoided. They will answer that conflict can be avoided with skillful scrum mastering.

Roy: Ooh…

Mark: Sadly, no. I’ve not found any skills yet which allow us to avoid conflict. There’s no better way to deal with it than to simply allow it to happen and to get through it.

Roy: I’ve been on a few teams that wanted to jump the idea of conflict through a form of hazing, where they wanted to have a gauntlet for new team members to run through. What kind of impact would something like that have on the team?

Mark: Wow! That does not sound like a great idea.

[laughter]

Mark: My first thought is it puts the new person in position of weakness and possibly fear, depending upon how bad your hazing rituals are. I went to a university where the hazing rituals were fairly unpleasant. It puts the existing people in a position of power. If anybody really wants to think about just how dangerous that can be and how far it can go, they should read some of the original prisoner experiments from the mid ’60s.

I can’t remember the author’s name.

Roy: Were those ones in response to the Nuremberg Trials?

Mark: I’m thinking of one called “Prisons We Choose to Live In”, I think. It’s a series of psychological experiments where people were recruited. Some people were made guards and other people were made prisoners and very quickly, evil and not good behavior started to evolve.

The gist of is that sounds really quite dangerous. That sounds like it sets up power relationships which are not very good.

Roy: Sure.

Mark: I’ve not encountered that before. I’d have to go give that a lot more thought.

Roy: Luckily, the team that I was on, or one of the team members that were pushing for that, ended up rejecting it. We didn’t actually go through with it.

I agree with you, it would have been a dangerous idea. I think it stems from the idea that a team seems to form quickest when they have to rally together around some kind of crisis, right?

When there’s a need for the team to form or, even if there’s ‑‑ in lack of a crisis ‑‑ a strong vision. That might have been the driving force behind it.

Mark: A crisis is exactly what it takes for team formation. Luckily, in Scrum, we usually get the crisis fairly quickly. It’s one of the joys of Scrum, I might point out.

In my course, I simulate this. I actually use Scrum to run my course, so I have a burn‑down, I have a back‑log. The course is a product back‑log, there isn’t printed agenda.

We have our first crisis at the end of sprint one, when it becomes clear we cannot achieve all of the material that we’ve set out. Then, we have to do some radical reprioritization.

That usually has them desirable effect of throwing the team into crisis, in the sense of a real Scrum team ‑‑ maybe not on my CSM course. I don’t need to create artificial crises. They usually take care of themselves quite nicely.

Roy: That’s a good point.

Mark: Honestly, I’ve never seen a team that didn’t, after the first few sprints, quite naturally start trending into storming. My favorite analogy is, “If you interrupt me and I’m in the IDE, your interruption had better be damn good. Actually, it better be a serious reason.”

If on the other hand, I’m browsing cnn.com, “Hey, any old interruption is good”! That’s the beginnings of storming there. I’ll yell at you if it’s not ‑‑ I won’t really ‑‑ I might pretend to yell at you if it’s not a very good interruption and I’m in the IDE, and I’m doing something I think is valuable. I might be more open to it when it’s just cnn.com.

Roy: Earlier, you mentioned about people entering that scope of Scrum Mastering that will allow them to avoid conflict. I’ve seen that in the past where there are individuals that are so against the idea of conflict that they’ll do anything to prevent it from happening, even when they wouldn’t even be involved.

For example, Scrum Master just hates conflict so much that they will try to prevent it. You had mentioned that it doesn’t really seem possible to avoid the conflict, but is it healthy to even try?

Mark: In fact it’s even worse. If you try you’ll probably set the team back. I try it all too often myself and what I find happening is…I can’t remember, I think, it’s Kirby and Markman…I’m pretty sure are in conflict.

Let’s say we go to Kirby, “Kirby, would you please stay clear of Markman’s tasks for, at least, the next two weeks”? “Mark, would you please stay clear of Kirby for the next two weeks”?

I haven’t really resolved the problem. All I’ve done is taken two warring parties and told them to back off. A much better solution to this problem requires getting them to talk. I might take them individually out for coffee just so you can hear each of their sides.

[jokingly] A great Scrum Master spends 20 to 30 bucks a month on coffee or tea, if that’s your preferred beverage.

Roy: I like that.

Mark: Take them out each individually for coffee, hear their respective sides and then, if this is an on‑going issue and it isn’t just the first time, maybe bring them together and see if they can create working agreements, but the point is you don’t ever actually do anything on their behalf.

You simply help them come to the conclusions that they need to come to.

Roy: In your article, you mention a lot about that ‑‑ where it’s very important for the Scrum Master not to take a side, to remain unbiased. That’s got to be hard for a lot of people. Can you elaborate a little more on that? How is that possible?

Mark: It’s hard for a number of reasons. A lot of organizations have part‑time Scrum Masters, who is usually a Developer. At the moment, we have Kirby come in. Kirby is going to see John as the Scrum Master/Developer in that case, and he’s going to assume John is primarily friends with all of the existing people.

Instead of seeing John as someone who is playing the role of neutrality and balance, he sees John as another friend of those developers who aren’t churning out very good code ‑‑ someone else to do battle with.

There is no great solution except that you have to win people over a little bit at a time, and you have to be seen as being neutral. You have to make it clear that there are no sides ‑‑ that your job is the care and feeding of the entire team, and not just any one individual. That can be really difficult.

Frankly, I suspect that will be just as much a problem in the Kanbanny world as it is in the Scrummy world.

Roy: We just published or are about to publish a podcast in which Derek talks about most of these problems that we’re seeing in teams having nothing to do with the process.

The process just seems to highlight them, and almost exacerbate them. The point of the process seems to be that we need to highlight these problems, so that we can attack them.

Scrums aren’t going to solve your problems anymore than Kanban, or any other processes. The important part is to cycle as often as possible, get some feedback and get better.

Mark: Exactly. I shock people in my course on a regular basis by making the rather bold statement, “Scrum has never solved a single problem.” Scrum merely helps you see what problems you have already.

People are shocked. They think they’d spend a lot of money to get their problems solved, and they’re very surprised when I explain that no problem will be solved.

Roy: I like also in your article, you talk about if the team had been more involved in the hiring process from the beginning, it would avoid some of these problems, or maybe avoid bringing a member on who wasn’t a great fit.

I’ve been in a setting where we did do that, and it was great. The whole team got to pair with the potential hire and they got to decide as a team, “Is this a good fit for us”? How about you? Can you share an experience?

Mark: I have seen a few examples of that, but sadly I never got the chance to do that when I was employed working for real companies before I moved into the consulting world.

My favorite example of that recently goes one further. The folk at Menlo Innovations in Detroit go one further ‑‑ they get the candidates to pair with each other, the thinking being, “If you can make the person you’re supposedly competing for job with look good, you will make every one of your peers look good.”

Roy: That is an awesome idea.

Mark: Yes, I’m looking for someone who’d like to have me run that as an experiment with them. [jokingly] By the way, please don’t take the forgoing as legal advice in the United States of America.

[laughter]

Roy: That sounds like a really neat idea to try. I can’t imagine as an interviewee though getting paired up with another interviewee that I’m competing with and trying to make them look good like that. That’s going to be tough, but I really like the idea of trying to see what comes out of that.

Mark: I suspect if I tell too many people about it, the secret will get out and maybe the secret sauce will be lost.

[laughter]

Roy: That’s true. Thanks a lot for joining us on the Agile Weekly podcast. For those of you listening, feel free to participate in the conversation at facebook.com/agileweekly. Mark, did you have any last words, anything to share with the listeners?

Mark: Don’t stress. When you see your team going through forming and storming, don’t stress over it. Let it happen ‑‑ it’s going to happen at the pace it happens. There’s nothing you can do except watch, and think of yourself as a sheepdog and not a leader.

Roy: If you get a chance, Mark’s blog can be found in the description of this podcast. All right, thank you very much. Thank you Mark.

[background music]

Mark: Fantastic guys. Thank you. Good night.

The post Episode #65 – New Team Members with Mark Levison appeared first on Special Episode: Interview with the Mathsters appeared first on The Myth of 100% Utilization“:

What is the 100% utilization myth?
Kanban and WIP limits
Slack time
What’s a good amount of slack?
Experimentation with slack and utilization
What does a team do with slack time?
Should slack time move the team/work forward?

You can find Pawel on twitter @pawelbrodzinski and on his blog Software Project Management.

Transcript

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich…

Derek Neighbors: I am Derek Neighbors…

Pavel Brodzinski: And I am Pavel Brodzinski.

Clayton: Welcome, Pavel. We’ve found an article that you wrote, it’s entitled “The Myth of 100 Percent Utilization”. I was curious if you could explain a little bit about the motivations for writing this one and kind of what you mean in terms of what is the myth of 100 percent utilization. If you could just introduce the topic a little bit, that would be great.

Pavel: The motivation to write the piece was that what I see over and over again in different organizations is that the organizations or managers are trying to optimize the way people work, the way companies work in a way that everyone has something to do all the time. We basically are trying to utilize people for the whole time. We aim for 100 percent utilization.

If you learn a bit more about the subject, you start thinking it is not the best way of organizing work. By implementing Kanban, we implement WIP limits, work in progress limits. If WIP limits are set correct, it usually means that people will have some idol time, which is called slack time. It actually is a mechanism that the team makes the organization improved.

My main motivation was sharing the idea and spreading the word. What I tried to do was to explain why thinking of utilization in the first place is the wrong idea to have.

Clayton: Is there a good level of slack time or amount of slack time, that you think on average a team should spend with no assigned task, so to speak? Is that going to vary from team to team and situation to situation?

Pavel: When I think about utilization in terms of different contexts, for example, traffic on a highway. There is, I don’t remember the numbers, but something around, I believe, 70 percent, which is the optimum, the point where most cars are going through the highway.

However, I would say that in terms of teams, it’s not that simple. You can say that teams should have around 20 or 30 percent of slack time. What I believe in is experimenting. You should try to tweak WIP limits, tweak the way you organize work in your team, and measure what the optimal way of working is, in your case.

In terms of knowledge work, we deal with high variability of tasks we work on. It’s not that one car passes through the highway in pretty much the same time as another, as our tasks differ. It can be said that there is some kind of ideal number. I believe every team needs to find their own sweet spot. It will be floating, by the way, it’s not something that is set for a longer time.

Clayton: In terms of the time that…let’s say that a team has some slack time. What do they do with that time? Is that time that they burn down technical debt, fix defects, or experiment with new things…If I’m a manager and I’m willing to accept that the team should have some slack time to do other things, this will not be a hundred percent utilized. What are they doing with that time? Are they doing nothing, what exactly would that look like?

Pavel: It would depend on policies you have in your team. Because you can have some guidelines, what kind of tasks people should choose first, during slack time, but…most teams I know have freedom, in terms of they use their slack time.

In an ideal world, by the way this is something I teach in Kanban, the first task to be taken, would be either swarming on tasks that are already now a bottleneck. Let’s consider the situation that we have, say, too many developers and too few testers or quality engineers. We have this bottleneck in testing. Basically, after some time one of our developers would have this slack time. In an ideal world, he would either take one task and test it or maybe swarm with one of the quality engineers, to deal with the other task faster.

However, we don’t live in an ideal world. Most of the time, when a developer faces the opportunity to test [sarcastically] , he will do anything to avoid using this opportunity.

[crosstalk, laughter]

Clayton: Yes. Right.

Pavel: In the long run, that’s even better, because usually they would spend time working on things that optimize the whole process, for example, automating some testing. Because this is fun, this is still development, and yet it helps quality engineers to shorten the time they spend on their regular tasks.

This is the story of one of my teams that are actually working on this kind of tasks, automating tests, improving code quality, simplifying configuration. We were able to remove this bottleneck in testing because we improved the way we build the code, the way we build up. Developers had fun, working during their slack time, and still we improved the whole process, the whole end to end process. I would say that it’s pretty safe to leave much freedom to team members to choose what they’re doing during slack time.

Derek: I follow that you’ve been bantering back and forth on this a few months back where, maybe it’s optional task stuff, maybe it’s important task, maybe it’s my inability, from the English language perspective, but I’m feeling a very strong disconnect to the logic. What I’m hearing is that people should not be a hundred percent utilized, yet they should have slack time. In the slack time they should be doing things that propel the company, the sprint, or the team forward. To me, that’s a total disconnect.

If we say, “You should be doing something for the company a hundred percent of the time that you’re at work,” and then we go, “Oh, no. We don’t really believe that, what we really believe is that you should only plan 80 percent of your work, but the other 20 percent that’s not planned, you should still be doing something that moves the team forward.” I’m having a disconnect there, in the sense of…I guess I’m more of a believer that in creative work you need to allow your brain time to process things.

If you’re doing, I don’t want to say slack time because I just think it’s a horrible terminology, a horrible expression, because it has so many meanings within the English language that are bad, [?] got baggage with it. May be the Pomodoro method’s an easier way to articulate it. You’re doing some volume of work, whether it be 60, 80, 90 percent, some planned form of work, and then the remainder is really more of a state of play, where you allow your mind to process…whether it be play video game, table tennis, or take a walk around the campus, whatever.

I was thinking that the concept of not being a hundred percent utilized is that we’re not being fully utilized, that there’re some cycles outside…so maybe, if you could help clarify some of that…it would help me.

Pavel: The first perspective is that we look at a hundred percent utilization from the perspective of building new theories of doing our regular work. When we introduce WIP limits, we try to avoid starting too many things at once before finishing some of them. This is the first thing.

However, you aren’t actually forced to do this improvement work during slack time. You can perfectly do nothing. You can take a walk. You can take a break and do nothing in terms of building any value, and it would still result in better effectiveness of the team as a whole.

However, what I find typical is that people actually do find time to think, do find time to have a break and play foosball or whatever. They don’t have problems like this. They still are starting too much, too many concurrent tasks. They still build those huge, huge queues in the process which make all the work of the whole team ineffective.

I don’t really see introducing WIP limits, introducing slack time as a way of building this spare time to think because from what I witness in many organizations is that people, whenever they need, they actually take this time to think, to take a break, to refresh themselves but still do have problems with effectiveness in this other area. This is my view on this subject.

Derek: I don’t think there’s any easy answer because I think that we can all agree that you end up with queuing problems if you have a hundred percent working on feature mentality and don’t have any slack to deal with the world around you.

I think we can probably all agree that creative people need some time to process things. It’s just a matter of what we call it and how it’s planned for and how it’s probably communicated to managers or people paying the bills in a way that that they can understand that they don’t feel like people not working on whatever, to them, feels like the most pressing thing, right?

Pavel: Yeah, exactly.

Clayton: Let’s say for instance a scrum team, and they’re using a commitment‑driven approach or capacity planning where they say, “We have a hundred hours of available capacity for this sprint.” They pull in stories. They pull them in, and they task them out and everything, and they try and build up until they get to the hundred hours.

Let’s say they’ve been doing that for a while where they try to pull in as many tasks as they can, I think, that they can commit based on their capacity. Would you recommend that they lower their capacity a little bit so that they do have some of that slack time? Do you think that would be beneficial to that team?

Pavel: I would definitely try this kind of experiment because what you end up when you try to pull as much as possible, you end up doing features, doing tasks ‑‑ those regular tasks ‑‑ all the time. Basically, what you don’t have time for is this kind of improvement work.

When you’re thinking about a classic scrum team…In sprints, we limit our work in progress in pretty different way than we do in Kanban. We don’t try to limit the number of tasks which are on this stage or the other stage, but we just have time boxing which is just the other idea of how we can limit work in progress because we can only have that many features that’s queued into our sprints and not anything more.

I would definitely advise trying to introduce some time for improvement. Maybe to commit to one feature less or one story less and see what happens. If nothing changes, in scrum it’s not a problem to pull one more story out at a later time during sprint. We usually have this bunch of stories that might be in sprint, but we don’t commit to them, right?

Clayton: Right. I think we’re actually about out of time here, but if listeners want to find you maybe a blog or on Twitter or if there’s anything you’ve been interested lately and a community that you’d like to share with the audience, if you can just let them know where they could check you out and see some more of your articles.

Pavel: A basic, basic place where people can find me is the blog which is blog.brodzinski.com, B‑R‑O‑D‑Z‑I‑N‑S‑K‑I. My Twitter handle is PavelBrodzinski, which is my first name and surname.

Clayton: We’ll put those in the show notes for you.

Pavel: Yeah, but basically if you Google my surname, all of the results somehow connects with me as that name isn’t that popular, I guess.

Clayton: [laughs] That’s a good one to have.

Pavel: Yeah, that’s true.

Man 2: Well, thanks a lot for joining us today. We really appreciate it, and we look forward having you on again.

Pavel: Thanks for having me.

[music]

Announcer: If there’s something you’d like to hear in the 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 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 at Gangplank Studios in Chandler, Arizona. For old episodes, check out Integrumtech.com or subscribe on iTunes.

The post Episode #64 – The Myth of 100% Utilization with Pawel Brodzinski appeared first on Manage Your Job Search

Using personal Kanban to manage the job search
Breaking down tasks into small, manageable pieces
Collect feedback in small iterations and pivot
How do you hold yourself accountable?

Transcript

Derek Neighbors: Welcome to another episode of the Agile Weekly podcast. I’m Derek Neighbors.

Drew LeSueur: I’m Drew LeSueur.

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

Johanna Rothman: I’m Johanna Rothman. Thanks guys, for having me.

Derek: Oh, thank you. Johanna, I know that you’re working on a new book that is about how to maybe go about using some agile practices to change your outlook on getting hired. Why don’t you tell us a little about the work you’re doing?

Johanna: I have a new book in beta called “Manage Your Job Search” with a totally ridiculous subtitle, which is, right now, “Reduce your overwhelm, focus your search, and get your next job.” I’m going to change the subtitle. But I think the title is “Manage Your Job Search.”

It’s on Leanpub, which is the way I’m writing my next couple of books. It’s Leanpub/get your next job, and I have a new version of the hiring book also on Leanpub right now. As soon as I have the title for that and a cover, I’m going to hit the publish button for that, too.

The idea with “Manage Your job Search” is, if you use Personal Kanban and work in one week Editor Relations you actually can stay focused and work on your task in really small chunks and figure out “How do I’ll do a little experiment, and get my next job”?

One of the problems with a job search is you say, “I have to write a resume,” but writing a resume can take you a week, and you have to say, “No no no, I can do the first draft of the resume. I can get it reviewed by a few people,” And maybe you can say, “Well I don’t know. Should I be a Product Owner? Should I be an Agile Project Manager”?

I actually am one of the few people that says, “Yes, we do need Agile Project Managers, not everyone can be a Scrum Master.” Because, if you read my stuff on geographically distributed teams, I actually think you need Agile Project Managers. I don’t think you can just do everything with Scrum Masters. I think there is a role for people such as Agile Project Managers.

You don’t know what you might want to be, and you might want to be one thing in this company, and one thing in another organization. You might want different kinds of resumes for different kinds of organizations. You can’t just say, “Write the resume to end all resumes.” You might want to have a focused resume for this kind of company and a focused resume for that kind of company.

You have to figure out what you want to do for this week [laughs] and what you want to do next week. And maybe based on the interviewing that you do, or the phone screens that you do, or even the talking to people that you do. That you want to experiment, this is the idea behind the Lean start‑up.

You do a little something, get a little feedback, and pivot. If you’ve used Personal Kanban, you can do this. The idea behind “Manage Your Job Search,” which I do think is the [laughs] main title of the book. Although the subtitle, no, no, no, we’re not going to keep the subtitle. But I’m going to keep the main title of the book.

That’s the book I’m working on in beta. I was so hung up on trying to say, “Should I publish? Should I get feedback? How do I get feedback? It’s on LeanPub.” I don’t have a developmental editor guiding me. And I finally said, “I know how I can do this. I can do a beta book”!

I have 53 people who are reading this book and using it. Some of them have given me feedback ‑ not all of them, of course ‑‑ which is what happens with a beta book. But a couple of them have given me feedback. The ones who have given me feedback say, “When they do this, when they actually use Kanban, it really works.” What a surprise.

Derek: What kind of response are you getting from people when you tell them that they might want to use a Agile practice like Kanban to do something like a job search? Do you get kind of crazy looks that you might use what people think of as a manufacturing process or a software development process as a way to look for your next career or your next path in your career?

Johanna: The technical people who already know about this say it’s a sort of dope‑slap on their heads, “Oh yeah! That’s a good idea.” And the non‑technical people…I’m working with a couple of people whose parents I know, and their kids are just graduating from college. Their kids ‑‑ they know me as Johanna, the friend of their parents.

They say, “What is this with the stickies? Why does Johanna want me to do this”? And I say, “Just trust me. Just try this.” They say, “You know, I’ve looked at your office, Johanna, and you have stickies all over the place.” And I say, “Yes. That’s because it works and I get all the stuff done.”

They say, “Why do I have to use stickies? I don’t know about this business.” I say, “Well, it’s pretty cheap as a way to organize your to‑dos.” And they say, “Well, OK.” Then they try it and say, “Well, this is a weird thing, but I’m getting stuff done.”

They don’t know that it’s from manufacturing because a lot of these people have BAs in Philosophy. I mean, they are liberal arts majors, who don’t know anything about manufacturing, and they are taught to be critical thinkers.

Derek: How are you incorporating some of the concepts from feedback?

I loved how you started off with, that it’s really a hypothesis, that you’re trying to prove that hypothesis. If I go in and say, “I really want this job,” and I look at the particular employer, I think that they’re really wanting to potentially hire for this.

Maybe I’m going to change my title a little bit to be more appealing, and I’m going to do these things. I get a call back, I go through the screening process, and ultimately I end up not getting the job. How are you trying to incorporate feedback back into that process?

Roy: Especially when a lot of employers have a very hard time with giving you honest criticism about why they didn’t hire you, or aren’t very timely at all about it. If you’re trying to improve on one‑week sprints, and it takes some three weeks to get back to you, how do you deal with that?

Johanna: A lot of it is if you’re looking for a job and have enough leads, which is a piece of the job‑finding puzzle. If you only have one lead, then you’re just holding on by your fingernails to that one lead. That’s one of the reasons you have to have really small tasks, and really small to‑dos so that you are not hanging on by your fingertips to that one thing.

You have to be looking for multiple jobs, at all times. That’s one of the things that I’m really hoping that people get from this book because if you’re only looking in one place, you’re not going to find a job. You have to be looking in multiple places.

I have a whole thing on how to use LinkedIn and how to use Twitter because you have to be expanding your network. I have a session at the AYE conference about how to be a social butterfly, for people who are not social butterflies.

I met Derek at, what was it, a Better Software Conference a number of years ago?

Derek: Yes. I think so. Do you sometimes say that you want to be more of a social butterfly? Johanna, are you encouraging people to potentially do some of this, well before they’re actually looking for a job?

Maybe, in a current career are there some practices that you can pull through that position you, should you decide to change careers or decide to change employers that maybe you’ve already done some of the groundwork, or is it something that really only applies when you’re in the thick of trying to find new work?

Johanna: I started writing this book, before I realized I was writing this book, when I was coaching a bunch of my management coachees…I do a lot of management and executive coaching. What I was realizing is, a lot of my manager colleagues had not been building their networks. I was coaching all these managers and some executives, who had a 150 people in their LinkedIn networks.

I said, “This is crazy. You, guys, need to expand your networks because how are you going to hire people”? I was looking at this from the hiring perspective.

When I was redoing the hiring book, I was saying to people, “Part of what you need to do ‑‑ especially if you’re hiring for an agile team ‑‑ is you need to be building your LinkedIn network so you can look at the people in your groups and look at the people that you have a relationship with so you have a shot of knowing who are the passive candidates.

If you don’t have a good personal network, how are you going to reach out to people who might be really good people for you to hire? And that’s assuming you don’t want to relocation and assuming you just want people who are good people.

I cannot tell you the number of people in my local network in the Boston area who every so often send me an email saying, “Do you know of a good project manager? Do you know of a good tester? Do you know of a good developer”? I have these serendipitous emails from someone who says, “I’m just starting to look around and if you know of anyone looking for somebody” and I happen to be able to put them together. Not because I’m trying recruiting as a second career because I don’t want to.

But got this email and then I get this other email and I can say, “I know this person, I haven’t worked with him or her and I know this manager I haven’t worked with him or her but based on my little relationship with both of you, I think you guys might have something in common.”

Derek: Yeah I see that a lot in the work that we’re doing with Gangplank, especially is that…you said serendipity and I think people do not take nearly enough advantage of serendipity. But one thing serendipity requires is that people signal. I heard you say two things, somebody signaled that they were looking for a particular type of person to hire and somebody else signaled that they were looking for a particular type of work.

Because both of those people were signaling, you were able to basically cross those signals and then probably put them into touch and maybe good things happen. Maybe good things didn’t but there was an opportunity to potentially have there and maybe something like Personal Kanban for looking for next job.

One of the things it does, it forces you to look at things at a granular level that allows you to signal in multiple ways which just increases the opportunity for good things to happen. So it’s just a really interesting approach.

The last question I really have is, one of the things that is difficult with any kind of process is discipline. When you’re in the self‑mode, I’m not on a team, an agile team, I can have other people help enable me to accountability but in a Personal Kanban or personal agile space of some kind, how are you coaching people to be disciplined in the work they are doing?

Johanna: I have people start and end their week on a Tuesday or a Wednesday, that’s the first thing. I don’t know if you’ve read “Manage It!” Or any of my project management stuff that says, “Don’t ever start or end a week on a Monday.”

I wrote an article a long time ago called “What’s Wrong with Wednesdays”? And in “Manage It!” I actually say unless there’s a really good reason, never start your week on a Monday and iteration on a Monday either. Because that just begs for people to slide into the weekend then you don’t really know when your iterations start.

I strongly suggest that people start their week on a Wednesday. I say to them, “You have to take time off. You absolutely not work on your job search at some point during the week. You have to take time off from it. And I don’t know which days you’re not going to work on your job search but some of those days you’re not going to. Because it’s a job like any other job. You cannot work on it seven days a week, that’s craziness.”

Then I have retrospective, I tell them to count up their tasks. I tell them to make sure that their to‑dos are small chunks. I explain that they should try and make their to‑dos a couple hours in duration. I explain that this is how I work actually. None of my to‑dos in my work are longer than a couple of hours. This is literally how I work.

I do a chunk of work in the morning, I do a couple of chunks in the afternoon. This is how I keep the ball rolling in my work. This is how I get books written, this is how I write articles. I explain all of that in this book because this is how I keep the flow of work going.

I explain that in the book and then I say that count up all the tasks you got done and it doesn’t matter how many you got done. It’s just a number. That’s how you can predict which you might be able to get done. And I say it’s just a number, it doesn’t matter what the number is.

For those of you who are…I don’t actually say the word anal, but for those of you who are worried that it’s not a normalized number, it’s not a normalized number, don’t worry about it, live with it and use that number to predict what you might be able to get done next week.

If you always have really small chunks it doesn’t matter but you’ll be able to do approximately this number next week. And then I walk them through three different kinds of retrospectives. I offer them three different kinds of retrospectives and tell them to mix it up.

Derek: You’re creating an independent one‑person agile team, that’s awesome. What…

[crosstalk]

Roy: …be beneficial in that type of case if you have somebody you can trust like a spouse or a good friend to help hold you accountable to that type of stuff. I know that, personally, I don’t have the willpower to keep myself to an iteration like that. I’d probably have to have some kind of external force holding me accountable. Is that something you’ve seen have good success or does it not really make a difference?

Johanna: I don’t know. I mean, this is what I do. Am I so weird that I’m the only one that does this? Maybe. When the book is actually out, I was going to offer some webinars based on the book and see what happens. Maybe I should offer webinars before the book is out of beta.

[crosstalk]

Derek: That sounds like the lean thing to do to me.

Johanna: Yeah. I’m having knee surgery this summer. Maybe that’s what I’ll do when I can’t travel. I actually thought for sure that people would maintain focus but you guys are giving me feedback, that maybe people are not able to maintain focus.

Maybe that’s a question I’ll ask in this version of the beta and maybe people will give me feedback that they’re having trouble maintaining their focus and see if they are or not. And maybe that’s something I’ll offer as another offering. Are you having trouble maintaining the focus of the Kanban?

Derek: Sounds great. I think we’re at the end of our time box. Is there anything that you want to promote or share with us before we head out?

Johanna: Go see if this is interesting for the book. I will have a new version of the hiring book with a lot more about cultural fit, also on Leanpub. Look for “Agile Program Management” at some point this summer. Probably also I will first release it in beta. That’s my next writing project.

Derek: You’re looking to do that on Leanpub as well?

Johanna: Also on Leanpub, yes.

Derek: All right, so it sounds like [inaudible 18:23] it on Leanpub. Lots of good stuff coming out. Thank you so much for your time and thank you for participating.

Johanna: Well thank you so much for asking. I really enjoyed it.

[music]

Announcer: Is there 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 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 at Gangplank Studios in Chandler, Arizona. For old episodes check out integrumtech.com, or subscribe on iTunes.

Would you like to chat about this topic a bit more? Check out the “Agile Weekly” Facebook fan page, where you can discuss this episode with the hosts and other listeners.

The post Episode #63 – Managing Your Job Search with Johanna Rothman appeared first on But Are They Working Hard?

How can you tell if a senior developers is acting in a way that befits their title?
Should we reward the hardest worker for working hardest?
What makes a senior developer better than other developers?
Should we ever care if the developers are working hard?

Transcript

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

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

Drew LeSueur: I’m Drew LeSueur.

Derek Neighbors: I’m Derek Neighbors.

Clayton: Today, we’re going to talk about an article that we found from Esther Derby. It’s titled, “But are they working hard?”

It’s a story about some managers in an organization that’s adopting Agile and they’re wondering to themselves, “OK, everything seems like it’s going well, but there’s this guy over here and he’s got that “senior” word in front of his title. He’s a senior developer. I’m wondering, is that guy really doing senior level work? His team is this cross‑functional thing. Everyone’s doing a bunch of stuff all together.”

How do I know that this guy is really pulling his weight?

Drew: Why do you care?

Clayton: As the host of the podcast, I’m not sure.

Roy: Maybe you care because you’re paying him a lot more than everyone else.

Drew: That’s a good example.

Clayton: Maybe I’m paying this guy more or he’s got more seniority or he’s my buddy and when special assignments come up, in the past, I’ve always picked him. But now, I’m just kind of wondering, is he kind of just goofing off now because he doesn’t really have to work as hard?

I don’t know.

Drew: Is that a legitimate concern of mine?

Roy: I think that’s true. I didn’t think about like that, but yeah, if this guy is not pulling his weight, then maybe you can cut his pay, right?

Derek: I think the other way we see this manifest is, you know, good people have to be pushed really hard. If I can’t tell if that individual is really working hard or not, how do I know to whip him harder?

In the old school management style, if somebody is not working, you whip them and you continue to whip them until they are performing to their “stretch goal”. But if you don’t know if the person is being stretched or not, how do you know to whip them?

Can a team only reach its maximum potential if every individual on the team is reaching their individual maximum potential and are putting in the maximum amount of effort?

Drew: I think, that’s what Management 1.0 believes.

Derek: How do measure effort, too? If you’re talking about laying bricks or shoveling something, yeah, sure you can be maxed out and shovel as fast as your physical body can shovel.

But if you’re on something that’s creative like software or something else, how do you physically think harder or think faster? How do you judge that even?

Drew: I think it goes back to the “work smarter not harder”.

Derek: Right.

Drew: So if you go to your snow shovel example, if I give you a tablespoon and I go ask you to shovel snow and you are putting every ounce of your body into it and working so hard that there is no question that you are ready to be on the brink of death you are shoveling snow so hard.

Then I turn around and give you a two foot by one foot snow shovel and you are working half as hard but you’re getting twice as much snow shoveled, should I be pissed that you are not working hard enough?

Derek: Let’s say, I am on a senior development product team and I see that this team is not going to hit their commitment. Let’s say, it’s a longer term commitment. They’re missing their release.

I could see that in an organization, especially one that even has the concept of senior developers like me, right?

Roy: You’re not that old.

Derek: Well, I am a senior developer.

Drew: Do you get the discount at Denny’s?

Derek: Yeah, the over 65’s discount? I think, I might still qualify for the student discount. I could see what I would so as a senior developer is not help my team out.

Let them fail so it look’s like shit is going to hit the fan and I am not helping them. I knew from the beginning that they weren’t going to make it without my help.

Then what I do, is at the last moment, when it looks like all is lost, I work my ass off for two days straight. I just kick ass and, now, I’m the star. I mean, that’s how I got the senior title in the first place.

Why wouldn’t I keep doing that?

Clayton: I was going to ask, what is it about the senior developer that makes them the senior developer? I think, in this example in the article, a lot of it comes down to you have been there longer or, maybe, you have exhibited some hero coding specialties where you burned the midnight oil a few times. Then, all of a sudden, you are loved by the manager.

What is it really? I think that’s the question. Why is this person the senior developer and how do I really know that they are the senior developer, especially if they’re working in this environment where everyone is supposed to be equal?

Derek: I think this is kind of a mind set shift that management has not gone through. Today, the mindset is the person that works the hardest is the leader, right?

If you come in early and you stay late, you write more code and you’re more knowledgeable about the code, then, clearly, you are the code leader. You’re the senior developer.

That becomes what they look for, so who is going to burn the most midnight oil for me? When that person steps up they will become the leader. I think that on Agile teams, specifically, or self organizing teams, it really is all about continuous learning. It’s about learning how to adapt to situations and learning new things.

I think, the concept of leadership fundamentally changes. It’s not the person who works the hardest. It’s the person who gets the most out of the people or makes the people around them the best.

That’s who the real leader is on an Agile team, it’s the person that people say, “This person makes me better at what I do.”

Drew: Is it really the person who works the hardest or is it perhaps the person who sacrifices the most because I think we’ve seen even internally where we have issues with team members that have a martyr complex and they seem to rise to the position of leader because they earn respect through sacrifice.

Derek: I definitely think, that’s just a form of working harder, right?

Drew: Sure.

Derek: I think, when you say, “Woe is me. Look at what I had to give up to get this.” That largely becomes a, “Wow, you know that person’s really taken one for the team. They’re really working out,” you know what I mean?

I don’t want to say those are interchangeable pieces, but yeah, I definitely would say that sacrifice, commitment, working hard, you name it, like all of the kind of Management 1.0 or 2.0 concepts.

“I don’t have to crack the whip hard on that guy. I know he’s going to work hard. I know he’s going to sacrifice for me.”

Roy: Some of the things that were mentioned in the article, that senior level things “are like pairing and mentoring”, code kata, examining the team’s practices, looking for ways to improve, those are all things I think that speak to Derek’s point of helping the people that are around you improve.

I think, the real sticky situation that comes up a lot especially in an organization that’s transforming itself, from an HR perspective, if you have people on the payroll or that they’re in this position in the pecking order as a senior person, but these attributes aren’t things that only they can do.

They might be doing something like this in some aspect of the team for some period of time and then someone else might get jazzed up about it and they start doing it. You have this floating role in leadership position where everybody can be some leader in some aspect and now that senior thing kind of disappears, right?

Derek: Right, I think you start to have senior people with different things. It kind of becomes who’s initiating that particular thing and that person might rise to the leader of the team or the senior person on the team for that particular type of thing.

Whether it’d be a technology or whether it be a process or whether it’d be whatever, the teams start to say like, “So‑and‑so is kind of our go to person. They’re the champion for whatever that is.”

They’re the database champion or they’re the Java script champion or they’re the Agile champion or they’re the Kanban champion or they’re the training or teacher champion.

Drew: What if the entire team is kind of slacking off?

I remember we were reading about the article and briefly talking about it. It mentions the concept of something called social loafing. I think, Derek, your eyes lit up when that was mentioned. I’m not really familiar with it. Can you explain what it is?

Derek: I’m not too familiar with it. I talked about it a bit this last week with a number of other coaches. I think, the term goes something to the fact of this concept of when you get in groups, people start to defer responsibility and it becomes somebody else will pick up that slack.

There’s this loafing around concept the more social something gets. I think, there were some studies done by some people doing a tug‑of‑war type of thing that if you measured people’s exertion of force when it’s one person’s tug of war against another person, they give a much higher effort than when it’s 10 people tugging war against 10 other people.

I think, there’s some kind of concepts out there around. Can that be contagious as well, where you start to see one person kind of loafing? Does that start to get contagious within a group? I think, that this is something that managers fear.

Drew: Is it something that we can prevent? It seems to me like if we are being accountable to our effort and somehow broadcasting that to our team members, we can hold each other accountable.

Is that something we even want to do or is maybe that measuring something we want to do not that we ensure that everybody is spending maximum effort? But if we notice that everybody is spending maximum effort, it means we’re doing something wrong and we need to change the way that we’re doing something.

Derek: Yeah. I think maybe the way that I look at it is if you’re looking at the tug of war sample, maybe I’m not pulling my absolute hardest, but if my team starts to lose, I do pull harder. If you’re setting clear vision for people and you’re putting goals out there for them to hit, can you put motivations out there?

I’m not talking about more money, more whatever. But can you put some intrinsic motivations out there that get them to want to pull harder because you’re challenging them? I think that, to me, human beings have an innate desire to learn and grow.

I think, sometimes people get a beat out of them or they got out of touch with it. But I think ultimately, if you’re challenging people to go deeper and harder than they’re used to, they tend to engage more.

When I’ve sees social loafing, it’s usually when the team or the organization is not providing much of a challenge for somebody. They go like, “Well, I don’t have to pull that hard because we’re OK,” with regards to the power of the pull.

Drew: I don’t know if this is where the metaphor is breaking down, but it seems to me like, if the goal is to win in tug of war, then it sounds to me that the minimum amount of effort required in order to win is the best strategy and the most sustainable strategy for a team to take. Is that true in all cases?

Derek: I think that sounds fairly true to me.

Clayton: One of the examples that she mentions in the article, the question she asked is, “Let’s say, we’ve got a few teams, and we’ve got them formed. They got a foundation. They start going. They’re producing software, delivering results, and things are going well. As a manager, do you care if they’re giving a hundred percent of the work all the time?”

I think that’s the core question. Are they working hard? Is that even a valid question? Should I even be worrying about that if they’re still producing results? Am I just measuring the results? Am I only measuring effort?

Then you get back to that concept that Derek has mentioned of, “Do I get mad at Drew for exerting less physical effort to shovel that snow because he’s got a better tool for the job?” Am I supposed to be mad at him about that? But if he’s delivering results, I don’t care if he’s working half as hard because it’s still working, right?

Derek: You’re right. I think, that teams should get to the point where they’re only exerting as much effort as it takes to basically pull past the goal. But the second thing, I would clarify, is that if you win, you should constantly be looking for better competition.

If I’m playing tug‑of‑war and if everybody on the team only has to give 10 percent to beat an opponent, we should be looking for a tougher opponent next time, until we get to the point where we are having to put more and more effort into making that victory.

If we get to the challenge where we can’t win, then we need to start looking at, “What do we need to do? Do we need to go lift some weights so that we don’t have to pull as hard to win the next time?” I think that that’s, to me, the whole concept of a healthy team.

Challenge yourself just enough that you’re in a sustainable effort level because I think a hundred percent effort all the time is not sustainable, so whatever that level is. It’s probably different for everybody on the team.

Get them to that point. See what victories you can have. Then challenge yourself, “What do we need to do independently and as a team to grow so that we can go against harder and harder competition while still being sustainable?”

Drew: It is still a smell if the team is exerting almost no effort and not because you aren’t getting any results you want, but because it might be reasonable to be concerned that your team is going to lose motivation if they continue to have to put almost no effort into their job on a daily basis.

Derek: Absolutely.

Clayton: I guess as a manager, if I am committed to the idea that I don’t really care if my team’s working hard so much as I hope they’re delivering results and improving, like you’re mentioning Derek, should I be responsible for trying to find or uncover ways that they could be improving? Or should I just focus on enabling them and giving them some culture or some guidelines for that kind of continuous improvement mentality?

Roy: The same as inside the team, I think, as I mentioned in this bullet points, the leader or the senior person, as Derek said, is the person who is going to spread his knowledge or empower or enable the rest of the people on the team. I think, maybe, somebody outside looking in can do the same thing.

They’re a senior, or whatever, for whatever reason. Hopefully, it’s because of one of the bullet points on this list. How can they use their mentoring skills, or their coaching skills, or whatever skills they have, to empower the team to be better? Because we can all be better. You just have to balance that sustainability versus effort.

Drew: So do you need to be a senior developer in order to practice the things on this list?

Roy: I don’t think so. A senior developer, no.

Drew: Do we even have a need for senior developers or that title?

Derek: Probably not. Maybe hitting your question a little too, Clayton, I think, that it is valid for leadership or managers to understand how hard a team is challenging themselves. Not necessarily working hard, but are they going up against tough opponents or not?

I think, if they’re going up against opponents that are complete softballs, I think, that it’s OK for management to say, “I think, we should be trying to solve harder problems, or basically push harder.” But that’s not necessarily work harder. The team needs a tougher challenge.

In the same way that, I think, if they’re being over challenged, the management needs to be able to pull back and say, “Hey, we need some potentially easier opponents to go against.”

To me, the difference is you’re measuring or you’re looking at the team not the individual, and let the team decide what to do with the individuals. If it’s, “Hey, this is too hard,” let the team figure out who needs to improve on the team and how they’re going to improve.

Don’t dictate that to them. Don’t say, “Well, if Roy would just work harder, then we would be able to beat this guy.”

Clayton: One last question, I’ll ask around, and you can give me a yes or no answer. If you were on an Agile team as a senior developer, do you think it would be meaningful for the progress and improvement of the team for you to publicly rescind or give up your senior developer title?

Roy: That sounds cool.

Drew: Yes, without being a martyr.

Clayton: OK.

Derek: It doesn’t really matter.

Clayton: I’m no longer a senior developer. I’m a developer committed to the team.

Derek: I don’t think that matters.

Roy: I feel your pain.

Clayton: Just symbolic, OK. Derek?

Derek: In principle, I absolutely love it. I actually saw a team the other day where somebody pretty much did that and said, “We’re all developers here. There is no better or no worse.” Because somebody was talking about a better developer or worse developer, and their response was pretty much like, “We’re all developers here. There’s not better and worse.”

This was somebody who’s seen as the senior person. But I don’t know if that necessarily change things either. While, I think, it’s noble and the right thing to do, I’m not sure that it necessarily helps.

Drew: Do I lose my paycheck when I give up? Because I want to keep that.

Clayton: All right. If you are a senior developer and you would like to come yell at us, we invite you to the Agile Weekly Facebook fan page at facebook.com/agileweekly. You can give us an earful about why we’re wrong about your senior developer title. Or if you’d like to just join the conversation in any other aspect, we’d love to have you, too. Thanks!

[music]

Announcer 1: If there’s something you’d like to hear in the future episode, head over to integramtech.com/podcast where you can suggest a topic or a guest.

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

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

The post Episode #62 – But are they Working Hard? appeared first on Don’t just change the process if people aren’t following the existing one.

Is the process really the issue?
Process only highlights culture problems, it doesn’t solve them
How do you know when it really is time to change the process?
A short feedback cycle is important to evaluate the problems that are being highlighted.

Transcript

Drew LeSueur: Hi. Welcome to another episode of the Agile Weekly Podcast. I’m Drew LeSueur.

Derek Neighbors: I’m Derek Neighbors.

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

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

Drew: Today we’re going to be talking about an article by Jamie Flinchbaugh titled “Don’t just change the process if people aren’t following the existing one.” The article talks about how people focus on the process and following it to the tee, as opposed to questioning whether that’s a correct process. What are you guys’ thoughts?

Roy: I don’t know. It sounds like it could be very easy to abuse. It sounds like an invitation for scrumbutts, or any other process butts, “Well, it’s a problem with the process.” I guess this is, actually, saying don’t change the process. Actually, I like that. I guess maybe it’s not a scrum‑but right. It’s saying, just because it doesn’t work for you, maybe it’s not the processes fault. I completely turned around right there. [laughs]

Derek: What I see a lot of times are people get so hung up on their process as the problem. I think what he might be saying is, if you’ve got a process, and people aren’t following it well, what makes you think they’re going to follow some new process? Even if they are following the process, is how do you know the process is really the problem? Meaning, if you’ve got deep culture issues, or you’ve got leadership problems, or you’ve got visioning problems, process does not solve those.

All process does, especially if you’re talking Scrum or Agile, Kanban, all it does is highlight problems. It doesn’t actually solve them. If you just say, “Here’s process A,” and we run through it, and it highlights all these problems, and we go, “Hmm, yeah, let’s not do anything about these problems, let’s just switch to another process, and maybe if we have to have that process those problems won’t exist.” Then that process highlights the same exact problems, at some point you have to deal with the problems.

Drew: Derek, how often have you found that it actually is the process that is the problem within a company? Has that ever happened to you? Or is that something that happens generally speaking and this is an exception where it is?

Derek: I’ve never seen the process be a solution. I have seen a lack of process, or no process, make it so that a company or a team does not know what the problem is. I think sometimes you have to jump into a process to help highlight what the problems are. But, ultimately, the process never solves the problems, it just highlights them.

If you’ve already got a process that’s highlighted a bunch of the problems for you, I wouldn’t advocate going and switching to another process. I would deal with the problems that your current process is highlighting. If you have no clue what problems you need to tackle, then maybe you need some process to help highlight the problems for you.

Clayton: Yeah, I think that one example that comes to mind is you might find a team that is doing Scrum, and they never have enough time for planning. Like, every time they say, “Scrum, the process says we have to do this thing called a planning meeting,” and it has these certain things we have to do, and there’s this artifact or whatever that falls out of it. But we just can’t just do it.

Either the work we’re doing is too complex and we don’t have the time to break down all the work that we’re doing in this planning meeting, or there’s just not that much time in a day. They told us we have to do this two week sprint thing, so we can’t spend two days. That’s too big of a percentage of our Sprint just doing planning and thing that’s one of those situations that Derek’s getting into is, “OK, well, maybe there is a problem. Why does it take so long to plan?” Or maybe that’s not even a problem. Maybe that’s OK. But I think that’s the kind of thing that people will dive in and say. “This process is broken, it doesn’t work!”

Roy: Does that mean that maybe processes like Scrum, and like some of the other ones out there are really just a way to normalize your team, so that you can talk in the same language as all the other teams? For example, having the issue of not being able to spend the time for planning, you might be able to go to another team that is practicing Scrum, and say, “Hey, we’re having this problem, and because you guys are using the same terminology, and you are trying to implement the same process, maybe all it is, is a framework to make it easier to communicate your problems to other teams, so that they are able to help you out.”

Clayton: Yeah, that probably would make it easier, but I don’t think that’s really the goal so much as the teams have probably going to all have some different kinds of problems. They are all going to be exposed in some different way. I think it’s kind of, you get to that fork in the road, where either you decide to, “OK, well, here’s this problem we have. We’re going to resolve it somehow.”

I think what the gist of article is, “We have this process problem. It must mean that we’re not doing something about the process right so let’s stop doing this and find a new process.” That’s the real issue. A lot of times, the stuff that something like Scrum or any agile methodology will uncover are difficult things that you would rather not have to solve. It’s a lot easier to blame it on the process, do some new thing, “Here, look, look, a pony.” You get some new thing in there, and you can kind of start the cycle over again.

Drew: We have some processes out there that I feel like most of us consider negative processes. I think, in most circumstances, for example, waterfall is pretty much frowned upon in the agile community. There probably is a time and a place for it, but how do you make that determination?

I suggest if the entire agile community shuns it, then we can’t consider it a valid process. It might be the process that is a problem. How do we know that it is my process that is a problem, or how do I know it is my team that is a problem? Do you know what I mean?

Derek: I think a process lets you know what challenges you face within a team or an organization. I think the reason that waterfall has been universally shunned over or shown to be not so effective is it’s feedback cycle is way too short. It does have the ability to tell you that things are wrong, and to deal with them. However, the time frames that that are in are generally in months or years as opposed to days or weeks.

I think when I look at why most agile processes do fairly well is because they’re very iterative, which means they’ve got much, much smaller feedback loops. I would almost argue that a lot of teams I see doing scrum are really doing mini‑waterfall.

Their teams are still very siloed. They’re doing two or four‑week sprints. In whole, they have iteration zero, and they have a hardening sprint. They have all these smells, but they are getting feedback in a much tighter loop than if they said, “Hey, we’re going to do this 12‑month project, and we’re not really going to do a postmortem until month 12.”

Clayton: Just to clarify, I think you meant to say that they have a longer feedback cycle?

Derek: Yes, longer feedback cycle. I’m sorry.

Drew: When people have resistance to part of the process ‑‑ like, “Oh, we can’t spend all this time planning” or “This standup is just getting in our way. Why don’t I just get my work done?” ‑‑ part of a lot of agile processes are ceremonies that may be uncomfortable for people who are trying them to start.

What are ways you guys think to overcome those type of awkwardness of starting a new ceremony that, by their culture, they’ve never done before?

Roy: I think a lot of it is providing value in those ceremonies. I see way too many organizations institute a standup or a planning meeting. They are pretty much dog and pony shows in the sense of, they are there only because some scrum book or some scrum master or some coach told the team they need to do that, but the teams get no inherent value out of them.

I think the key is getting the information out in the ceremony, dealing with it, reflecting on it, and improving the ceremony every time. Otherwise, what’s the point? There’s been several times I’ve told teams, “Why do you even bother having a stand up, because what you’re doing is not valuable to yourselves or anyone around you?”

Clayton: Going back to the article about, “Don’t just change the process,” when do you guys think it’s OK to change a process? How far does it matter to team maturity?

Or if you get to try it for a certain period of time, how would you know now is the right time to change things and do something different even just as an experiment? How would you know how far to go with that? If you keep that for a longer period of time, is it OK to change process? How would you know that?

Drew: One example that I have ‑‑ it’s just maybe a change of not necessarily a process but a practice ‑‑ is we were trying to get our stories smaller. We had a problem of having stories that were too big. I remember during planning once, we argued forever or discussed for a long time, “Should the stories be broken up or not?” At that point, we decided, “OK. Let’s just put it into this sprint. Let’s not talk about it more. We can move on and figure out if it was too big or not.”

But I think sometimes, because of a time constraint, you can just move on, and, maybe, just skip some of those things that, maybe, you know you should do, but as a team, you don’t have consensus.

Derek: I think it’s all about data. I would ask, “Why did the team think they needed to break the story down to a smaller story?” What behavior or what symptom or what data made you think, “Hey, we should potentially break this down”?

Drew: In that experience, I think it was more of just people saying, “Hey, we should break this story” or people saying, “Big stories are bad, and smaller stories are good.” That was all the data that we were going off of.

Later on, we actually learned that ourselves when we learn that, “Hey, it’s getting near the end of the sprint, and we have no story signed off. How can we fix that problem?”

Derek: To me, it’s all about data. If you say, “Hey the problem is the data that’s coming up is that we’re not getting stories into pending until the end of the sprint, we should change something.” Once you change something, you should then be able to measure, “Once we did that change did the problem of not getting stories into pending until the end of the sprint go away?”

If the answer’s yes, then that was probably a good process change, or a potentially good process change. If the answer’s no, then you say, “Hey, that’s not had anything to do with it, let’s either go back to what we were doing before or let’s find what the real problem is.”

Roy: It sounds like in that type of situation you’d want to be very careful to make only one change so that you know which change caused your measurable effect. Doing a process swap, like you had asked when is it appropriate. It sounds like doing a whole process swap is very difficult, because sure you can measure whether or not there was a successful change, but you don’t know which aspects of your new process made that change.

Chances are, if it did improve, then your ideal process as a team lies somewhere between the old process and the new process. In some cases, not all cases, obviously.

I kind of feel like instead of approaching a new process, what I would do is try to get the existing process working, so that you know that you are following all of the ceremonies. Deal with those problems that arise. If you still are noticing problems within the organization, or within the team, I would start pulling in one aspect at a time of the other process and trying them out. Trying to see if, just swap it in place, and see if that works for your team or not. I can’t really think of too many cases in which different best practices from multiple processes are mutually exclusive.

Clayton: I was going to say, what if the different aspects that you might be pulling in are conflicting?

Roy: Since you’re only pulling in one aspect my assumption, and it could be a wrong assumption, is that it should really only affect one aspect of your existing process. I still feel like that’s a one change that you’re making.

Derek: Maybe the way I would say it is if your current process is not highlighting problems for you, by all means, change your process. If your current process is highlighting problems for you, until you’ve dealt with those problems, changing your process will not help you.

Roy: If you think you kick ass, you’re using the wrong process and you need to switch immediately.

Derek: Maybe.

Roy: I wasn’t being totally facetious. Let’s face it, no team is perfect. Everybody needs some proof. If your process is telling you that you are perfect, something’s wrong.

Clayton: Yeah, I guess that’s a matter of does your process support something like continuous improvement, and those kind of things, right?

Derek: Correct.

Clayton: I guess I have one last question. If I’m in a situation where maybe I’m part of a team, and all of a sudden some ‑‑ let’s say scrum ‑‑ scrum‑thing gets dumped on me, and I’m told now you do this process.

We used to do this thing over here, that’s the old and busted, now we’re going to do the new hotness. Do it. Is that kind of culture, and that kind of thing even conducive to having that process be successful in the first place, or is that the kind of culture where people are going to blame the process for problems?

Roy: That’s a good point. When something like that is mandated from on high it makes it very difficult. I think we’ve had some good arguments in the past about the power of self‑organizing teams, and I think if you start organizing the team for them, it’s going to be difficult to get buy‑in.

Derek: I mean, I think it’s the difference between self‑direction and self‑organization. I think that you can still have a large amount of self‑organization and be put in a container. You could be put on a team and say, “Hey you have to ship product x.” Technically, that’s not self‑direction, but you can be pretty self‑organizing within that.

I would say that, if you’ve got leadership, or you’ve got somebody who understands self‑organization, who really wants the team to quickly adopt, or quickly accelerate through a new process that is highly self‑organizing, I think you’d probably want to go through some form of a process, where you start to talk about the old process, or lack of a process, and say, “Hey, doesn’t it bother anybody else that we can’t do A, or we can’t do B, or that this is a problem, like our quality sucks, or we don’t have predictability,” or these kind of things.

Start with isn’t this a problem. If the team starts to identify it’s a problem, then you can kind of say, “Well, what if we use this thing,” whatever the process is to try to help solve some of those problems. Then, now it’s kind of the team is kind of pulling it along. It’s not you will use this. It’s rather, “Hey, here are the problems we’re trying to solve. Does anybody know how to solve them?” I’ve heard these particular processes might be good for it. Now you’re kind of letting them be part of that process of choosing the process.

Roy: The best part is they might actually have better ideas than ones you’re already aware of to deal with some of those issues. They may be able to point out that what you think are the issues are not the real issues.

Drew: They can adopt the changes, as you talked about, Derek, if they show the problems or if they share with the problems, then they can choose some change that they can make to solve those problems, and make it more of a gradual thing.

Roy: It’s their victory if they succeed.

Derek: I think it falls in line with, if we’re talking at least scrum. It falls in line with you can tell the team this is the story that needs to be done, but you’re not telling them how to implement that story. In the same way, you can say, these are the problems I need as a product owner, or these are the problems I need as a CEO, but you’re not telling them this is the process you have to use to give me that information or to fix those problems.

Drew: Thank you. That concludes our episode. We’d love for you guys to join the conversation at facebook.com/agileweekly. Thanks a lot.

Clayton: Thank you.

Derek: Bye‑bye.

[music]

Announcer: Is there something you’d like to hear in a future episode? Head over to integrum.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, 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 Integrum Technologies, and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com or subscribe on iTunes.

The post Episode #61 – Is the Process the Problem? appeared first on Deb Spicer discuss 10 Destructive Behaviors That Can Bring Down a Team’s Success:

10 behaviors observed over 25 years
Deb’s book, Power Teams VIP
Why is lip service so prevalent?
How can a manager keep good team members while helping everyone improve?
Dealing with culture and millennials
What’s the worst behavior for the team?
How to improve bad behaviors
Are some people just not right for the team?

Transcript

Clayton: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Roy: I’m Roy van de Water.

Clayton: Joining us today, we have Deb Spicer. You can say hi, Deb.

Deb: Hi. How are you?

Clayton: Good. We actually found an article you had written. The title is “10 Destructive Behaviors That Can Bring Down a Team’s Success” and that’s we wanted to talk to you about. A lot of the work that we do involves working with teams and taking teams from maybe being some dysfunctional team and trying to get them toward high performing and those things. We were really interested in that topic.

First off, I was just curious. Where was it you came up with this list of 10 ideas? Is that something you’ve observed or a list you’ve compiled with people in the industry? Where’d you come up with that?

Deb: Actually, I came up with it after 25 years of working in global matrix teams or organizations and it is part of the book that I wrote, “Power Teams.” We can talk about that later, but actually I wrote the whole book about high‑performing teams, what makes them high performing and also when you do have destructive behaviors, how do you deal with that.

Clayton: We’re look at a few of the behaviors that were identified on that list and we had some questions about some of those.

The first one that jumped out at us was the one about lip service. We feel like whenever we identify this where there’s somebody that is in the organization that’s like this, it seems like everybody know that that person is full of it but nobody seems to say anything about it. Why do you think that is?

Deb: It’s very common. There are a couple of reasons that people behave that way. One is in all these behaviors, people behave the way that they do because leading to this point, it has worked for them in some form or another. When you have someone that promises everything but doesn’t really deliver on that, then it’s likely that that person has gotten away without being accountable for the things that they claim.

By instilling some accountability for that person by breaking it down, holding their feet to the fire, that helps change that behavior and it just shows them, “hey, it’s a new day and you can say whatever you want but the rewards will come from the delivery, not from the words.”

Clayton: Another thing we were wondering about is…we’re trying, whenever we have guests on the show, to take a viewpoint of maybe one of the listeners…so, if I’m a manager listening to this podcast and I think, “OK. I’ve identified these 10 behaviors, and I understand they’re wrong.

If I want to make my team better and promote the good things, how do I keep my team intact, because if people get better, aren’t they just going to leave and get a better job, or something”?

Deb: That’s a great question. In fact, when teams come together and achieve for something being themselves, they tend to stay, because that is a reward that is so rarely seen in organizations. It’s like when you get in the trenches with a group of people, but yet you achieve, you come out, you succeed, and you’re rewarded. Those teams tend to be the ones that stay together in a very tight cluster, move on, and take on even bigger challenges and bigger jobs together.

They’ve gelled, they trust each other, they know how to deal with conflict, they feel safe to just push back on each other, and challenge each other’s ideas. Always on the other side of that, something bigger and better comes out of it, so, in fact, organizations don’t have to worry.

The organizations that promote that kind of team cohesiveness, with many different teams in the organizations, are the ones who have the most innovation, are the strongest, and tend to be the leaders in the forefront of whatever dynamic is happening in the marketplace.

Clayton: One thing that you’ve mentioned also is the idea about the old culture. There’re some people who maybe have been there for a long time and have a way of doing things. Something that we’ve been seeing a lot…it looks like a lot of chatter is, especially in the software industry where you have people that are the new Millennial Generation. These 20‑somethings maybe out of college…

Roy: I guess me.

Clayton: Yes. That might describe Roy, actually.

How do you integrate that? They got these old culture people that have a certain way of doing things, and then you got these Millennials. Would you have any insight on treating this kind of generational gap?

Deb: I can, and in fact that chapter in my book talks about a computer company that was number two in the marketplace. Overtime, the focus was on one of the divisions in the company that was not performing, and that was to the detriment of what were the high‑performing divisions.

There was enough complacency to go around that really brought the company down and it slipped down to number three. Important in dealing with this is to just shake that culture up. How do you do that?

First of all, as the leader, what you do is you start setting very tight timelines on deliverables. You start speeding things up. You start the focus on what those measurable outcomes are going to be.

You add things like higher level team reports so that those people that are complacent on a team, psychologically they know they better step up or they risk looking bad in front of the higher management folks. You keep the pressure, you set the deliverables, you set the timelines short, you know, “By Thursday this is what is due.”

You hold people’s feet to the fire and what you see happening then is it’s not the leader holding people accountable, it’s the rest of the team that starts holding them accountable. That style supports the new millennial styles of work that haven’t been built in to some of the older cultures. Then the pressure starts coming from within the team and not just a top‑down kind of pressure.

Clayton: Just to clarify, you’re suggesting applying these pressures to the entire team, right? Not to individuals or is it…

Deb: Correct.

Clayton: …or is it doing it to the individual?

Deb: No. In fact, that’s a good point because whenever we talk about these behaviors, that is what we’re talking about. The people themselves are not bad people, it’s just that they have gotten used to using behaviors that don’t necessarily fit with the kind of culture organizations need today when those organizations want to succeed.

We address the behavior by putting things in place that will shake it up. That’s a particular one, you haven’t mentioned the piranha factor, but that’s actually one of the hardest ones to deal with for this reason. It doesn’t matter as a leader how charismatic you are, it doesn’t matter how great of a negotiator you are or a communicator. This behavior is very difficult.

Just close your eyes for a minute and think about this scene. You’re in Brazil, you’re on a bridge looking over the river down into the water, and you take a piece of raw meat and you throw it down into the water. What happens?

All of a sudden, you see backs of fish. It starts looking like a washing machine is just churning up the water and you see tails and fins and pieces of scales and stuff floating in the water. What that is, it’s the piranhas. They’re coming after that raw piece of meat.

In the piranha mentality, it doesn’t matter…what people don’t understand is they are eating each other to get to that prize. It doesn’t matter who’s in the way. They just go after them and they’ll take them out to get the prize. Picture that in a team setting. The same destructive things happen. The piranha personality can leave a whole team in shreds. It doesn’t matter who they take out because for whatever their motivation or agenda is, they’re going to take out anybody who gets in their way.

That’s an important one that if you inherit that person who has that personality or if you’re taking over a new team and you see that coercive, manipulative, sabotaging, demeaning kind of personality, what you have is a piranha, what I call the piranha factor. One of the most difficult and destructive team behaviors is that and it’s manifested by deliberate manipulation, deliberate coercion.

They will sabotage individuals and the team as a whole for whatever their personal gain is. That behavior of all of them needs to be dealt with immediately and it needs to be dealt with very firmly.

How do you do that? One of the ways is that, while you’re in the team setting, you still handle everyone very professionally, because the other team leaders, who are very aware, just like the ingrained old culture, everybody sees it. Everybody knows.

But it’s your leadership that’s important in this scenario, to not that person out, if you will, in front of everyone. It’s you address it professionally, firmly…

Deb: Then what you do is, besides talking to that particular person outside of that team setting, what you want to do is find a way to remove them from their comfort zone.

What that means is, and what I’ve used in the past is, I then moved the entire team outside of the role that they bring to that team. IT, example, if you’re an IT programmer, then I might move you to the finance role, so you have to put on the thinking cap as if you were the finance person for that organization. If you’re a quality assurance person on the IT team, I might move you to the market role.

As the piranha is the director of IT programming, like I said, I wouldn’t move that person to a finance role. Everybody figuratively moves outside of their own comfort zone, so what you get is the information, experience, enthusiasm that people bring to their regular job, plus you’re making them stretch themselves into what if I were the finance person, how would I deal with this team challenge or this team initiative that we need to solve.

Roy: I guess the moving people around works but what if you have somebody on your team that is irredeemable, or he doesn’t seem to be willing to take on any of the positive traits that your team requires, and they just keep exhibiting his negative ones? Do you find that that even happens? Is nobody irredeemable? Or, if somebody is irredeemable, how do you deal with that?

Deb: The easy way is to [laughs] remove them from the team, if you can. In my circumstance, that I write about in the book, it was people higher up than me required that this person stay on, because they found that person brought something in a niche way that was important.

Because this initiative was at such a high level, and the outcome of this initiative was so critical to changing some of the direction for the company, the other team members, who were also decision makers, actually took on the role policing this person, and it didn’t have to be me to get them in the right vein. They did it themselves.

But there are some people who, no matter what, will make sure that they don’t have any personal loyalty that they will not allow the team to collaborate, they’ll keep blinders on, they’ll stay single‑focused, and, at the end of the day, they have to be removed, or else it destroys your entire team.

Roy: One last question for you here. Let’s say that I’m just a member of the team, and I come across this article, or maybe I listen to this podcast, and I’m witnessing some of these behaviors on my team.

What can I do? What to do for a step for me? Maybe I’m not ready to stick my neck out and make a big deal out of it, but I want to make some change.

Deb: Very good question. The most important thing that you can do is be an example. You heard of the 80/20 role in business and in sales. There’s a different role. It’s called the 10/80/10 role.

What happens is 10 percent of any team, of an organization, of a homeowners association, whatever dynamic that you have, 10 percent of the people will be wonderful cheerleaders, they’ll buy in immediately, they’ll rah‑rah, they’ll be supportive.

On the opposite end of the spectrum, you have 10 percent, no matter what, that will serve their destructive behaviors. They’re against things because that’s just who they are. If everybody else wants it, they don’t want it. Then there’s this 80 percent in the middle, we call them the mushy middle.

This is in politics, this is in lobbying, in can be in churches. 80 percent of the people are the followers. They’re going to look, they’re going to watch, they’re going to observe, and then, eventually, they’re going to choose aside the 10 percent positive, the 10 percent negative.

You, as a person who wants to see the success of this, modeling successful behavior will start to bring more and more of that 80 percent over to that dynamic. You’ll see more and more people come to that. What, ultimately, does that do? It marginalizes and makes the 10 percent who are negative very insignificant.

Even as a younger manager, new in your growth professionally, you can still model the behaviors as if you’re at a higher level, and you’ll find that more and more of the mushy middle will start to also model those behaviors, again making the negative, stubborn, procrastinating type of people, or the outright saboteurs, be very insignificant, because they won’t be able to sway the team.

Clayton: It’s a good answer. I’m a big fan of modeling good behavior, so that’s a great way to think about it. We’re about out of time here, but you’ve mentioned a book. I was curious if there is anything else relating to the book or anything like that you’d like to share with the listeners.

Deb: Sure. Actually, the book is called “Power Teams: The New SQUARE ROOT MODEL That Changes Everything!” It’s on Amazon, by Deb Spicer. If you’d like to look up on my website, it’s quantumlevelsuccess.com. Also, I do have some additional materials. I have a quick reference guide that goes with the book that I give for free. I have some chapters that are available for free.

If you have any questions that are bothering you with any of your team members, and you’d just like to drop me a line, I’m very happy. I talk through ID as an issues with people all the time. It’s no charge. I really enjoy hearing the good and successful team stories as well as the challenges, and I think talking through those makes us all stronger, so I encourage you. It’s [email protected]. Please reach out. I’d love to hear from you.

Clayton: Great. That sounds great. We really appreciate you taking the time to speak with us today, and we loved having you.

Deb: Thank you, and thank you for inviting me, to your success, to your team success. I wish you the best. Take care.

Clayton: Thanks.

[music]

Clayton: If there’s something you’d like to hear in a future episode, get 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 agileweekly.com. It’s the best agile content delivered weekly for free!

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

The post Episode #60 – 10 Destructive Team Behaviors with Deb Spicer appeared first on Episode #59 – Running a Transparent Consultancy with Chris Sims appeared first on Episode #58 – Personal Kanban with Gerry Kirk appeared first on Episode #57 – Performance Reviews with Kane Mar appeared first on Episode #56 – Strengths with Scott Dunn appeared first on David Bland discuss Lean Startup principles in Agile:

Lots of companies dealing with unknowns
Product teams
Release early, release often
Validate, Experiment, Iterate
Culture preventing engagement?
Executives communicate with teams
How to get the “C” level to change
Eric Ries “Lean Startup” / Steve Blank
Is it a panacea?
Radical culture problems abound
Confusion about what lean startup means
Risk adverse culture problems when you have golden egg to protect?
Alignment across enterprise
Cross functional teams
How do you maintain it?
Give freedom, be creative
Innovation team (I’m a special snowflake)
Executive support mandatory

The post Episode #55 – Lean Startup Principles and Agile appeared first on Episode #54 – Defects in the Sprint, with Mike Vizdos appeared first on Jurgen Appelo, author of Management 3.0, discuss:

Managers in Agile
Environments to enable innovation
Experimentation in Agile
Self-organizing teams
How to help organizations change
Stoos

Transcript

Roy: Welcome to another episode of the Scrumcast. My name is Roy van de Water and joining today is Jurgen Appelo. Could you please introduce yourself a little bit Jurgen?

Jurgen Appelo: Yeah. Sure. My name is Jurgen Appelo and I am the writer of a book called “Management 3.0.” I am also the author of a blog called noop.nl and I am interested in the role of the manager in agile organizations, organizations working with scrum or any of the other agile methods.

Roy: Cool. I’ve been scanning through “Management 3.0” and I talked to Jade quite a bit who has read the whole thing. What was your motivation to write that book?

Jurgen: My original motivation was to write a book about complexity science and Agile…

Jurgen: …developments because I like the science that explains why Agile works. I read lots of books about systems theory and thought. With people at conferences, I’ve noticed that their main problems were with management and leadership because Agile and Scrum don’t really define what the role is of managers.

People just see managers as impediments to be put on the impediment back‑log or something. Managers have to support the teams in order to make Agile really work. When I got that feedback, I thought, “OK, let’s focus my book on that topic because I happen to be a manager for 15 years.” I knew something about the role of the manager in Agile organizations.

That’s what I, then, decided to focus on.

Roy: What do you feel has been the reaction from the managers that have read your book?

Jurgen: So far, so good. Interestingly enough, most of the people who read my book are not necessarily managers themselves, but interested in the role of the managers or how to help them.

Also, in my courses for example, based on the book, I think about 20 percent of them are middle managers. The other 80 percent are formed by Scrum Masters, product owners, team leaders, sometimes entrepreneurs, sometimes a product manager. A very diverse bunch of people, but they all struggle with the management position.

Either they are themselves managers or they want to help managers in order to get them aligned with what Agile expects from them.

Roy: Many people are saying that they value innovation, but they don’t really allow the environmental conditions for it to thrive to exist. What can we, as Agile coaches, do to help that?

Jurgen: That’s a difficult, difficult question. One thing that seems to lack in Agile methods is experimentation. Basically, I learned from system’s science that there are three forms for systems to survive in changing environments. Scrum teams are, also, systems that are trying to survive in a changing environment. Those three approaches are anticipation, adaptation and experimentation.

In Scrum, we do a little bit of anticipation because we try to look at the next sprint and predict what the customer wants. At least, that’s what the product owner does. We do a lot of adaptation because we show the results to the product owner. Then, they respond, the back‑log changes and new priorities and things off that.

But what about experimentation? There is no real guidance on exploring things, just for the sake of trying things out. I explain that sometimes jokingly, “I ordered a chai tea latte from Starbucks a few weeks ago, just to see what it was and I hated it. It was terrible, so I threw it away.” This was neither anticipation nor adaptation. It was exploration, just trying things out for the sake of trying.

We seem to be lacking that in Agile organizations. That is what innovation needs actually. We need a bit of time and space for experiments.

Roy: From reading your book, I feel that you value self‑organization a lot and getting the team to feel like they have the authority to perform this type of experimentation. I’ve heard managers in the past ask the somewhat ironic question, “How do I make my team be self‑organizing?”

What is the right way to ask that question? How do I allow my team to self organize or encourage them to self organize? Have you found a good way to get them to really feel comfortable, to take the authority, to make decisions and experiment?

Jurgen: Yeah, because usually managers trouble a bit with delegating stuff to self‑organizing teams because they see as it as a black or white thing. Either I make a decision as a manager or the teams make the decisions as self‑organizing teams. They see it as just two actions. But, actually there are more options in between. There are shades of gray.

In my book, I list several levels of delegation. The second level, for example, is trying to convince a team, but you still make a decision as a manager.

The third level is a step further where you first ask the teams, “What is it that you would do if you were allowed to make that decision? Just give me your input.” Let them, still I will decide.

Step‑by‑step you could go into the direction of delegation without doing a full‑blown sweep from level one to level seven because that for some managers feels dangerous and it is dangerous with some teams. You need a more gradual approach.

I try to help them with that. I explain it sometimes as trying to find what is the speed limit. Trying to drive your car as fast as possible, but you don’t want to drive too fast because that will end up in chaos. It’s the same with self‑organizing teams. I’ve seen it myself. Inexperienced and immature are allowed to make any kind of decision, things will blow up. There is too much freedom. You have to constrain it a little bit.

Roy: What would you say to a manager that’s resisting allowing their team to self‑organize, perhaps somebody more of the traditional management role where they’ve always been taught that if they’re not in control, then everything is going to go wrong?

Jurgen: That’s a well‑known problem. It’s a good question. I can only tell from my own experience that I have noticed quite the opposite. When I introduced Scrum in the Agile organization, things were going better. Things were not blowing up around us as much as they used to before.

We have self‑organizing teams. I was able delegate to them. The performance went up. This did not diminish my role as a manager. On the contrary, it elevated me in the eyes of many, including my own CEO, because I was the one who came up with it. I was the one who said, “We have to do this.”

The result was that I expanded my span of control from 20 people to 30 people and then, in the end, to 100 people because it made us more scalable and I could manage more teams. I would deny that it makes managers feel powerless.

On the contrary, if you do it well, it could make you more powerful. It’s a bit cliche, but it is win/win. You gain from it as a manager because better performing teams reflect on you as a manager because they are your teams. My CEO didn’t want to let go of me anymore after such good decisions.

Roy: Got you. You talked a little bit about introducing Scrum into organizations and starting to form these teams. You just came out with a new protocol of how to change the world. How does that fit into trying to introduce organizational change?

Jurgen: The question that I get most often is, “How do I get other people to change their behavior?” Or any form of that question like, “How do I convince team members that they should develop themselves some more?” Or, “How do I convince my customers that they should accept Scrum and its changing back‑log and things like that?”

It’s always the same thing that Agile and Agile coaches struggle with it is convincing other people that they have to change. I have basic change management. I have researched that. I have borrowed lots of ideas from many good books and I turned it into a little handbook called, “How to Change the World”.

It is an ambitious title, but it’s only 80 or 90 pages. It sort of gives an overview from my perspective as a complexed thinker on how you should approach a social system, which an organization is.

It is a social system, and you have to poke it with ideas and experiments, and see what works and what doesn’t and do iteratively and get feedback and basically, you have to be agile as a change agent as well because you never know how the system is going to respond, how the organization is going to respond to your ideas, but just to try things out and also understand that you have to work on not only the rational level, but the emotional level as well because some people are aware of a need for change, but they have to be fed the medicine with lots of sugar.

You have to address the people’s intrinsic desires as well and not only the rational part.

Roy: In the book too, you talk a little bit about how management is often times really slow to change. Why do you think that is?

Jurgen: It’s for many reasons. I’m quite sure some of them will fear their jobs because they see it not unreasonably as a danger for their position because I do think that, in some organizations, there are too many managers. The middle management layer is simply too fat.

It can be thinner, but it doesn’t mean that we need no managers. I’m quite sure that for some this is the reason to resist and while for others it is simply not knowing what to do and willing to work with self‑organizing teams, but fearing that things go out of control. These managers would have a positive inclination towards Agile, but they simply don’t know how to handle it in a safe way.

There are many different ways, many different reasons I think for managers to be cautious or resisting. We have to figure it out on a person by person basis.

Roy: What would be your best change success story where you’ve gone in somewhere and introduced a good change?

Jurgen: That would be my own organization because I’m not an Agile coach. I can only talk from my own experience as a manager. I’ve been working in my last organization for 7 years as CIO. There I introduced Scrum and it was a success in terms of the people who were working there, both the team members, top management, and customers.

Of course, there were plenty of problems that we had to solve, but that’s what Scrum does. It doesn’t solve the problems itself. It just makes them more visible. We could start working on them, but everyone agreed that we made a good step in the right direction, that’s my personal experience. Of course, I hear plenty of stories from others, but they’re not my own.

Roy: Recently you’ve been involved and helped organize something called the Stutz network. Could you please tell us a little bit about that?

Jurgen: Yeah, sure. I was in contact with Steve Denning, another author who wrote Radical Management, Franz Roosli, who was part of the Beyond Budgeting Movement, Peter Stevens who was an Agile coach, and the four of us thought wouldn’t it be great to get people together, who are all trying to address the management problem and I’m just one of many.

We started inviting people, and this became the Stutz event, the STOLZ, it is actually pronounced in German. In Switzerland, we had 21 people together to discuss things and we tried to figure out how can we accelerate change in the world and it is a very difficult topic.

But we were very much inspired by each other and it seems that there’s plenty of spinoff activity now with Stutz satellites and Fearless Change, Fearless Hamburg, Fearless et cetera, lots of cities where events are being scheduled, and we’re already talking about some follow up events that have not been announced or scheduled yet, but at least we want to go on because it is a topic that many people are concerned about, and we’re all trying to figure out how can we help to accelerate change in the world.

My another book How to Change the World is my own small contribution, but many people have their own contributions as well and we want to align them and make it dance together, that would be useful I think.

Roy: Do you have anything that you’d like to promote or current things that you’re working on that you’d like to talk about?

Jurgen: Well, there’re lots of things that I’m working on. I’ve already started writing the next book, which is sort of a real follow up to Management 3.0 in terms of very practical stuff to do.

I aim for things you can try the next Monday morning when you get back to your work. That level of practical pragmatic stuff because my first book had lot of theory in it and I thought it was important to have a solid foundation, but now people are asking for more examples of practical things that are happening in other organizations and that they could try out.

I’m collecting those. I talk with people at conferences. I have my own idea of what I call roving coffee. I have coffee with people in various places in the world.

Wherever I’m traveling, I invite people to have coffee with me and I ask them what are practices that are working for you, I want to hear their stories so anyone who wants to share a story with me, they can do that over email or have coffee with me, I’m collecting them, and hopefully that turns into a very interesting new book that might be out by the end of the year or next year or something.

Roy: Awesome. That sounds great. I’m looking forward to it. All right, well, thank you for joining us.

Jurgen: Thank you for inviting me.

[music]

Announcer: 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. This Scrumcast is brought to you by Integrum Technologies and recorded at Gangplank Studios in Chandler, Arizona. For all the episodes, check out integrumtech.com or subscribe on iTunes.

The post Episode #53 – Managers in Agile with Jurgen Appelo appeared first on Mark Graban, author of Lean Hospitals, discuss:

Agile outside of software
Lean in healthcare
Lean as management principles
Lean is not cost cutting
Risk and quality in Lean
Bad processes and lean improvements
Improving flow

Transcript

Derek Neighbors: Welcome to another episode of the “Scrumcast”. I’m Derek Neighbors.

Corey Haines: And I’m Corey Haines.

Derek: Corey, I wanted to talk a little bit…You’re pretty well known in the community, at least in the software developer side, also a little bit in Agile and the XP side. I find your story extremely fascinating on a number of levels.

One of the things that always intrigued me is that you started programming relatively young for the average programmer, I would say. I’m curious a little bit about how you got started, and I think people can find some of that online.

What would you tell parents who had kids that were interested in computers or programming? What would you tell them to encourage them to let their kids get into this kind of craft?

Corey: I think nowadays, like I got in by cheating at video games. We had all the source codes so we could go in and change the source to let us get past points that we couldn’t get past. Nowadays it’s a little bit more difficult to do that, with all the games are huge and compiled.

Now with the physical computing stuff that’s so pervasive and so easy to get into, like with the Raspberry Pi stuff that’s coming out and Arduinos, really grabbing the attention of the kids via physically doing stuff.

I’ve done a little bit of work with teaching kids. I taught a class last summer and we used Scratch for programming. It was just amazing to see kids pick it up. It’s a graphical programming environment so there’s a lot less of the frustration of syntax errors, things like that. I’d say get into, bring those sorts of things. There a lot programs going on now around that are sort of centered around teaching kids to program.

Derek: Absolutely, we run one here at our work space, so absolutely.

Corey: That’s neat.

Derek: What would you tell your younger self if you could go back in time to that 10‑year‑old Corey Haines, what would you tell yourself?

Corey: Don’t go into Microsoft technologies. Simply because of the fact that when I started spreading my eyes out a little bit and started looking beyond the .NET space and, even before that, the VB space, that’s when I really found this amazing community of learning and the community of not just one language but most people out there that I meet are some form of polyglots.

The open‑source community is very supportive. I got into VB, C#, doing a lot about it in the corporate environment for longer than I wish I had. It was about 2004 when I started looking outward mostly through the XP community. And I wish that I had started sooner.

Derek: I think that segues really well. You talked about being in the corporate community, and certainly, how you came on my radar was when you took your yearlong tour where you said, “You know what, I’m really kind of tired of this corporate thing, and I’m really interested in really becoming a master at what I do and really broadening my horizons and working with different people.”

As part of that, you took a yearlong tour so to speak to go work with a wide variety of people, a wide variety of projects, technologies, you name it. What inspired you to do that?

Corey: In 2008, I actually left my last corporate job, joined a startup for about seven months, got fired from that startup because it just was not a cultural fit for me. Then a friend of mine and a good mentor of mine, J.B. Rainsberger, he and I for quite a few years had been talking about how great it would be to do something like Paul Erdős who was a mathematician that would basically just go everywhere and do math with people.

We always have that idea of, “Man, would it be great to have the opportunity to just go program with people? No overhead. No expectations. Just go program, go code with them. See what they’re doing. Learn from them. Teach them.”

When I got fired, I had some money saved up and was just like, “Now is the time to do it.” There’s so much out there to learn. There’re so many people out there to learn from and teach. I set up a three‑week trip.

Then it snowballed into that. It was originally only intended to be about three weeks. But during those three weeks, it started to snowball, and I started setting my eyes outward a little bit and realized that there was a whole range of people out there, that I could go code with.

It was always anywhere from a day to five days. So there was…I would come in, the only rule was, I was doing it for room and boards. I needed a place to stay and I needed food and I was pairing with somebody the whole time. And that was sort of the only rule that went with it.

Derek: What was the best part about that experience?

Corey: There were a lot of really great parts. One of the big things that came out it that I had started with this idea and actually came to fruition was. I had a much, much, better sense sort of where I was, level‑wise.

I had good understanding. I’d worked with people, who’ve been programming longer than I’d been alive. I worked with people who’ve been programming for a few years. It really gave me an opportunity to reflect on just where I stood as a developer. I was about, 11 years into my professional career, may be 12 years in.

We often times get caught up in our own community and we have a sense of where we are relative to the other people in our community. But by going out and just working with as many people as I could, I got a better sense of that.

I learned something in one place and then the next day, I would be teaching it to the next people. That sort of helped me, really solidify a lot of my understanding of the, a lot of the core fundamental techniques, that I use when I program.

Derek: I think that’s a huge, a huge deficit that this occupation has, is, it’s really hard to have a measuring stick where you are. Sometimes, if you think you are really great at something, may be you kind of pull back and you stop engaging, you stop learning.

One of the things that kind of excites me is, what if we get to a point where, companies start to put programmers out on loan, so to speak. What if it was a corporate culture to allow a little bit more polygraph behavior and allow developers to kind of meander between different corporations to help get some of that litmus test where they are at?

Corey: Actually in 2010 and 2011, there was a group of companies that were doing just that. There is a group of seven consulting companies, like Relevance and Optiva and Ethlite and a few others around the world. They started swapping employees for a week here, two weeks there.

Derek: That’s great.

Corey: Yeah. It was really neat to see.

Derek: I suspect there is a ton of great experiences. What were some of the bad experiences? What was the worst part about being on the road and working with different pairs, different technologies, different thing, every week or every five days?

Corey: A lot of it was, this is kind of a weird answer, that the worst part was the fact that it was just so utterly exhausting. I look back and I’ve thought about it a lot and there weren’t a lot of moments where I was like, “Man, this kind of sucks” or “This is difficult.”

It was a wonderful experience, I was going around, I meet people, I pull my car into somebody’s house that I had never met before, just come in, sleep on their couch and then code with them all day. But it was incredibly exhausting and probably about the first five or six months, I was doing short, several weeks, may be month long trips. Then I spent the summer of 2009, 3 weeks or 3 months, continually on the road and drove 6,900 miles, went from Cleveland to Miami to Prince Edward Island back to Cleveland.

It really was incredibly exhausting, but that exhaustion was exhilarating because I was learning so much and I was meeting people and seeing things and so I think it was really just that exhaustion was the major negative part.

Derek: It is part of this kind of journey of learning, so to speak, we’ve really seen the software craftsmanship movements start to bubble up and the metaphor of going from apprentice to journeyman to master. I know that you’re a big part of the craftsmanship movement. Why do you identify with that, and why does that metaphor strike a chord for you in relationship to software development?

Corey: Well, I really like the craftsmanship movement, the craftsmanship community because it covers the gambit of how do we bring people in to software. How do we train them through the years? Along the way, how do we interact with our customers? How do we take pride and how do we treat our code? All of these things, specifically with the apprenticeship to journeyman and beyond.

I have a hard time bringing the master term in mostly because…The only place that I use it is when there’s somebody that I personally look up to and learn from as opposed to an external, “This person is considered a master.”

I have much more focus on the idea of apprenticeship, of coming into a trade and learning somebody else’s way. I look at it as, apprenticeship is when you are studying under somebody and learning the way that they develop software. You find somebody who is an effective, proven software developer, and you learn their methodology and their techniques and their practices.

Then there’s a point where you got those practices down, and you can sit there on your own and really take the effective atom. When you have that, it’s important, I think, to go out, cast your eyes out, look at the people around, find somebody and say, “Hey, they’re doing something completely different than I am” or “They develop software differently. They don’t use some of the practices that I use, but they’re being effective.”

Go look and learn from them as well. You’ll bring stuff to share with them. You’ll be able to learn somebody else’s style. When you do that, you then start to merge those two styles in yourself, and you start to learn, and you start to reflect over those techniques. That is something that I think really could further our understanding of software development that I really like to happen.

Derek: Absolutely. There’s a few folks in the agile community that are critical perhaps of the craftsmanship movement and really struggling with tying the concepts of software development as an art form opposed to more of a scientific form.

The biggest criticism that is universal between the detractors seem to be that when we move to the metaphor of craftsmanship, the fear is that we’re turning all of the focus into the actual act of the creation of the product opposed to the deliverable of the product or the output or the effects that the product has on whoever you’re building it for.

Some of the examples are ‑‑ if you’re more worried about the stylistic making of the table so to speak in which it would be used, you’re not focused then on how it would necessarily be used in the real world. So maybe you can answer some of those detractors.

Corey: I understand where that is coming from and where those fears are coming from. There are people who have written [indecipherable 14:18] . I have a tremendous amount of respect for and had a great conversation with them about this last fall.

The thing is that being in the software development community and being in the agile community and in the craftsmanship community, we spend most of our time developing software. The things we talked about tend to be around developing software and the screencast that we do tend to be about developing software.

But there’s a very important part of the Craftsmanship Manifesto, which is the Productive Partnerships, which is really about the way that we deal with our client, the way that we partner with them to deliver software to them that is fit for use. It’s exactly what they need. No more, no less.

A lot of the craftsmanship thoughts came out of a reaction towards just the general level of horrible code that’s out there. So a lot of the emphasis that we put is on learning some of these techniques. There’s no more question about whether or not automated unit test provide value the majority of the time, and that TDD is a valuable, value‑providing method for doing design of your system.

Is it always a hundred percent of the time the thing you should do? I was talking to Fred George…He had given a great talk at SCNA where he said that if it’s faster to rewrite your system, then you don’t need to do TDD. Well, that makes sense. If it’s fast, if you’re writing a script or if you’re writing just something that’s very quick to put out there, maybe you don’t do it.

But the majority of people aren’t at that point. The majority of developers out there were not to the point where we have the experience necessary to make those decisions. I very much tell people, “Always write tests.” It’s better to overwrite them and then to reflect on the problems that that caused than to have no test at all and not do any sort of test‑first development and suffer the consequences of that.

We’ve all been through those projects, and we know that doesn’t work. We have a set of practices that ‑‑ discussion’s over ‑‑ they do work. It’s just a matter of knowing how to apply them, and you learn how to apply them by practicing them.

We talk a lot about this. If you go to the conferences that we’ve had, if you talk to the people that are involved in the community, and you go look at some of the companies that consider themselves craftsmanship companies, like say 8th Light here in Chicago, their focus entirely is on satisfying what the client needs. It’s not about polishing it. It’s not about gold plating it.

They have a very active, incredibly successful apprenticeship program. They do [indecipherable 18:00] with their people. They do all of the things that we talk about that people say we’re overly focused on, but you can’t get better if you don’t practice. The state of the software industry is atrocious right now, where doing things and making mistakes that we should not be making on our day‑to‑day jobs, so that’s a long one to [indecipherable 18:25] , so I hope the kind of…

Derek: It’s great. When you get to the core of it, I think the community is addressing the symptom that we see on a regular basis, which is really bad code and really bad practices. You have to get through that to get to the good stuff.

Corey: Yeah.

Derek: Speaking of community, you do a ton of community work with Coderetreats and Code and Coffee. You’ve got a number of projects out there whether it’d be your CodeCast or How I Got Started Programming series, I definitely think people should check out and get engaged.

Do you have anything new that you’re working on that you want to share with people?

Corey: I just last December started a nonprofit sort of centered around the Coderetreat stuff. We had this Global Day of Coderetreat last December where we had 94 cities, all doing Coderetreat on the same day. They were Skype calling back and forth, and it was just this wonderful day of bringing basically the whole globe together on a single day.

Out of that, I brought out a nonprofit called the Coderetreat Community Contribution Fund, which right now it’s operating as nonprofit. We’re under 501(c)(3) review, but the goal of that is to be sort of an umbrella organization for doing fund raising to support kids programming events as well as a small amount of the funds will go towards supporting adult practice oriented workshops of the Coderetreat nature, don’t have to be Coderetreat but just sort of practice oriented.

I’ve been working a lot on that lately, just sort of how do you fundraise. I just did a Coderetreat in January that raised $400 and turned that around and sponsored, in San Francisco, there’s an organization called Black Girls Code, which is focused on teaching underserved girls to program.

They’re doing a six week course on the national stem challenge for writing video games and stuff. We took the $400 we had and we paid for snacks and drinks and stuff for them.

The big thing that I’m really excited about now is that is sort of figuring out how to help these programs out there like KidsRuby, Hackety Hack, Black Girls Code, Code Now, and use some of the excitement that we built up around Coderetreat as a way of raising money to support that where we’re going to be doing Global Day of Coderetreat again this year in December, and the plan is for about 200 cities around the world to do it. My stretch goal is to have a Skype call with a space station.

Derek: There you go.

Corey: I figured if you’re going to have a stretch goal, it should stretch to outer space.

Derek: I’ll say if you’re listening to this, next year you need to participate in the Global Coderetreat. We’ve done it here at Gangplank a few times. We definitely participated last year in the global initiative, and it’s well worth everybody who participates time.

Corey, thank you so much for joining us today. I love the work you’re doing. I love what you’re doing to pay it forward, and you’re really a model for other developers out there to care about the code and really care about the community. Again, thank you for stopping by.

Corey: Well, I appreciate it, Derek.

Derek: Thank you.

Corey: Thanks a lot.

[music]

Announcer: 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 Scrumcast is brought to you by Integrum Technologies, and recorded at Gangplank studios in Chandler, Arizona. For all the episodes, check out integrumtech.com or subscribe on iTunes.

The post Episode #52 – Lean Principles in Healthcare appeared first on Episode #51 – Software Journeyman Corey Haines appeared first on Episode #50 – Potentially Shippable Software appeared first on Episode #49 – Topic Smorgasbord appeared first on Episode #48 – Missing the Deadline appeared first on Mindset by Carol Dweck

First Lego League

Teaching Kids to Program

Lost in Space

Transcript

Derek Neighbors: Hello! Welcome to another episode of the scrum‑cast, I’m Derek Neighbors.

Ray Van Norter: I’m Ray Van Norter.

Luann Falco: I’m Luann Falco.

Derek: So Luann, you’ve got a site called teachingkidsprogramming.org and I know you guys are doing a ton of work with different teaching styles to get kids adapted and wrapped up into programming, obviously programming is a moderately complex task.

So for a young mind I’m sure that you have got to take a couple of different approaches.

I’m just wondering if you guys have learned anything that you could maybe take into the coaching or to the agile world or to the adult world about learning styles that you have seen and how you might apply those to teams that we are working with today?

Ray: Absolutely. In fact, I find that both. We take a lot from Agile into when we teach. I teach both kids and adults, and in both cases I’m taking techniques from Agile there. Then I find that in the same way as every time you do a retrospective, that you realize, hey, there’s something else you can do, it transfers back and it creates a neat cycle.

But the first thing that we’ve seen is just this importance of feedback. In the same way as it’s really important to get your code [laughs] in front of a customer, it’s important to make sure that you are getting constant feedback. Not just as to what the kid is doing, but the kid is getting constant feedback or the student is getting constant feedback.

Derek: Absolutely. I noticed that in one of the models that I’ve seen it really talks about how you give feedback can be monumental to fostering additional learning. So one of the theories currently out there is, if you ask somebody to do something and you give them feedback, and the feedback is like, “No, that’s wrong” or “Yes, that’s right,” that you actually discourage them from wanting to learn.

Where if you reward them for the effort placed in, regardless of whether the answer was right or wrong, you say, “That’s a really great job. You did a really good job of trying to solve that problem, but it’s wrong. This is how you solve it,” that you actually encourage continual learning. I know you are really interested in some of the mindset kind of concepts, and I think the author of that book talks a little bit about that as well.

Are you seeing patterns about how you give feedback or how feedback is applied dictates how much a participant will dive in or not, dive in in the future?

Ray: It sounds a little bit the everybody‑gets‑a‑trophy.

Derek: I don’t think it’s really everybody‑gets‑a‑trophy. It’s not saying it’s not OK to tell somebody that they’re wrong or that they’re right. It’s that when you say that all that matters is the answer, that’s where the problem is. If you say the process of getting to the answer, I’m going to reward you for the effort of trying whether you tried or failed, that encourages people to go ahead and expend the effort the next time.

If you have a right answer and I say, “Yup, that’s absolutely right” and I don’t reward you for the effort you put in to get the answer, you’ll actually still be discouraged from wanting to put the effort in in the future to get the answer.

Luann: There are actually two things that are at play here that a lot of times get lumped together. One is feedback, and the other is praise. I think sometimes we consider them to be the same thing. Even if you did horrible, there’s a difference between saying, “Hey, you really suck at this, and you’re never going to be any good at it. You’re just bad” versus “You did bad at this, and you need to work harder at it. You’ll be better, but you have to try harder.”

One part is the feedback. “Did you do good or bad?” The everyone‑gets‑a‑trophy idea that says everyone is good regardless of what they did, and that’s not useful. In fact, that actually is removing a layer of feedback that’s important to the kids but the idea of then also how you praise.

Separating just the answer and the praise is a very important thing because it really is, and time and time again, the amount you work, the amount you practice. These things are really what determines where you end up.

Ray: I think it’s important to keep the two separated as well because in the past we’ve talked about the crap‑filled Oreo, right? Where it’s like the copout on how to give bad feedback is you give them a compliment like, “Hey, you’re doing a really good job.” Then you throw in something about the performance or something bad and be like, “But I notice you’ve been struggling in interacting with others.”

Then you follow it up with another compliment like, “But you’re doing a really good job, so keep it up.” Then the person walks away from the interaction not knowing whether they were rebuked or complimented or really where they stand.

Luann: Yeah.

Derek: One thing that I know is really in working with kids I think more often than not for most kids, not all kids, they still have a pretty strong belief that they can learn new things or tackle new things. They seem to not quite give up as much. I know that in working with adults, a lot of times if you encounter an adult that doesn’t know how to program, they say, “Well, I’m just not good with electronics. I could never do that.”

Whereas a kid, you put it in front of them. So are you able to take anything you’re learning with working with the kids and that can‑do attitude of…So are you able to take anything you’re learning with working with the kids in that can‑do attitude of, “I’m willing to give it a try. Even if I’ve never really played with a computer before, I’ll try this programming thing” and take that back to teams who maybe say, “Well, we’ve tried that” or “We can’t do that” or “It’s not possible to do that”?

How do you get them to start to change maybe their mindset a little bit to be a little bit more like a child in being able to try new things?

Luann: That’s actually really important. It’s weird to think about, but as a kid your life is so topsy‑turvy. Everything is changing. Your interests are changing. The people you’re around are changing. Each year you have a new grade, and your grades get bigger. You’re in smaller classes when you’re in kindergarten, but when you’re in high school the school is just massive.

In your world, you’re constantly in this state of flux. But what’s surprising is when you get to like 35 or so, all of a sudden you can do the same thing day in and day out and the same people. Your world becomes very much more controlled and smaller. You’re just not in the same kind of, “Hey, let’s go try something.”

To take just a very extreme example of that, think about in college when you head out to college in your dorm, you literally share a room with just some random stranger. That seems like an OK thing to do. But now the idea that, “Hey, I’m just going to randomly…” having a roommate, that’s a push. But a roommate usually means two rooms in the same house as opposed to the same room.

We have gotten ourselves into a much more controlled place, and that really cuts down on the experimentation. Kids are naturally in a better spot for that. What that means is you can just quicker do the thing that you need to do, which is crucial, which is get them doing something because for any kind of learning to occur, first you need some sort of experience.

Derek: I was going to say I think that’s something that definitely you can take back to teams. I think teams will debate things to death a lot of times when they don’t know. Even if it’s implementing a feature that maybe they’re not sure of the best technical way, they’ll want to beat that to death. “Let’s talk about it.”

Whereas if sometimes you’re going to say, “Let’s jump in and do it,” put out a spike, put out a tracer bullet, do something to just actually get into the doing side of things, how quickly they can come back to that childlike state. Whereas if you let them stay in that corporate state, it’s really easy to come up with a million reasons why “We can’t do that” or “We can’t try that” or “This isn’t viable” or “I don’t feel comfortable with that.”

Where if you just push them off the ledge, they go, “Hey, that was fun. I want to do the ride again.”

Luann: One of my favorite quotes from Agile is “Don’t spend 15 minutes talking about something you can do in 10.”

Derek: Right.

Man: Derek and I both volunteered with the First Lego League last year…

Luann: Ah, fantastic.

Man: …helping out. I guess if you don’t know what First Lego League is, it’s a program where you have teams of…I think it’s 8 to 14‑year‑olds. Is that right?

Derek: Yeah, 9 to 14.

Man: 9 to 14, who work together as a team to build a robot to perform a set of tasks that’s standardized across all the teams. Then they show up in a competition and compete against each other, and then they also have to build a research project around that.

Luann: This whole thing was actually implemented by the guy who did the Segway, and it’s a fantastic competition. If you have kids, I highly recommend it.

Man: One of the things that we noticed when we were working with the kids is we’d try to implement Scrum with them and at the very least start it out with having retrospectives with them every single time. We only met once a week, so we would have a retrospective every single day that they got together, so once a week.

One of the things we noticed is, first off, they were a lot more open with their feelings and exactly what was bothering them than most of the adult teams that we’ve worked with.

Luann: [laughs]

Man: The other thing is that we ran into the exact same problems with kids as we ran into with adults.

Luann: Yeah, to a large extent people are people.

Derek: It’s amazing seeing the engineering camp challenges be almost identical between grown [laughs] teams and teams of 9 to 14‑year‑olds because at the end of the day most team problems are people problems. People don’t change a whole lot in their core behaviors from the time they’re nine to the time they’re 99 in most cases without a concentrated effort to try to improve.

That definitely was a learning experience for us. We thought we needed a video series on, “This is you on Scrum when you were nine.”

Luann: [laughs] You also pointed out a really interesting part that I’ve seen emerge as part of a pattern of teaching, where you get them doing something and then you have that retrospective. Sometimes the retrospective is just so that they can see the patterns, that you need to do something two or three times before there is a pattern to detect.

You need to get them engaged, and then you need to retrospect over it to see the pattern. Then, of course, as a teacher I think the job is to guide them to see patterns they haven’t noticed or explain patterns that they haven’t noticed once they’ve had a chance to have done it before.

Derek: Absolutely. Probably the best example of that was this last year when we decided to put all of the challenges up on the board that they could potentially complete. We asked them to go estimate them from a 1 to a 10 how difficult they thought that those were and to do them as a team. So basically do planning poker.

We didn’t explain what planning poker was. We didn’t explain anything about it other than just from a 1 to 10, how hard do you think it was? In about three minutes you had seven kids basically doing planning poker and pretty much being within one step of agreement of each other on almost every single challenge. I don’t think we’ve ever seen an adult team do that.

I think as adults, what the problem is, we have no ability to believe in something anymore, so we have to question every little thing like, “Why are we using points instead of hours?” “I don’t feel comfortable about this.” Whereas a kid, they’ve never estimated anything really before. So to them it’s like saying, “How many pennies do you think are there in a jar?”

They’ve got no problem throwing out some random number. If they’re wrong, they’re wrong. If they’re right, they’re right. Whereas in the corporate world, well, if I tell you that’s a three and then you’re going to calculate my velocity, then you’re going to give me a raise based on whether my velocity’s too high or too low, I’ve got all this baggage that makes me want to not actually give you an estimate.

Luann: And not engage.

Derek: Right.

Luann: This is the thing. You’ve got to engage first, and that’s why the first few iterations, of anytime I get a team together and we start iterating, are not indicative of how that team will perform. It’s after three or four sprints that some sort of stabilization occurs and jellied.

Derek: Yeah, absolutely. So what are some other things you’re seeing out there that have your interest right now?

Luann: So talked about feedback, but I’ve found that if I get students to collaborate or pair, I think pairing is a very intense form of collaboration. It’s definitely not the only form, but it’s one that serves us very well, that they get a much better feedback cycle going. The environment for learning, there’s less control that’s inherent when two people work together. The control is already shaken.

They’re more willing to just try stuff, and they are constantly giving feedback. One person’s seeing something, but the other person doesn’t see it. You just get this much better environment for learning, and I’m actually surprised. When you walk into a classroom, it’s a very quiet place normally, and I think that actually really hurts learning quite a lot.

I see it in companies, too, where people don’t want to talk to each other. They just want to go into their own cubicle and work. While that might be good if you already know how to do something, I think it’s really bad for learning.

Derek: It’s funny that you say that. I think a lot of that’s modeled from the top. We’ve been doing a ton of work recently with school districts, principals within school districts, and superintendents of schools. We’ve got one school that we’re really partnering with on a regular basis, and we’re doing a lot of coaching and training of their staff on ways to be more agile in the classroom and be more twenty‑first‑century minded.

After just a number of sessions, leading a number of sessions with their staff with their principal with them, their principal released. I’ll put it in the show notes. He wrote a diatribe that he said that after coming in our workspace and being here for a fair amount of time, that he thinks it’s almost criminal that he has an office at the school.

He says, “When I go in there and I sit and I’m doing my email and I’m being productive, the thing that I’m really doing is I’m shutting out all my students and all of my staff from being able to have access to me and for me to really be effective.” So he’s actually looking to get rid of his office and start to work out of classrooms of the students so that he’s more available to his staff and to his students on a regular basis so that he’s there.

I think that the important part from my aspect is talk about the power of leadership saying, “I think it’s important to be collaborative. I think it’s important that I’m making myself available and I’m doing that.” He even stated, “I’ve had open‑door policies ever since I’ve been an administrator both literally and physically. But people don’t come in and interrupt me because the fact that I’m in my office makes them think I’m not accessible.”

Ray: Then he talks about, too, how he feels like he’s chained to his office and conjectures to imagine what students must feel being forced to sit in the same desk, shut up, and just pay attention the entire day but not be able to contribute to their own education.

Luann: Which is horrible because again, once you start engaging and you start looking at it, that’s joyful. Learning in general is a joyful activity. Just to go into this idea of feedback and collaboration. Another concept that we’re seeing a lot, which is layering, which is you don’t learn everything at once. You build. You layer learning on learning. That’s how you gain skill.

One of the places that I think is doing this better than any other area in the world right now is video games. If you look at a lot of video games, there are a lot less instructions. The tutorial is becoming the game, and you’re getting amazing feedback in these nice little layerings. Through that and interaction you’re learning pieces of the game.

There are some really nice examples out there right now. Portal springs to mind, a really good one. Also, there’s a game called Limbo. Both of them are teaching you something with a very interesting model of instruction.

Derek: Absolutely. So we’re at our time. Any final words or parting thoughts before we head off?

Luann: The first is go and teach your kids to program because it’s really on you to do it. There are a lot of neat resources out there. I know you guys run great stuff out there. Chandler, if you’re online, we have more structured courseware at TeachingKidsProgramming.org. Even if you do no courseware, just sit down with your kids and program with them, it’ll open whole new doors and worlds for them.

Derek: Absolutely. Thanks for joining us, Luann, and we’ll see you in a later episode.

Luann: Thanks.

Derek: OK.

Man: 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 post Episode #47 – Can Teaching Kids to Program Help You Be a Better Coach? appeared first on Episode #46 – Corporate Cultures appeared first on Pragmatic Thinking and Learning by Andy Hunt

Forget Why You Walked Into the Room?

Transcript

Clayton Lengel‑Zigich: Welcome to another episode of the ScrumCast. I’m Clayton Lengel‑Zigich.

Jade Meskill: I’m Jade Meskill.

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

Derek Neighbors: I’m Derek Neighbors.

Jade: So like Still Water…

[laughter]

Jade: …is like because you’re European…What you?

Roy: We’ll mix up the verbs and other things.

Clayton: Quite, you’re so European, you don’t even know, to get the things up.

Today we’re going to be talking about Digital Boards and Physical Boards. Let’s say that I’ve got a digital tool and has my Scrum board in it. And I’ve a physical collocated team, is that going to be problem or can never just look at a computer screen.

Derek: Certainly, everybody could. The question is what are the benefits of a Physical Board versus Digital Board. Andy Hunt’s “Pragmatic Thinking and Learning” is a great book that talks about some of the brain science behind physically writing things down versus typing them into a computer, or versus seeing them on a computer.

It cements something different in your memory. I like to equate this to when I see great schoolchildren or even college students, being asked to memorize vocabulary words or terminology. Usually the teacher requests that they write them down, write them in a sentence, write the definition down. Then they memorize from there. They don’t just give them a printed sheet and say, “Go read the printed sheet and memorize it.”

It’s because something in our brain is wired differently when we actually do the act of writing things out. When you’re forced to write out the story or write out the sprint items or the tasks, I think that something wired different in your brain happens. The second thing is, nobody goes to their computer to look at all that stuff.

When there’s big visible charts all over the walls, it’s much easier for somebody not involved directly in the project, or somebody on the outside, to ask questions. They’re not going to go look at the chart in some digital tool eight things deep, find something out, and then send an email, or not very often. Usually it’s too late. If they’re getting to the point where they know something is that wrong and they’re looking at the tool, it’s probably too late to help.

Jade: If you are physically collocated team, it’s much more difficult to hide from a physical board that has a presence in the room that you’re in, where it’s very easy to minimize a window and just essentially ignore everything that’s going on inside of the software system.

Roy: We’ve even seen examples where we would send emails of our burndown chart for example to everybody within the company or post a picture of it in the chat program we use, and still nobody really commented on it or noticed it even though it was being hand‑delivered to you saying look at me, it still didn’t really have the same effect as to something you occupy every day.

Jade: I saw a really interesting study that really talked about the brain and how when you move from room to room, that the doorway actually creates some physical barrier inside of your mind and that when you walk into a new room, it basically forgets everything about the old room.

I started thinking, “Does that apply to windows in our applications”? Like when you minimized that window, does your mind like basically shift gears into, “Well, now I’m doing something new and I’m in a new room. I can disregard all the other stuff.”

Clayton: What are some of the other benefits that you would get if you were a physical team having a physical board? Does that help promote collaboration or communication? What are some things you would get from that?

Jade: I think it’s a lot like having a face‑to‑face to conversation. There’re a lot of things that are communicated without words, and by placing it up in a physical dimension, you can tell so much more out of glance than looking at your screen which can only convey so much information and so much detail, just due to its limited size.

You can get away with a whole lot more. You can have a lot of more informal statistics or data that becomes very difficult for a computer to calculate. If I want to write something up on the board, I can just do it. I don’t need a special place to put it or if I want to post something new that we’ve never tried before, I don’t need a code to let me do that. I can do it with a piece of paper.

Derek: Some of it goes towards…if you’re really trying to be agile, you want to be locked into some best practice? That starts to…

Jade: Or at least a practice. [laughs]

Derek: Yes, that starts to cramp. A good example on build now on what Jade said is, “The nice thing about blank index card is it’s a blank index card,” so anything your mind can imagine to do with and index card, from shredding it up to adding new elements to doing anything, is possible. Whether you want to use pushpins with different colors to meant different thing, if you want to use different colors with a type of marker, the sky is the limit.

So if you want to try something, a great example I’ve seen our teams do in the past on occasion is, “Hey, we really want to enforce time boxing. We want to see how we’re performing against tasks, because a lot of people are questioning that. It’s as easy as drawing, if we think this is going to be a hour long task drawing one square for each one of the tasks, and then filling it in as it’s getting completed.” That would be really difficult to do in a tool that didn’t have that functionality already built into it.

The nice thing is, you can experiment with that. If that works really well, great. Maybe you keep doing it. If it doesn’t work well, or you get the data that you need to make the decision, I think in a lot of the cases I’ve seen a team think, “Oh, well the problem is our tasking is really, really horrible. It’s taking us way longer than we think to do the task.”

When they do something like that, they realize it’s not that the tasks that we are putting out there are taking too long it’s that we’re doing really crappy planning. We are not putting out half of the tasks that actually need to be done to complete the work. We put task A is going to be half an hour, and task B is going to be half an hour. We find that it really only took half an hour to do each one of those tasks.

But we totally glossed over the fact that there were tasks C, D, E, F, G, H that we just totally didn’t even talk about in planning. In reality, we need to fix our planning, not fix the estimates of our tasking. It allows you to play with things in a lot more easy format without having to fight against the…you never hear, “Well the index cards don’t do that.”

Jade: [laughs]

Roy: Right.

Clayton: To play devil’s advocate a bit, I’ll ask, “Doesn’t it take a really long to update your physical board”?

Right: Right. Everybody…

Clayton: Yes, it does. Is that what you are saying?

Jade: Doesn’t it take a really long time to update your digital board?

Roy: Every Agile team at some point, it seems like, gets into the, “OK. We need to start replacing the physical tools with digital tools.” I feel like they always have four big reasons for doing that. The first as I say, it’s way too much overhead to update a real board; which I think is kind of bullshit, because it doesn’t take any less work in my opinion, than filling out a digital tool. And it gets you a lot of value.

Another reason why they oftentimes want to go with digital as opposed to a physical board is because they say they want to save paper, which I think is just bullshit altogether.

[laughter]

Derek: You’re European, so it makes sense.

Roy: The third reason is because they are a distributed team, which I think is the only reason that I can come up with that has any validity at all. The fourth reason ‑‑ I forget at the moment, but I’ll jump in a second with it.

Clayton: Oh, I have another one. I would use a physical board, but I need to keep track of everything we’ve done, because what if I need to look at it again later? If I have a digital tool, it will save it all for me.

Roy: Yeah. So, you’re never going to need that data.

Clayton: Yeah, but I really, really do.

Roy: No, but you really won’t.

Jade: When you need it, you can write it down on the index.

Derek: I think a lot of this goes back to…

[crosstalk]

Jade: You can save all the cards.

Derek: …a lot of teams still have project manager mentality. The idea is, “I need to track tasks and I need to track who is doing the tasks. I need to track the actual hours against the tasks. I need to track all this data because at some point I need to hold somebody accountable.” The truth is, if your team is doing that, you’ve got way bigger problems than for using a physical board, or using a digital board.

That’s because you don’t trust your team, and you don’t believe the team’s going to do the best decisions. The teams that want that information so that they can actually improve don’t have a problem collecting that data. I know that we’ve thrown together spreadsheets on several teams where it’s like, “Let’s collect the data for two weeks and find out what’s really going on.”

Then make an adjustment and collect another two weeks. But very rarely you need to collect that data long term. I think that it’s one of the classic be careful what you measure. If you’re concerned about measuring the number of hours of tasks, and who is doing what, well that’s what you’re going to get. You’re going to get people that try to game the system, so that they don’t look like dumb asses for the number of tasks.

If you’re actually trying to deliver software of value, make that be what matters.

[crosstalk]

Jade: Measure lines of code.

Derek: Make that be what gets measured.

[laughter]

Derek: Function points are my personal favorite. Some of that goes back to…that’s more of a management thing usually, than a team thing.

Or if it’s a team thing, it’s because somebody is definitely afraid that they’re kicking ass, and that they’re not getting credit for kicking ass, which I also think is an entirely big smell. That you’re not a team player if you’re only worried for getting credit for the work that you’re doing, and you’re not actually worried about delivering the best product and making it the best.

Jade: That or you know that Clayton’s doing a terrible job and you just want to expose it. That’s how you’re trying to come up with that.

Roy: Leaving your paper trail so you can fire him.

Clayton: Let’s say I’m a development manager, and my team comes to me. I have this Scrum team or whatever. They come to me and they say, “We’re using this digital tool now, but we’ve all talked about it. We listen to the really awesome podcasts. And we decided that we want to have a physical board.”

Roy: Is there a podcast out there that talks about this?

[laughter]

Jade: Yeah, we’ll send you the URL later.

Clayton: Is that something the team can decide? Should I let the team do that? Or should I just jump out the window and give up? Those are the two choices.

Jade: If I was a development manager…

[laughter]

Roy: What’s the title again?

Derek: If it’s got the word “manager” or “management” in it, you should just jump out of the window now. And yes, I’m kidding to all those people that are managers.

Jade: Should we let the team do it? I think if you truly believe in self‑organization, then, yeah, you should let the team do it because that’s their work.

I think you have a reasonable expectation to get the information that you need to do your job to report to the people above you and stakeholders and all that stuff, so that information should be delivered to you however you need it.

But when it comes to the team performing their own work and managing their own work, that is the team’s realm of responsibility, and they should be fully able to do it however they would like whether that’s a digital or a physical tool. I don’t think it’s management’s role to dictate that solution.

Clayton: What are some instances…You hinted at Roy, but what are some instances where maybe we would want to use some digital tool? Maybe we want a physical board, but we think we need a digital one.

Roy: The one that I brought up was a distributed team. That one I would say, “Why distributed”? But if you really have to be distributed, then you have to have some way of keeping track of everything, and I haven’t found a better way than a digital tool, but as soon as I do, I’m jumping off the…

Jade: [laughs] Teleportation.

Derek: I think anytime you got a lot of cash to burn and you want a bunch of licensing fees is a good time to…

Jade: Yeah, if you really like that tool vendor [laughs] .

[laughter]

Jade: I think a distributed team is definitely a situation where a physical board does not work. We’ve tried it many times being distributed ourselves to try to manage a physical board, and at some point, it completely falls apart.

Roy: It was a physical implementation of a digital tool because it would be, one person would maintain a physical board and take a picture of it and send it to everybody else.

Jade: Which was just insanity. It was…

[crosstalk]

Roy: …writing an intelligible digital tool that you couldn’t update immediately.

Jade: Yeah, it wasn’t providing value.

Derek: Another valid reason for it ‑‑ and I would say that this should be a short‑term reason only ‑‑ is if you are in probably a larger company whereby you are a pilot or one of the few teams in an agile organization and you still have reporting structures that are requiring some of the data that you might need digitally.

Now in those instances, I would really recommend to go ahead and let people use a physical board and then actually key the information that you need for whatever roll up reporting you need for your manager. But I would say that in that case, it would be worth double keying that information to allow the team the benefits of a physical board.

But I could see somebody saying, “It’s just not worth a waste of doing it in paper and keying it in.” I’d say, “I don’t think you understand the benefits well enough,” but if you really believe that, I think that that is another reason. If you have to report some of the upstream until you can convince them otherwise, that might be a reason why you would see that.

Roy: Another reason too in that exact same situation ‑‑ why you would want to double key the information? ‑‑ is nothing starts conversation as well as a board. I can’t tell you how many times I’ve been sitting around here at Gangplank and then somebody comes up and asked me, “What’s the deal with all these cards”? Even people that normally wouldn’t ask questions of anybody else.

Jade: We’ve seen that in client’s sides too. The CEO or some executive VP walks by and says, “Oh, what’s going on? What do these charts mean”? And you can start to have a real conversation.

Derek: Absolutely. One of my favorite stories along this line is, we implemented cards, and I was sitting more where the executives were not necessarily where the team was, so the team had decided to put the board in that hallway, which I thought was bad for the team, but I thought it was good because it got a lot of management highlight.

I had one of the members that wasn’t on our team ‑‑ she’s not part of the development at all ‑‑ walk by, and she’d called me “card man.” We joked and laughed. She said, “Even though I’m teasing you, I’m serious. I really liked it.” She showed me cards that were for…The output of the software directly affected her department. It was the tool they used.

She said, “Right here, it says this, but it’s missing one. Do you know when they’re going to do that”? I said, “Well, they chose to not do that this sprint.” She said, “Well, why not”? She actually got really upset like, “That’s the most important thing, and it’s not even on there.”

She was able to go back to that development manager and say, “Hey, how come your team didn’t do this”? They gotten to a lengthy discussion, and it brought out all sorts of things about the inefficiency of the particular tool. She would have never done that if they were using a spreadsheet or some tool because she wouldn’t have ever known that it even existed.

That it’s those serendipitous moments that we don’t even really talked about very much that sometimes provide the most amount of value by having things out in the open and able for feedback from anybody.

Jade: What do you do if you’re a distributed team?

Roy: Cry [laughs] .

Clayton: Also jump out of the window is an option.

Jade: Jump out the window. Yeah, OK. So I’ve cried. I’ve jumped out the window. And they brought me back from the dead for this project [laughs] . What do you do to try to get the advantages of a physical board and a distributed world?

Roy: One thing that I’ve tried in the past is to use an online spreadsheet tool, like Google Spreadsheets, because it gives you a lot of flexibility while still maintaining somewhat a structure.

Although, I found that that works great for two weeks, and then it starts to get really disorganized as we try to make the same types of adaptation that look perfectly organized on the index card, but it starts to look very messy on a spreadsheet.

Derek: For me the problem is that you’ve got a much bigger problem than your board once you get distributed. I think that not being within proximity of other people is a much larger problem when you’re distributed than whether it’s physical or digital boards.

I’d say the first thing I would do is try to do everything humanly possible to simulate being collocated even though you’re distributed, whether that be Skype, whether it be pair programming, whether it be some kind of online instant messenger app, anything that promotes a lot of communication that is asynchronous and can simulate real being in a physical presence to someone.

I would really stress that that’s probably the most important. Once you have that, I think then you can start to add ways to say, “Hey, maybe every so often, we’re going to post the current burn down, or we’re going to do something, or maybe we’d add another stand up or something.”

I think there’s ways you can start to say, “How do we incorporate what we’re putting in a digital tool into the conversation”? But most distributed teams just don’t even have the conversation, which is, I think, absolutely critical to have.

Clayton: To wrap up, can we go around and get one thing that you think will make the most of your physical board, something that will make it better than it could be on its own?

Jade: Colors.

Derek: For me, the biggest one is big, visible charts.

Jade: I should say “meaningful colors,” not just random rainbow.

Roy: What I’ve seen help a lot was Derek’s example, where you show your time box by indicating the black boxes for you’re still using your time box. For every 15 minute increment, you draw a square. As you exceed your time box, you start drawing red ones. It becomes very easy to see.

At an overview, you can see an entire board. You can see where sections are red and where sections are green. It becomes very easy to see which stories cause the most problems throughout that week, and which ones went a lot faster than expected.

Clayton: For me, I would say updating the board in real time and collapsing things. You collapse all your tasks that you’ve completed down so that over time, as you’re passing by, in your subconscious you can look at the board. It looks different. It starts looking smaller, and it looks like things are going away.

Derek: I think that’s a really powerful one.

Jade: That’s good.

Clayton: Thanks guys.

Announcer: 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 post Episode #45 – Digital Boards and Physical Boards appeared first on Episode #44 – Story Sizes, Named Sprints and Partial Credit appeared first on Special Episode – 2012 Predictions appeared first on Episode #43 – Taking to the Twitters appeared first on Episode #42 – Shared commitments with Howard Sublett appeared first on Episode #41 – Working with Proxy Users with Alan Dayley appeared first on Episode #40 – Management Inbreeding with Darrin Ladd appeared first on “What is the Right Iteration Length”

Is it better to have a shorter iteration and close the feedback loop
Is it better to have a longer iteration to decrease the overhead of the Scrum Ceremonies?
Sprint Review seems to be the only ceremony not proportionally decreased with sprint length
Retrospectives do not have to occur every week, or perhaps have an extended retro every other sprint
The cost of deploying is sometimes an argument for longer sprints
Deployments and releases should be unhinged from sprints
The team agrees that shorter sprints are generally better

Transcript

Jade Meskill: Hi. Welcome to another episode of the Scrumcast. I’m Jade Meskill.

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

Chris Conagher: I’m Chris Conagher.

Derek Neighbors: I’m Derek Neighbors.

Chris: I was reading an article this morning by Todd Landry, called “What is the right duration length?” He was bringing up some experiences that he had in trying to discover what the correct duration length is. He says that when they first started forming an agile team, they were new to the concept. They figured they’d do one week iterations. They’d have a really quick feedback loop and be able to adjust as quickly as possible.

He says they did that for a little bit. They felt that the overhead of all of the scrum ceremonies for one iteration, got out of hand, so they increased it to two week iterations. He felt that that worked a lot better for him. He says around the holidays they started an iteration where they said, “Well, we can’t really do a real iteration, so we’re going to start now, and we’re going to end when the last person leaves the building.”

It ended up being about a four week iteration, and he says that that was a complete nightmare.

Roy: Yeah, it sounds that way. I was about to unleash on that one, but…

[laughter]

Roy: At Integrum we have done a lot of one‑week sprints, and you guys have all been a part of those one‑week sprints. What do you think, what was the positives from doing one‑week sprint?

Chris: I think some of the positives were that the ceremonies were very targeted. We had to learn how to keep them under control. I think that’s something the teams go through is that they don’t do a good job of making sure they keep those ceremonies under control, and that’s why they get so much overhead from them.

Derek: Yeah, I tend to agree. The number one thing that I hear from people is that the overhead on one week sprints is too high. The only ceremony that I believe has that amount of overhead is, really, the sprint review including the retrospective. The main reason that I say that is planning should be a rough estimate of a percentage of time in your sprint.

If you’re doing a four‑week sprint, you might spend an entire day. If you’re doing a two‑week sprint, you might spend a half‑day. If you’re doing a one‑week sprint, maybe you’re doing two hours. I think that what happens is a lot of teams doing one‑week sprint spend a whole day planning, and that’s where they feel the overhead is. I think they’re just being inefficient in how they plan. I, actually, think it’s poor planning that hurts one‑week sprints, not that there’s too much overhead.

We’ve played with this on and off. On the retrospective side of the fence, say, we’ll only do the retrospective every other week, or do a light version of the retrospective, where we at least catalog real quickly some high level frustrations, but don’t dig too deep. Then, on the opposite week, dig a little bit deeper, and spend a little bit more time during that.

From a demo perspective, which is really the other element of it, you should be demoing your work pretty much as you complete it. You shouldn’t be building up a whole lot of sprint demo time to begin with, so…

Roy: I think there’s a lot of teams that don’t follow that particular piece of advice, where they’re demoing constantly.

Jade: But even if they’re not demoing constantly, if they are only demoing one week’s worth of stuff, then their demo shouldn’t take the same length of time.

Derek: I think another thing that kills people too is there’s this really bad stigmatism that you have to deploy when you have an end of a sprint. A lot of teams, deploying is very painful, and so that eats up a lot of time. It’s actually getting things deployed so that they can actually demo. It’s why I find, when there’s a poor build environment that, generally speaking, teams are less likely to want to do one week sprints, because the deployment for demoing takes up half a sprint.

Roy: I always tell people that they need to unhinge deployment and releases from their sprints.

Jade: However, I kind of feel like, if you’re doing the deployment every two sprints, then that kind of builds up a cadence. It does almost feel like it would make sense to…

Roy: I think it’s nice, and it’s good if you can get there. But I don’t think they should be solely dependent on each other.

Jade: I think in an ideal situation, you’re deploying as often as you’re demoing, which is daily, and you don’t have to worry about it.

Roy: I think that’s a pretty highly evolved product or organization that can live in that continuous deployment world.

Derek: I guess where I get really concerned is, I’m even OK, as much as I might bag on it, on a 30 day sprint, or a four week sprint, as long as a team understands that that’s a segment of where they’re at, not where they should be going.

I get concerned when somebody starts with a one week sprint and then pulls back to a two week sprint, and says, “For us, just a two week sprint works better.” Because what they’re really not acknowledging is all the problems that are keeping them from being able to do a one week sprint. I see teams do one week sprints all the time, really, really effectively, which means it’s doable.

If it’s not doable for your team, there’s probably other symptoms that are happening. Either you’ve got poor deployment practices. You have bad product ownership. You have poor planning meetings. A myriad of different things can be coming up that are preventing it from it.

Sometimes when people kind of roll back to this less‑than‑ideal state, if they don’t do it with a, “We’re only doing this for right now until we can get better at the other things,” then I think that that’s dangerous.

Jade: I think that there’s some huge downsides, too, to doing one‑week sprints. I’m sorry. Downsides to not doing a one‑week sprint, specifically when it comes to regards to research tasks. If I’m doing commitment during planning and during my planning meeting, I find out that I don’t have enough information and I need to write research tasks.

If have a one‑week sprint, then it’s relatively low‑cost. I spend one‑week doing the research. In the following week, I can immediately do that task. If I have a four‑week sprint, that means I do the research task. That even means it’s four weeks until I do the research task. Then I don’t commit to getting it done until four weeks after that.

It’s going to be eight‑weeks until that story gets done. Or I do the research task immediately, but then it would be four weeks before I, actually, address the story. Then it’s four‑weeks between research tasks.

Derek: But, if it takes you nine weeks to deploy, that’s all OK.

[laughter]

Chris: Something that we’re talking about is that some of these teams that we hear when they’re doing one‑week and then they go to two‑week, how many times do we hear it’s right in the very beginning? You’re talking about retrospecting, realizing, “What do we need to change,” where they’re getting used to this, so it’s probably talking them longer than it would.

Are they really retrospecting, going, “Are we getting better at this? Can we stay at one week?” I have some questions in regards of what did the team think of and why did they go to two weeks?

Derek: Too much overhead.

Roy: I think it’s reduces that pressure like Derek’s saying. Doing a one‑week sprint requires a lot of discipline, and a lot of willingness to introspect and really pay attention to yourself. When you see people getting really uncomfortable with that, it’s because they’re trying to get a little bit more of a buffer to feel a little bit safer.

I think that’s OK in the early adoption phase. But like Derek said, if you just get stuck in that rut because, “Well, that’s just what we do,” I think that’s a bad place to be. You should really be trying to challenge yourself, but I think that’s reserved for teams that are a little bit more mature.

Jade: With longer sprint‑sizes, you’re increasing the risk in a self‑organizing team. Because when a self‑organizing team comes up into retrospect, and comes up with an idea and they try it, in a one‑week sprint, they can cancel out that new thing to try within one week. But if you have a four‑week sprint, you’re stuck with that for four weeks. That can be devastating to the company.

Roy: You could also do retrospectives disconnected from your sprint.

Chris: That’s true.

Derek: I think, as an industry, most people are doing two‑week sprints. I don’t know many people that are really on a 30‑day or four‑week cycle, but one thing I’ll say that I noticed with almost every team I encounter. The teams that like two weeks sprints only can pull in two or three stories, generally, per sprint. When they task out to do their commitments, it’s usually in terms of days.

I don’t mean ideal days. I mean, “Well, I’m going to work on this task today. Tomorrow, I’m going to work on that task.” When I see teams that are OK with one week sprints, and actually prefer one week sprints, I usually seeing them pulling in three or four stories, at least per sprint. They’re pulling in tasks down to a 15 minute, nothing bigger than hour or two.

I think that that gives them a lot more fine grain control over, are they ahead or behind schedule. It really helps to pick up pace. That’s not to say that people doing one‑week sprints complete more stories. That’s not the goal of bringing in more stories.

But, they have a habit of decomposing things to a smaller level which gets them a better accuracy from a standpoint of when something’s going wrong, they know that’s it’s going wrong a lot sooner. It’s not because they’re in a one week sprint. It’s because they’re not having to wait until the end of the day to figure out, “Oh, I’m kind of behind schedule.” They know that by lunchtime of the first day.

“I’m an hour behind. Or the team’s three hours behind.” It allows kind of those course corrections to happen within an hour of a sprint opposed at the end of a week, or at the end of two weeks.

Jade: I think that we all agree that it seems like the shorter the sprint length or, at least in our case, we feel that a one‑week sprint provides the greatest ability to react to change to minimize the risk and offers a lot more advantages. Oftentimes, a desire to go for longer term sprints are a result of other pains on the team. Or other malfunctions within the team that cause them to shy away from that.

Roy: I think you need to take the rest of the organization into account as well. I see a lot of challenges, sometimes, for development teams that are willing, and able, to go to one week sprints, but there’s some impediment at the organizational level that’s preventing them from doing that. I think…

Jade: Product Managers.

Roy: [laughs] . I wasn’t going to name names, but I think that does factor into that as well. It’s important for teams to be cognizant of that. Also, I think, try to work towards solving that. What’s wrong, or what’s happening inside the organization that’s preventing the other part of the team, the product donor, from being as responsive as the development team.

Derek: It’s not just product donors, design too.

Roy: That’s a whole other Podcast.

[laughter]

Jade: I think that’s it. Thank you for joining us.

Chris: See you next time.

[music]

Mark Graban: Hi, this is Mark Graban, from leanblog.org. I am looking forward to being a future guest, on Scrumcast. You can also listen to my Podcast, if you go to leanpodcast.org. I cover “lean” from a pretty broad perspective, including manufacturing, healthcare, startups, and software. You can listen to Podcasts that I’ve done with Eric Ries, with Brant Cooper, and Patrick Vlaskovits, on customer development.

You can find all of these on iTunes, if you search for leanblog, or go to leanpodcast.org.

The post Episode #39 – What is the Right Iteration Length appeared first on Special Episode : User Story Class Interview with Rose Hess-Nunn appeared first on Chief Revolutionary Officer:

Lately I have been doing a lot of work with organizations on Portfolio Management. I needed to create a fun game to give an introduction to the challenges of an Agile Portfolio without being overwhelming.

In April 2011, I attended the Agile Game Incubator at Agile 2011 and utilized the PLAID technique that Mike and Don taught us. This framework was extremely helpful for focusing me on my objectives and building a solid game. If you haven’t checked out tastycupcakes.org and used some of the amazing games, you must.

My goal was to create something meaningful, yet playful, that had a team building element included. I created some fun personas to the game to let people role play and laugh a lot. I’ve used this game successfully with clients and also with my fellow coaches at the Scrum Coaches Retreat 2011.

Here is an introduction to the game that I created and you can find a link to download the facilitator’s kit at the bottom of this post. If you have any improvements or suggestions, please comment.

Problem

The management team of Zebco, Inc. has too many projects, too few resources. This game teaches teams how to prioritize the people and resources they have available and try to maximize their effectiveness.

Some randomness is introduced by the dice roll. This helps simulate reality when unexpected things happen and makes the game more fun.

This game is sized for a team of 3-7 people. For larger groups, split them into smaller teams of 3-7 people and provide them with extra copies of all materials.

Lead Objectives

Learn how delicate the balance of projects can be
Learn how to manage limited resources
Learn to deal with conflict

Downloads

Visit the original Agile Portfolio Management Game article for the latest version.

The post Agile Portfolio Management Game appeared first on Scrum Coaching Retreat in Boulder, CO. During the course of the intense two-day deep-dive, the need arose for a wiki to capture all of the amazing ideas. Within minutes of creating the wiki, the information began flowing in. By the end of the retreat, more than seventy coaches from around the world had shared their wisdom for everyone else to benefit, and continue the conversation.

Please contribute your thoughts and ideas at the new Scrum Coach Retreat Wiki.

The post Scrum Coaching Retreat 2011 Wiki appeared first on Episode #38 – Communities in Scrum with Perry Reinert appeared first on Special Episode : User Story Class Interview with Sandra Bufford appeared first on Episode #37 – Software Craftsmanship with Adam Sroka appeared first on Phoenix Scrum User’s Group.

The post Special Episode : Doug Hall Phoenix Scrum User’s Group Oct 2011 appeared first on Episode #36 – Liftoff, with Ainsley Nies appeared first on Roy van de Water after the October 2011 Phoenix Scrum User’s Group.

The post Roy van de Water Phoenix Scrum User’s Group Oct 2011 appeared first on Episode #35 – Technical Excellence in Scrum appeared first on