Integrum http://integrumtech.com Revolutionary Teams, Organizational Transformation Sat, 30 May 2015 06:08:16 +0000 en-US hourly 1 https://wordpress.org/?v=5.5.1 Episode #148 – What’s a Culture Fit? http://integrumtech.com/2015/06/episode-148-whats-a-culture-fit/ http://integrumtech.com/2015/06/episode-148-whats-a-culture-fit/#respond Thu, 25 Jun 2015 06:00:09 +0000 http://integrumtech.com/?p=7678 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.

The post Episode #148 – What’s a Culture Fit? appeared first on Episode #148 – What’s a Culture Fit? appeared first on Episode #147 – Agile: It’s Supposed to Hurt! http://integrumtech.com/2015/06/episode-147-agile-its-supposed-to-hurt/ http://integrumtech.com/2015/06/episode-147-agile-its-supposed-to-hurt/#respond Thu, 18 Jun 2015 06:00:48 +0000 http://integrumtech.com/?p=7676 Derek, Clayton and Chris discuss the idea of how difficult it is to work in an agile environment, embrace agile methodologies and do the right …

The post Episode #147 – Agile: It’s Supposed to Hurt! appeared first on Episode #147 – Agile: It’s Supposed to Hurt! appeared first on Episode #146 – Listener Question: Technical Projects http://integrumtech.com/2015/06/episode-146-listener-question-technical-projects/ http://integrumtech.com/2015/06/episode-146-listener-question-technical-projects/#respond Thu, 11 Jun 2015 06:00:23 +0000 http://integrumtech.com/?p=7674 Derek, Clayton and Chris answer a listener question about technical side projects and how they fit into the bigger picture.

The post Episode #146 – Listener Question: Technical Projects appeared first on Episode #146 – Listener Question: Technical Projects appeared first on Episode #145 – Lean Coffee with Mark Ng http://integrumtech.com/2015/06/episode-145-lean-coffee-with-mark-ng/ http://integrumtech.com/2015/06/episode-145-lean-coffee-with-mark-ng/#respond Thu, 04 Jun 2015 06:00:52 +0000 http://integrumtech.com/?p=7671 Derek, Clayton and Mark do a Lean Coffee episode and discuss: Retrospectives, Visualizing flows across teams, Backlogs and more.

The post Episode #145 – Lean Coffee with Mark Ng appeared first on Episode #145 – Lean Coffee with Mark Ng appeared first on Episode #144 – Presence http://integrumtech.com/2015/05/episode-144-presence/ http://integrumtech.com/2015/05/episode-144-presence/#respond Thu, 28 May 2015 06:00:06 +0000 http://integrumtech.com/?p=7666 Derek and Clayton talk about presence. How do you indicate presence? What does presence look like for distributed teams? What happens when there is little …

The post Episode #144 – Presence appeared first on Episode #144 – Presence appeared first on Episode #143 – Feedback Loops http://integrumtech.com/2015/04/episode-143-feedback-loops/ http://integrumtech.com/2015/04/episode-143-feedback-loops/#respond Thu, 23 Apr 2015 17:55:00 +0000 http://integrumtech.com/?p=7648 Clayton and Derek discuss feedback loops.

The post Episode #143 – Feedback Loops appeared first on Episode #143 – Feedback Loops appeared first on Episode #141 – WTF is Wrong With Agile? http://integrumtech.com/2015/04/episode-141-wtf-is-wrong-with-agile/ http://integrumtech.com/2015/04/episode-141-wtf-is-wrong-with-agile/#respond Wed, 08 Apr 2015 06:00:19 +0000 http://integrumtech.com/?p=7632 Derek Neighbors, Jade Meskill, and Clayton Lengel-Zigich discuss: the state of Agile today.

The post Episode #141 – WTF is Wrong With Agile? appeared first on Episode #141 – WTF is Wrong With Agile? appeared first on Episode #140 – Our Ideal Team http://integrumtech.com/2014/09/episode-140-our-ideal-team/ http://integrumtech.com/2014/09/episode-140-our-ideal-team/#respond Thu, 04 Sep 2014 06:00:00 +0000 http://integrumtech.com/?p=7636 Derek Neighbors, Jade Meskill, and Roy van de Water discuss: Our ideal team. Transcript Jade Meskill:  Hello, welcome to the “Agile Weekly Podcast,” I’m Jade …

The post Episode #140 – Our Ideal Team appeared first on Episode #140 – Our Ideal Team appeared first on Episode #139 – Rapid Team Growth http://integrumtech.com/2014/06/episode-139-rapid-team-growth/ http://integrumtech.com/2014/06/episode-139-rapid-team-growth/#respond Thu, 12 Jun 2014 13:00:31 +0000 http://integrumtech.com/?p=7612 Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss: How to deal with a rapidly expanding team. Transcript Clayton Lengel‑Zigich:  Welcome to …

The post Episode #139 – Rapid Team Growth appeared first on Episode #139 – Rapid Team Growth appeared first on Episode #138 – Principles or Practices http://integrumtech.com/2014/06/episode-138-principles-practices/ http://integrumtech.com/2014/06/episode-138-principles-practices/#respond Thu, 05 Jun 2014 13:00:32 +0000 http://integrumtech.com/?p=7608 Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss: What is more important, principles or practices? Transcript Jade Meskill:  Hello welcome to …

The post Episode #138 – Principles or Practices appeared first on Episode #138 – Principles or Practices appeared first on Episode #137 – Central Control http://integrumtech.com/2014/05/episode-137-central-control/ http://integrumtech.com/2014/05/episode-137-central-control/#respond Thu, 08 May 2014 13:00:32 +0000 http://integrumtech.com/?p=7446 Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss: What happens when someone has central control Transcript Derek Neighbors:  Hello, and welcome …

The post Episode #137 – Central Control appeared first on Episode #137 – Central Control appeared first on Episode #136 – Simple http://integrumtech.com/2014/05/episode-136-simple/ http://integrumtech.com/2014/05/episode-136-simple/#respond Thu, 01 May 2014 13:00:24 +0000 http://integrumtech.com/?p=7444 Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss: Simplicity Transcript [laughter] Clayton Lengel‑Zigich:  It is hard doing that every week. [laughter] …

The post Episode #136 – Simple appeared first on Episode #136 – Simple appeared first on Episode #135 – Ticket Driven Agile http://integrumtech.com/2014/04/episode-135-ticket-driven-agile/ http://integrumtech.com/2014/04/episode-135-ticket-driven-agile/#respond Thu, 03 Apr 2014 13:00:23 +0000 http://integrumtech.com/?p=7438 Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Jake Plains discuss: Ticket Driven Agile Cross team collaboration Transcript Jade Meskill:  Hello. Welcome to another episode of …

The post Episode #135 – Ticket Driven Agile appeared first on Episode #135 – Ticket Driven Agile appeared first on Episode #134 – Cross Functional? http://integrumtech.com/2014/03/episode-134-cross-functional/ http://integrumtech.com/2014/03/episode-134-cross-functional/#respond Thu, 27 Mar 2014 13:00:50 +0000 http://integrumtech.com/?p=7436 Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Jake Plains discuss: How to get more cross functional How to overcome the challenges of working with very …

The post Episode #134 – Cross Functional? appeared first on Episode #134 – Cross Functional? appeared first on Episode #133 – Changing too fast or too slow http://integrumtech.com/2014/02/episode-133-changing-fast-slow/ http://integrumtech.com/2014/02/episode-133-changing-fast-slow/#respond Thu, 27 Feb 2014 13:00:36 +0000 http://integrumtech.com/?p=7433 Roy van de Water, Jade Meskill, and Clayton Lengel-Zigich discuss: What is the right pace for change in an organization Transcript Jade Meskill:  Hello, welcome …

The post Episode #133 – Changing too fast or too slow appeared first on Episode #133 – Changing too fast or too slow appeared first on Episode #132 – No Surprises! http://integrumtech.com/2014/02/episode-132-surprises/ http://integrumtech.com/2014/02/episode-132-surprises/#respond Thu, 13 Feb 2014 13:00:15 +0000 http://integrumtech.com/?p=7430 Roy van de Water, Jade Meskill, Clayton Lengel-Zigich, and Derek Neighbors discuss: No Surprises Transcript Jade Meskill:  Hello. Welcome to another episode of the Agile …

The post Episode #132 – No Surprises! appeared first on Episode #132 – No Surprises! appeared first on Episode #131 – Autonomy, autonomy, autonomy. http://integrumtech.com/2014/02/episode-131-autonomy-autonomy-autonomy/ http://integrumtech.com/2014/02/episode-131-autonomy-autonomy-autonomy/#respond Thu, 06 Feb 2014 13:00:12 +0000 http://integrumtech.com/?p=7427 Roy van de Water, Jade Meskill, and Derek Neighbors discuss: Autonomy Autonomy Even more autonomy Transcript Jade Meskill:  Hello, and welcome to the Agile Weekly …

The post Episode #131 – Autonomy, autonomy, autonomy. appeared first on Episode #131 – Autonomy, autonomy, autonomy. appeared first on Episode #130 – Roles, huh, yeah. What are they good for? http://integrumtech.com/2014/01/episode-130-roles-huh-yeah-good/ http://integrumtech.com/2014/01/episode-130-roles-huh-yeah-good/#respond Fri, 31 Jan 2014 13:00:07 +0000 http://integrumtech.com/?p=7424 Clayton Lengel-Zigich, Roy van de Water, Jade Meskill, Derek Neighbors and Alan Dayley discuss: Roles Collective Ownership Transcript Clayton Lengel‑Zigich:  Welcome to another episode of …

The post Episode #130 – Roles, huh, yeah. What are they good for? appeared first on Episode #130 – Roles, huh, yeah. What are they good for? appeared first on Instant BDD/TDD Feedback With BlinkyTape http://integrumtech.com/2014/01/instant-bdd-tdd-feedback-with-blinky-tape/ http://integrumtech.com/2014/01/instant-bdd-tdd-feedback-with-blinky-tape/#respond Sat, 11 Jan 2014 07:05:30 +0000 http://integrumtech.com/?p=7399 Roy and I were trying to figure out something cool to do with a Blink(1) when we had a great insight: What if we could …

The post Instant BDD/TDD Feedback With BlinkyTape appeared first on Roy and I were trying to figure out something cool to do with a Blink(1) when we had a great insight:

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.

ready

single_was_passing

failed_was_passing

passed_was_failing

all_was_failing

all_passed_was_failing

looks_great

The post Instant BDD/TDD Feedback With BlinkyTape appeared first on http://integrumtech.com/?p=7387 A little while back I was talking with one of our clients and happened to show him a copy of our company values.  He said, …

The post The Value of Values 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.

The post The Value of Values appeared first on http://integrumtech.com/?p=7382 Roy van de Water, Clayton Lengel-Zigich, and Jade Meskill discuss refactoring your Ask For Help to get better results.

The post Episode #129 – Ask For Help Refactoring appeared first on Episode #129 – Ask For Help Refactoring appeared first on Episode #128 – Smaller Teams http://integrumtech.com/2013/12/episode-128-smaller-teams/ http://integrumtech.com/2013/12/episode-128-smaller-teams/#respond Thu, 12 Dec 2013 13:00:16 +0000 http://integrumtech.com/?p=7377 Roy van de Water, Derek Neighbors, Clayton Lengel-Zigich, and Jade Meskill discuss the benefits of smaller teams.   Transcript Jade Meskill:  Hello, welcome to the …

The post Episode #128 – Smaller Teams appeared first on Episode #128 – Smaller Teams appeared first on Episode #127 – Do we need frameworks? http://integrumtech.com/2013/12/episode-127-need-frameworks-2/ http://integrumtech.com/2013/12/episode-127-need-frameworks-2/#respond Thu, 05 Dec 2013 13:00:30 +0000 http://integrumtech.com/?p=7375 Roy van de Water, Derek Neighbors, and Jade Meskill discuss the need for frameworks.   Transcript Jade Meskill:  Hello. Welcome to another episode of the …

The post Episode #127 – Do we need frameworks? appeared first on Episode #127 – Do we need frameworks? appeared first on Episode #126 – Prescriptive Coaching? http://integrumtech.com/2013/11/episode-126-prescriptive-coaching/ http://integrumtech.com/2013/11/episode-126-prescriptive-coaching/#respond Thu, 14 Nov 2013 13:00:36 +0000 http://integrumtech.com/?p=7365 Roy van de Water, Clayton Lengel-Zigich, and Jade Meskill discuss trying a different approach to get a high performing team. Transcript Jade Meskill:  Hello. Welcome …

The post Episode #126 – Prescriptive Coaching? appeared first on Episode #126 – Prescriptive Coaching? appeared first on Episode #125 – Being Lazy http://integrumtech.com/2013/11/episode-125-lazy/ http://integrumtech.com/2013/11/episode-125-lazy/#respond Thu, 07 Nov 2013 13:00:15 +0000 http://integrumtech.com/?p=7363 Roy van de Water, Clayton Lengel-Zigich, Derek Neighbors, and Jade Meskill discuss the benefits of laziness. Transcript   Clayton Lengel‑Zigich:  Welcome to another episode of …

The post Episode #125 – Being Lazy appeared first on Episode #125 – Being Lazy appeared first on Episode #124 – Automate it http://integrumtech.com/2013/10/episode-124-automate/ http://integrumtech.com/2013/10/episode-124-automate/#respond Thu, 24 Oct 2013 13:00:44 +0000 http://integrumtech.com/?p=7356 Clayton Lengel-Zigich, Roy van de Water, Derek Neighbors and Jade Meskill discuss why everything that can be automated, should be automated. Transcript Jade Meskill:  Hello. …

The post Episode #124 – Automate it appeared first on Episode #124 – Automate it appeared first on Episode #123 – Standards vs Innovation http://integrumtech.com/2013/10/episode-123-standards-vs-innovation/ http://integrumtech.com/2013/10/episode-123-standards-vs-innovation/#respond Thu, 10 Oct 2013 13:00:35 +0000 http://integrumtech.com/?p=7346 Roy van de Water, Clayton Lengel-Zigich, Derek Neighbors, and Jade Meskill discuss standardization and the effect it has on innovation. Jade Meskill: Welcome to the …

The post Episode #123 – Standards vs Innovation appeared first on Episode #123 – Standards vs Innovation appeared first on Episode #122 – Multitasking and Multiple Commitments http://integrumtech.com/2013/10/episode-122-multitasking-and-multiple-commitments/ http://integrumtech.com/2013/10/episode-122-multitasking-and-multiple-commitments/#respond Thu, 03 Oct 2013 13:00:12 +0000 http://integrumtech.com/?p=7338 Roy van de Water, Derek Neighbors and Jade Meskill discuss the danger of multitasking. [music] Jade Meskill: Hello, welcome to the “Agile Weekly Podcast”. I’m …

The post Episode #122 – Multitasking and Multiple Commitments appeared first on Episode #122 – Multitasking and Multiple Commitments appeared first on Episode #121 – Ask For Help http://integrumtech.com/2013/09/episode-121-ask-for-help/ http://integrumtech.com/2013/09/episode-121-ask-for-help/#respond Wed, 25 Sep 2013 13:00:49 +0000 http://integrumtech.com/?p=7333 Roy van de Water, Derek Neighbors and Jade Meskill discuss asking for help Why you should ask for help Rescuing people who won’t ask for …

The post Episode #121 – Ask For Help appeared first on Episode #121 – Ask For Help appeared first on Episode #120 – Presence over Planning http://integrumtech.com/2013/09/episode-120-presence-over-planning/ http://integrumtech.com/2013/09/episode-120-presence-over-planning/#respond Thu, 19 Sep 2013 13:00:25 +0000 http://integrumtech.com/?p=7335 Roy van de Water, Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Jim McCarthy discuss presence over planning.   Transcript Jade Meskill:  If only I knew… …

The post Episode #120 – Presence over Planning appeared first on Episode #120 – Presence over Planning appeared first on Episode #119 – Slowing Things Down http://integrumtech.com/2013/09/episode-119-slowing-things-down/ http://integrumtech.com/2013/09/episode-119-slowing-things-down/#respond Thu, 05 Sep 2013 13:00:14 +0000 http://integrumtech.com/?p=7320 Roy van de Water, Jade Meskill, and Derek Neighbors discuss: How to deal with people who want to slow things down. Transcript Jade Meskill:  Hello, …

The post Episode #119 – Slowing Things Down appeared first on Episode #119 – Slowing Things Down appeared first on Episode #118 – Having Fun at Work http://integrumtech.com/2013/08/episode-118-having-fun-at-work/ http://integrumtech.com/2013/08/episode-118-having-fun-at-work/#respond Thu, 29 Aug 2013 13:00:15 +0000 http://integrumtech.com/?p=7315 Roy van de Water, Clayton Lengel-Zigich and David Foster discuss: Can you have fun at work? What if your org. culture doesn’t support fun? How …

The post Episode #118 – Having Fun at Work appeared first on Episode #118 – Having Fun at Work appeared first on Episode #117 – Product Owner as the Customer http://integrumtech.com/2013/08/episode-117-product-owner-as-the-customer/ http://integrumtech.com/2013/08/episode-117-product-owner-as-the-customer/#respond Wed, 21 Aug 2013 13:00:24 +0000 http://integrumtech.com/?p=7311 Roy van de Water, Clayton Lengel-Zigich and Derek Neighbors discuss: A common pattern of teams with many masters. The Product Owner as the Customer and …

The post Episode #117 – Product Owner as the Customer appeared first on Episode #117 – Product Owner as the Customer appeared first on Episode #116 – What ever happened to XP? http://integrumtech.com/2013/08/episode-116-what-ever-happened-to-xp/ http://integrumtech.com/2013/08/episode-116-what-ever-happened-to-xp/#respond Thu, 08 Aug 2013 13:00:42 +0000 http://integrumtech.com/?p=7308 Roy van de Water, Jade Meskill, and Derek Neighbors discuss: What happened to eXtreme Programming? Vacation Transcript Jade Meskill:  Hello, and welcome to another episode …

The post Episode #116 – What ever happened to XP? appeared first on Episode #116 – What ever happened to XP? appeared first on Episode #115 – Commitment Considered Harmful? http://integrumtech.com/2013/07/episode-115/ http://integrumtech.com/2013/07/episode-115/#respond Thu, 25 Jul 2013 13:00:04 +0000 http://integrumtech.com/?p=7303 Roy van de Water, Clayton Lengel-Zigich, Derek Neighbors and Jade Meskill discuss an article that was published on Agile Weekly this week: Commitment Considered Harmful …

The post Episode #115 – Commitment Considered Harmful? appeared first on Agile Weekly this week: Commitment Considered Harmful

 

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 http://integrumtech.com/2013/07/episode-114-sprint-failure/ http://integrumtech.com/2013/07/episode-114-sprint-failure/#respond Thu, 11 Jul 2013 13:00:37 +0000 http://integrumtech.com/?p=7296 Roy van de Water and Clayton Lengel-Zigich discuss: What is a failed sprint? How should the team react? What should the team demo? What should …

The post Episode #114 – Sprint Failure appeared first on Episode #114 – Sprint Failure appeared first on Episode #113 – High Costs and Negative Value of Pair Programming http://integrumtech.com/2013/07/episode-113-high-costs-and-negative-value-of-pair-programming/ http://integrumtech.com/2013/07/episode-113-high-costs-and-negative-value-of-pair-programming/#respond Thu, 04 Jul 2013 13:00:42 +0000 http://integrumtech.com/?p=7293 Roy van de Water and Clayton Lengel-Zigich provide a rebuttal to an article that has been circulating within the Agile community this week: High Costs …

The post Episode #113 – High Costs and Negative Value of Pair Programming 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 Episode #112 – 7 Agile Best Practices that You Don’t Need to Follow http://integrumtech.com/2013/06/episode-112-7-agile-best-practices-that-you-dont-need-to-follow/ http://integrumtech.com/2013/06/episode-112-7-agile-best-practices-that-you-dont-need-to-follow/#respond Thu, 20 Jun 2013 13:00:48 +0000 http://integrumtech.com/?p=7287 Roy van de Water, Derek Neighbors and Clayton Lengel-Zigich discuss an article that has been making the rounds in the Agile community this week: 7 …

The post Episode #112 – 7 Agile Best Practices that You Don’t Need to Follow 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 Stair Step Burndown http://integrumtech.com/2013/06/stair-step-burndown/ http://integrumtech.com/2013/06/stair-step-burndown/#respond Thu, 20 Jun 2013 11:00:45 +0000 http://integrumtech.com/?p=7274 Problem Most burndown charts look like this: However, teams frequently don’t actually burn down this steadily. Often team members know on planning day that they …

The post Stair Step Burndown appeared first on straight-line-burndown

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

  1. Get the team’s capacity by day.
  2. Draw a horizontal line on each day of the sprint, indicating how much of the team’s capacity is left in the sprint.
  3. 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:

straight-line-example

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:

stair-step-example

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 http://integrumtech.com/?p=7255 Roy van de Water, Derek Neighbors and Clayton Lengel-Zigich discuss: Does money work? What if developers don’t realize they need to grow? Should developers choose …

The post Episode #111 – Inspiring Personal Growth in Agile Teams appeared first on Episode #111 – Inspiring Personal Growth in Agile Teams appeared first on Interruption Balloons http://integrumtech.com/2013/06/interruption-balloons/ http://integrumtech.com/2013/06/interruption-balloons/#comments Thu, 13 Jun 2013 03:50:55 +0000 http://integrumtech.com/?p=7257 Problem The team complains that they are not able to get close to commiting to their capacity because they are constantly being interrupted. Nobody in …

The post Interruption Balloons appeared first on red-balloons

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 http://integrumtech.com/?p=7241 Problem One of the first complaints of going to Scrum is the huge amount of overhead. The effort and time it takes to plan, task, …

The post One Hour Iterations appeared first on One Hour Iterations appeared first on http://integrumtech.com/?p=7203 Problem   It’s the end of the sprint. The team committed to half their capacity but somehow still failed to hit their sprint. During the …

The post Extreme Timeboxing 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

 

  1. 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.
  2. Each pair grabs a task card off the wall
  3. Each sets a timer (almost all phones have them) for the length of the timebox.
  4. The pair starts working, letting the timer do its thing.
  5. 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.
  6. Reset the timer and continue with the task.
  7. When the pair is done with the task, fill in the remaining time left on the original estimate
    in green boxes on the task.
  8. 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.

The post Extreme Timeboxing appeared first on http://integrumtech.com/?p=7238 Roy van de Water, Clayton Lengel-Zigich, Jade Meskill and David Foster discuss: What’s a senior developer? Software developer job bands Compensation based on performance Transcript …

The post Episode #110 – What’s a Senior Developer appeared first on Episode #110 – What’s a Senior Developer appeared first on Episode #109 – Revisiting Decisions http://integrumtech.com/2013/05/episode-109-revisiting-decisions/ http://integrumtech.com/2013/05/episode-109-revisiting-decisions/#respond Thu, 16 May 2013 13:00:44 +0000 http://integrumtech.com/?p=7200 Roy van de Water and Clayton Lengel-Zigich discuss: Why teams revisit situations Disclosing what you know Decider Protocol Transcript Clayton Lengel-Zigich:  Welcome to another episode …

The post Episode #109 – Revisiting Decisions appeared first on Episode #109 – Revisiting Decisions appeared first on Episode #108 – Imperfect Situations http://integrumtech.com/2013/05/episode-108-imperfect-situations/ http://integrumtech.com/2013/05/episode-108-imperfect-situations/#respond Thu, 09 May 2013 13:00:33 +0000 http://integrumtech.com/?p=7197 Jade Meskill, Roy van de Water, Derek Neighbors and Clayton Lengel-Zigich discuss: When Facilities won’t help When Developers can’t set up their environments When continuous …

The post Episode #108 – Imperfect Situations appeared first on Episode #108 – Imperfect Situations appeared first on Episode #107 – Is Agile Faster? http://integrumtech.com/2013/04/episode-107-is-agile-faster/ http://integrumtech.com/2013/04/episode-107-is-agile-faster/#respond Fri, 26 Apr 2013 13:00:04 +0000 http://integrumtech.com/?p=7192 Jade Meskill, Roy van de Water, Derek Neighbors and special guest Alan Dayley discuss: If agile faster What it means to be better Transcript Roy …

The post Episode #107 – Is Agile Faster? appeared first on Episode #107 – Is Agile Faster? appeared first on Episode #106 – Lean Startup http://integrumtech.com/2013/04/episode-106-lean-startup/ http://integrumtech.com/2013/04/episode-106-lean-startup/#respond Thu, 18 Apr 2013 13:00:19 +0000 http://integrumtech.com/?p=7190 Roy van de Water, Jade Meskill, Derek Neighbors, Clayton Lengel-Zigich and Mike Vizdos discuss: Lean Startup in the enterprise. Vanity metrics LeanPub Mike’s Childrens Book …

The post Episode #106 – Lean Startup appeared first on Episode #106 – Lean Startup appeared first on Episode #105 – Delivering News and Doing the Right Thing http://integrumtech.com/2013/04/episode-105-delivering-news-and-doing-the-right-thing-2/ http://integrumtech.com/2013/04/episode-105-delivering-news-and-doing-the-right-thing-2/#respond Thu, 11 Apr 2013 13:00:37 +0000 http://integrumtech.com/?p=7188 Jade Meskill, Roy van de Water and Derek Neighbors discuss: How to deliver news How to help your team if they know they’re doing the …

The post Episode #105 – Delivering News and Doing the Right Thing appeared first on Episode #105 – Delivering News and Doing the Right Thing appeared first on Episode #104 – Executives, Rewrites and Information Radiators http://integrumtech.com/2013/04/episode-104-executives-rewrites-and-information-radiators-2/ http://integrumtech.com/2013/04/episode-104-executives-rewrites-and-information-radiators-2/#respond Thu, 04 Apr 2013 13:00:28 +0000 http://integrumtech.com/?p=7184 Roy van de Water, Clayton Lengel-Zigich, and Derek Neighbors discuss: Executives in Agile The Big Rewrite Ignoring information Radiators Transcript Clayton Lengel‑Zigich:  Welcome to another …

The post Episode #104 – Executives, Rewrites and Information Radiators appeared first on Episode #104 – Executives, Rewrites and Information Radiators appeared first on Episode #103 – Let’s Define Value http://integrumtech.com/2013/03/episode-103-lets-define-value/ http://integrumtech.com/2013/03/episode-103-lets-define-value/#respond Thu, 28 Mar 2013 13:00:48 +0000 http://integrumtech.com/?p=7177 Roy van de Water, Jade Meskill, Derek Neighbors and Clayton Lengel-Zigich discuss: The emperor has no value. What is value? Different types of value Transcript …

The post Episode #103 – Let’s Define Value appeared first on Episode #103 – Let’s Define Value appeared first on Episode #102 – Agile Metrics and Organization Debt http://integrumtech.com/2013/03/episode-102-agile-metrics-and-organization-debt/ http://integrumtech.com/2013/03/episode-102-agile-metrics-and-organization-debt/#respond Thu, 21 Mar 2013 13:00:31 +0000 http://integrumtech.com/?p=7172 Roy van de Water, Jade Meskill, Derek Neighbors and Clayton Lengel-Zigich discuss: Agile Metrics Releasing Often Organizational Debt Transcript Clayton Lengel‑Zigich:  Welcome to another episode …

The post Episode #102 – Agile Metrics and Organization Debt appeared first on Episode #102 – Agile Metrics and Organization Debt appeared first on Episode #101 – Working Agreements http://integrumtech.com/2013/03/episode-101-working-agreements/ http://integrumtech.com/2013/03/episode-101-working-agreements/#respond Thu, 14 Mar 2013 13:00:46 +0000 http://integrumtech.com/?p=7170 Roy van de Water, Jade Meskill, Derek Neighbors and Clayton Lengel-Zigich discuss: Confusing Working Agreements Working Agreements as Policies Values and Principles over Working Agreements …

The post Episode #101 – Working Agreements appeared first on Episode #101 – Working Agreements appeared first on Episode #100 – Failure, Learning and Fun http://integrumtech.com/2013/03/episode-100-failure-learning-and-fun/ http://integrumtech.com/2013/03/episode-100-failure-learning-and-fun/#respond Thu, 07 Mar 2013 13:00:57 +0000 http://integrumtech.com/?p=7165 Roy van de Water and Clayton Lengel-Zigich discuss: A Culture of Learning Fear of Failing Having too much fun? Transcript Clayton Lengel‑Zigich:  Welcome to another …

The post Episode #100 – Failure, Learning and Fun appeared first on Episode #100 – Failure, Learning and Fun appeared first on Episode #99 – Working From Home? http://integrumtech.com/2013/02/episode-99-working-from-home/ http://integrumtech.com/2013/02/episode-99-working-from-home/#respond Thu, 28 Feb 2013 13:00:56 +0000 http://integrumtech.com/?p=7163 Jade Meskill, Clayton Lengel-Zigich, Roy van de Water and Derek Neighbors discuss: Technical Scrum Masters Team Workspaces Working from Home Transcript Jade:  Hello, and welcome …

The post Episode #99 – Working From Home? appeared first on Episode #99 – Working From Home? appeared first on Episode #98 – Storming Teams http://integrumtech.com/2013/02/episode-98-storming-teams/ http://integrumtech.com/2013/02/episode-98-storming-teams/#respond Thu, 21 Feb 2013 13:00:13 +0000 http://integrumtech.com/?p=7155 Clayton Lengel-Zigich, Roy van de Water and Derek Neighbors discuss: Team Culture Alpha Developers Retrospective Safety Transcript Clayton Lengel‑Zigich:  Welcome to another episode of the …

The post Episode #98 – Storming Teams appeared first on Episode #98 – Storming Teams appeared first on Episode #97 – Product Owners, INVEST, Continuous Delivery http://integrumtech.com/2013/02/episode-97-product-owners-invest-continuous-delivery/ http://integrumtech.com/2013/02/episode-97-product-owners-invest-continuous-delivery/#respond Thu, 14 Feb 2013 13:00:05 +0000 http://integrumtech.com/?p=7150 Clayton Lengel-Zigich, Roy van de Water and Derek Neighbors discuss: Product Owner Availability Delivering Value Continuous Delivery vs Deployment Backlog Gardening Transcript Clayton Lengel‑Zigich:  Welcome …

The post Episode #97 – Product Owners, INVEST, Continuous Delivery appeared first on Episode #97 – Product Owners, INVEST, Continuous Delivery appeared first on Episode #96 – A Backlog of Topics http://integrumtech.com/2013/01/episode-96-a-backlog-of-topics/ http://integrumtech.com/2013/01/episode-96-a-backlog-of-topics/#respond Thu, 31 Jan 2013 13:00:59 +0000 http://integrumtech.com/?p=7128 Clayton Lengel-Zigich, Roy van de Water and Derek Neighbors discuss: Sprint Zero Working Agreements Performance Testing Backlog Gardening Transcript Clayton Lengel‑Zigich:  Welcome to another episode …

The post Episode #96 – A Backlog of Topics appeared first on Episode #96 – A Backlog of Topics appeared first on Episode #95 – Moving to a Team Room http://integrumtech.com/2013/01/episode-95-moving-to-a-team-room/ http://integrumtech.com/2013/01/episode-95-moving-to-a-team-room/#respond Thu, 24 Jan 2013 13:00:10 +0000 http://integrumtech.com/?p=7119 Clayton Lengel-Zigich, Roy van de Water, Isaac, Deepa and Ryan discuss: Moving from cubes to team rooms Collaboration Self-Organizing teams Update: We found a problem …

The post Episode #95 – Moving to a Team Room appeared first on Episode #95 – Moving to a Team Room appeared first on Episode #94 – Agile Design and UX http://integrumtech.com/2013/01/episode-94-agile-design-and-ux/ http://integrumtech.com/2013/01/episode-94-agile-design-and-ux/#comments Thu, 17 Jan 2013 13:00:22 +0000 http://integrumtech.com/?p=7114 Clayton Lengel-Zigich, Jade Meskill and Kevin Goldman of 29th Drive discuss: Agile in Design Pen Sketching Ideation and collaboration Transcript Clayton Lengel‑Zigich:  Welcome to another …

The post Episode #94 – Agile Design and UX appeared first on Kevin Goldman of 29th Drive discuss:

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

The post Episode #94 – Agile Design and UX appeared first on Episode #93 – Education and Agile with John Miller http://integrumtech.com/2013/01/episode-93-agile-education-john-miller/ http://integrumtech.com/2013/01/episode-93-agile-education-john-miller/#respond Thu, 10 Jan 2013 13:00:16 +0000 http://integrumtech.com/?p=7109 Clayton Lengel-Zigich, Jade Meskill, John Miller and Roy van de Water discuss: Agile in Education Scrum in the classroom How software developers are like pre-k …

The post Episode #93 – Education and Agile with John Miller appeared first on Episode #93 – Education and Agile with John Miller appeared first on Episode #92 – Hiring For Agile Teams http://integrumtech.com/2012/12/episode-94-hiring-for-agile-teams/ http://integrumtech.com/2012/12/episode-94-hiring-for-agile-teams/#respond Th