Webinar: What to do after you’ve learned agile practices

Gary TuohyCommunity, Tech Stuff1 Comment

post agile webinar


Raygun Educational Series - Post Agile banner

Raygun’s Educational Series – Interviewing Jason Thane from General UI on his post agile experience.

Welcome to Raygun’s Education Series.

Every month Raygun aims to give you actionable insights into producing even better quality software using the latest tools and methods.


Post Agile Practices - JD and Jason Thane profile pictures



In this free webinar, Raygun’s co founder John-Daniel Trask hosts a conversation with General UI’s CEO Jason Thane and Director of Developments Kevin Klinemeier on how implementing post agile practices have taken their team to smoother, more efficient production, saving both time and money – especially in production.

Post agile is when your team has a set of agile tools and knows exactly when to use them…and when not to

Jason Thane – CEO of General UI

Even though agile practices are the most implemented management frameworks in software companies, many still struggle to grow them into an adaptable framework. And it can be tough finding the right balance between tools and systems for your team.

Luckily for us, Jason goes into detail about which systems General UI use to consistently produce great quality software for thousands of customers every year.

Inside this webinar, you’ll learn:

  • How General UI makes consistently great quality software with their post agile practices
  • How implementing post agile practices significantly improved General UI’s output quality and how you can do the same (whilst also keeping your team happy)
  • When sprints aren’t necessarily the most efficient practice for all teams
  • Which tools General UI uses to schedule and prioritise workers
  • Why the quality of the software lies in the quality of the team (and what Aristotle has to say about team dynamics)
  • How to sell peer programming to management and your clients


Watch the full webinar here:



Listen on Soundcloud:

Resource list from the webinar:


Did you enjoy this webinar? Get notified on our next webinar in the Education Series:


Full Transcription:

John-Daniel: Cool. Hi, everybody. I’m John-Daniel Trask. The co-founder and CEO of Raygun. And I’d like to welcome you to our first Raygun Education Series webinar. I’m here with Jason and Kevin, from General UI.

Kevin: Hello.

John-Daniel: And they’re friends of ours, here, in Seattle. So I met Jason, probably, what? A few months back, now. Because I’ve been expanding from Seattle, down to Australia. We’re headquartered in New Zealand. And we’re expanding into Seattle. So we’ve been spending some time together.

I had the opportunity to tour Jason’s office, here. And see some of the great work they’re doing and how they’re running their agile practice. It got me thinking that I think they’re doing some really interesting stuff. And that some of our customers might find it really interesting to learn from.

So today’s format is going to be a conversation between Jason and Kevin, talking about what’s going on. If you have any questions, please write them in the sidebar. You might hear me yell them out in the background, to the guys. But, otherwise, please enjoy. We’ll try to keep this to 30-minutes. But we might go over a little bit if there’s a lot of questions. Thank you very much.

Jason: Thank you, JD. So I’m Jason Thane. I’m the founder and CEO of General UI. This is Kevin Klinemeier. He’s our Director of Developments.

And, we’re here to talk about maybe a controversial term: post agile. And that’s not to say that we’ve thrown agile out with the bathwater. But rather that we want to talk about what to do, and how to do it, and why to do these things after you’ve learned to be agile. And when I say “agile,” I mean agile, as an adjective, rather than Agile — a proper noun. And that distinction is important because we find that a lot of our clients and a lot of different development teams that we encounter through our work, as they start to learn agile, they see it as a set of rituals. They see it as a cult-like practice with very strict and regimented rules that they have to implement and follow to the letter. And it becomes very ritualistic.

And there’s a story I like to tell, as a metaphor for this. And that’s that after World War II, there were islands that the U.S. had built airstrips. And on these islands, there were natives who were amazed at all of the goods coming in from the Westernized world during the war. They would see planes land, and they would see cargo come out. And the cargo would have amazing wonderful technological marvels that it’d never had seen before.

And then the war ended. And planes stopped coming. But the airstrips were still there. So the natives actually panicked. And they said, “Well we’ve got to get this good stuff back. What are we going to do?”

So they actually would organize a cult around trying to summon the planes back. And so they would build a tower out of bamboo sticks and put on coconut headphones and wave batons like this, hoping for the planes to arrive. But, in fact, the planes never did. And that’s because those rituals were practiced without any real understanding of what an airplane is, or where it comes from, or why?

And so we think that agile can be practiced like that. So that some people are following the motions of [inaudible 00:03:53] retrospectives through strange things, like planning poker. There are all sorts of rituals that have been created around agile and given various names, for better or for worst. And the fact is that those rituals are worthless if you don’t understand why they exist, and if you don’t really understand how to use them.

So what we want to talk about today is where we are in our pursuits of “agile,” as an adjective. And some of the tools that we’ve implemented. Rather than seeing the practices as rituals, we see them as tools. And every tool is an optimization. So every tool is appropriate for certain situations and circumstances. And wildly inappropriate for other situations and circumstances. Is that a fair introduction, Kevin?

Kevin: Yeah, it seemed spot on.

Jason: Kevin is actually our…he’s far more advanced in all these things than I am. If I’m not saying anything that greatly steps in with Kevin, I’ll be happy about that. So you can give me feedback.

So Kevin, what would you say our current state of agile practice is, at General UI? What are we optimized for? What are we not optimized for? And how are things going?

Kevin: Some of the values that the team has is, don’t create towers of knowledge. That’s one of the first things that we talk about. As a consultancy, we work on a lot of different projects, and we talk to our customers about not getting in the situation where you can’t get progress on your project because the one person who knows about it is out sick or happens to be on another project while you wanted to restart it.

And so that need for communication, so you don’t have a single person who has that information, drives a lot of our practices. And that drives our pair programming that you see…that, if you come to our office, you’ll see that happening a lot. I make sure that at least two people know what’s happening and that drives our practices around rotating pairs. So you don’t pair with the same person everyday, and sharers those practices.

And that has a lot of other additional benefits then, which is that when you’re pairing with someone. You share, not only project knowledge, but engineering practices. And so there’s a lot of things that I’ll hear people talking about on the team that they really like this new testing tool, or just this programming technique. And you can watch spread kind of virally around the team. Of, if Drew was the one who came up with it, then the people who paired with Drew this week know about it. And they’re sharing it with the next people, and the next people, and the next people. That ends up being really efficient from a communication point of view, because you get to see it in real code. And I don’t have to stop the team and call a 30-minute presentation on whatever this thing is. It just happens, it get’s shared as a result of people showing up to work and getting things done.

Jason: So pairing, as an agile practice, as a development team practice. What is that an optimization for? And what is it an optimization not for?

Kevin: Yeah. Yeah. Knowledge sharing equality are definitely the things that it optimizes. You’ve got two people looking at code, talked about knowledge sharing within quality.

I’ll tell you the way that I came to peer-programming. A long time ago I worked this guy. And he wanted me to try it, and I was adamant against it. I thought it was the worst ideas ever. And I don’t know…this is Matt, by the way, who you know well.

Jason: Works for General UI.

Kevin: And I knew him from college. And he studied Electrical Engineering, while I studied the higher art of Computer Science, right? So he comes to me and says, “I think we should do this peer-programming thing.”

And I said to him…I’m not at all proud of this. I’m so fortunate he’s still my friend. I said, “Well, if you need some help with your programming, I’ll help you out. But I don’t think I need [inaudible 00:08:14].” And he says, “Okay. Yeah. Sure. Let’s try it out.”

And the other part that was interesting in that scientific experiment around peer-programming is, in that environment, we were working with 100% code review. So every line of code that we wrote had to go to a code review that was fairly formalized. It wasn’t like, “I’ll stamp your code. You stamp mine,” kind of thing.

It was, “Let’s have four or five people who are required to have some kind of comment and get together and review that code.” And I didn’t hate it everyday. I definitely had some problems. I could see…this is my second job out of college at that point. I could see that it was definitely improving the quality of my code. But, gosh, it was taking a long time to get anything done with that code review process. And a lot of it was eye roll stuff of, “You’re over the 40-character limit, here.” And people obviously trying to find something to say so that they could say that they said something.

But then, the other thing that was almost more frustrating than that was, this was stuff that I could’ve come with, too, if I’d spend another 45-minutes or an hour, looking at the same bit of code that was functional and complete.

And then, when I left code review, I left with all these changes for code that works. That is totally, except for these design changes, production ready. And code that I’ve spent three or four days building on before I got these changes. 90% of the time, that stuff went nowhere. Those were nice recommendations that I’d try to keep in mind for next time. And it just didn’t happen.

So now I started peer-programming. And the thing that was stark was, while this is a whole other skill, when we had to figure out how to work with each other and how to communicate again, even though we’d known each other a long time. But then, once we got into the groove of it, I really see the benefits when we got to code review. Because then, when we got to code review, we had, for the first time ever, the team said, “I don’t know. This looks pretty good. This is all really solid.” And we had time to put that quality into the code because we didn’t build anything on top of it. And it was easy for one person…and this is just classic pairing. But that’s we saw. One person would be thinking about, where do the curly braces and semicolons go? And the other person, [inaudible 00:10:41] thinking about, “What are the things we’re always hearing in code review?” Or, with the Gang of Four book open, or whatever those higher design qualities…

Jason: Yeah. I do a lot of explaining to clients, why we pair, and why it’s important to pair, and why it’s more efficient, why it’s a better use of their money?

And some of them might liken it to and have compared to, when you pass a construction job site and you see three guys digging a whole. One guy digging. And then other two leaning on their shovel.

And, actually, that’s not a bad comparison, because there is a form of intellectual rest that happens when you’re the navigator, rather than the driver. So in pair, on person’s the driver. They’re ready to cap in the keys. The other person is the navigator.

It turns out that being the driver, you actually have to devote a fair amount of your computing resources and your own brain to just getting the code to the pilot, person with the keys, and, formatting things nicely. And you can use what’s left of your ability to think about the design, the architecture, of user experience. You can think about quality testability, test during development. You can think about aesthetic. There are all these other things that you can and should be doing to make the product better. But it’s really a rare person, and usually somebody who is so automatic with software development for multiple decades that they can think those higher levels while they’re working at the lower level of the code.

So pairing actually allows a whole another brain to sit there and think about those other things. Some of those are high-level. Like I mentioned, that static, and design, and architecture, and user experience.

Other things are a little more pragmatic. For example, edge cases. Did you think about what happens when this function’s passed the null? What are the tests you should be writing to document some behavior of the application if certain inputs are received? And so, and that manifests itself in an even more concrete way, which is that a lot of minor bugs are fixed in-line, in the pair, instead of getting checked into a repository. Where, later, they’ll be compiled, and built, and deployed, and found by somebody. Then, documented. Entered in a bug tracker, then prioritized, then fixed, then verified, then built, then deployed again. And it’s an extremely inefficient process. And…

John-Daniel: I have a product that will help you with the, Jason.

Jason: Okay. You have to have Raygun. Well, we really find pairing is an incredible [inaudible 00:13:30] to that. Some projects that all developer, I think, have experienced, will have a very long bug tail when you get to the end. You’ll find that that bug tail is much, much shorter when you’re working in pairs because those were fixed in-line.

That’s one of the key benefits. So a lot of the pain of software project management is involved in having a bug open rate that is high. And you end up trying to determine when it’s going to [inaudible 00:14:06] approach to zero. And maybe, it’s very to quantify it. So pairing reduces and removes a lot of the risk from the product management side.

So that’s one optimization that we have found to be fairly relevant to our customers. Now, it’s not relevant for all of our customers. We are using it on most customers, right now. But, not all. And like any agile practice. It would be inappropriate to say that one size fits all. If there was one size that fit all, that would be the way that everybody did it. And there would be complete agreement. But what we see is there is no agreement on exactly which type of agile works.

And the reason is that all agile practices are optimizations. So the reason that we call our ourselves, and we call this talk post-agile, is that we want to talk about not learning the tools of agile. Learning how to have a strong process or [inaudible 00:15:05] process, do extreme programming.

We want to say, “Once you’ve learned how to do those things. And more fundamentally you’ve learned why to do those things. Then you can go practice.” And when you go practice, you…and not just you, as an individual. I mean you, your team, can choose the optimizations that are going to work best for the situation. And that situation, that’s a nice environment that involves your customer, your user, who’s paying the bills? Your management structure, the culture of your organization. All of those factors are very important inputs to a development team that’s aware and constantly choosing to apply the best agile practices and optimizations to their develop path. So that’s why post-agile.

It’s not that we’re tossing out agile. We’re just saying, it’s not a magic recipe for success. Instead, there are tools that you have to use wisely. And you really have to use them with full awareness of why they exist.

John-Daniel: Would you say there’s any [inaudible 00:16:16] at all that will never work? The reverse of the silver bullet, if you will?

Jason: We have moved away from a regimented [inaudible 00:16:34] process. We’ve taken ideas from [inaudible 00:16:30] and we apply them. But, really, those are all [inaudible 00:16:44].

For a company like ours, spirits are an optimization that don’t work well. And the reason for that is resource allocation. We’re a consultancy that we serve 10 clients at a time. And so, if we have sprints it’s very hard to allocate resources properly because the ends of saints would never add up to each other. And you can’t get all clients into a single consistent sprint cycle of…it would be really nice. We tried it but we weren’t able to do it. And so sprints are a perfect example of an optimization that’s very great for some people. If you’re working in a monolithic organization or you have one product team. Maybe you have multiple, but you only have to worry about the resource assignments for that one team, over a certain period of time.

Kevin: Or, if you have some legitimate external factor that’s forcing you into a cadence. So when I started, I did [inaudible 00:17:38]. And the legitimate external factor was releases were a freaking nightmare that took four-days to do. And we did not want to do them very often. And we couldn’t…we had all these moving parts. And so that forced us into some kind of a cadence, which we worked hard to get down to two weeks, instead of two months.

But then, the progression of agile is, “Okay, learn what continuous integration is. Learn what DevOps is, and the automation of that experience.” And it made the pain of that inability to do frequent releases visible. And then we addressed it. And we no longer had that external schedule.

In some consulting that I did, before coming to General UI, I worked with clients that had other external cadences that they had to meet. Like, they had a very large credit card processor that they work with, that I’m sure you’re carrying in your wallet. And they had, for legal reasons, which probably is reasons people I’m talking to don’t know. But, regardless, it’s not changeable so it may as well be set in stone. But they can only do releases on a certain period, because they were contractually required to give the other team some time to respond to those. Now, whether you think that’s a good plan or not, it was the situation they were in, tailor-made for sprints. It made sense.

Jason: So instead of sprints, we talk about work in progress, eliminating work in progress and measuring our progress. That’s more of the [inaudible 00:19:10] style. It’s not to say that we’ve implemented an orthodox [inaudible 00:19:14] process, either. We’ve taken some things that work from that process.

A great way to explain it, and everybody’s familiar with Stand-up, right? Stand-up is an Agile practice. It’s a tool for teams. And a Stand-up is useful for a team that’s communicating. If you have a team that’s not talking and you have a Stand-up, daily. And people talk about what they did yesterday. And they talk about what they’re going to do today. And you limit it in scope, and time, and you actually stand up. These are all Agile practices.

That can be a boon to a team who wasn’t communicating. That team, once they are communicating, and once they’ve gelled, might not need to have Stand-ups anymore. In fact, the Stand-ups could become something that they elect to have or not have. I think most of our teams have Stand-ups, now. But we have had some teams that don’t. And that’s okay.

Once you have a team that’s really self-organizing, and self-aware, and able to optimize itself, they can make those choices. And we don’t…from top down we don’t say that they have to do things one way or another. Just as long as we’ve developed that trust.

Just, sticking to our agenda, what are some of the other team practices that we use. So we talked about some limiting work in progress with, kind of on stuff. We do a lot of test during development. That’s a very important fundamental value that we have. That test during development is not an optimization that’s applicable to all circumstances either.

If you’re building a throwaway demo, it might not be a wise investment of funds to TDD get it. However, if you’re building something that you want to last for any amount of time. Or, even the demo that could turn into a product, you should probably TDD this. Then, it can tolerate change, and it will be a sustainable product.

Another optimization, this is one that I like to pick on a lot. Is, open communicating and pairing, versus what we call caveman programming. So I think the default mode…actually, this is not true.

If you look at computer science students, there will be a lot of caveman programmers that go work on their assignments, and then turn them in. And then, we see a lot pairing happening. And pairing happening typically is because two guys are friends, or two girls are friends…not to make it gender-biased. But one of them will be mentoring the other one along. And you end up end sharing a lot of knowledge in that pair. And that’s how a lot of computer science students work, and a lot of computer labs. And maybe that was originally because computer were expensive and we didn’t have enough of them, but we’re organized around pairs. But, I think, it’s more fundamental than that.

I think that actually pairing is a very natural state of human beings to work together. When we pair, we communicate with our voice boxes and we use the verbal circuitry in our brains to solve problems. And people are built to solve problems by talking [inaudible 00:22:33] when they’re parenting. That’s what I do with my business partner, Jason Greer. We make decisions by talking about the problems that we’re solving. And I really think that the optimization, or the practice that’s a little less natural is the caveman programmer.

Caveman programmer is the guy who says, “Okay, I’ve got it. I’ve got the idea in my head. I’m going to go into my cave and I’ll come back next week and it’s going to be done. It’s going to be perfect.”

Well, typically what we see when that happens is a few things. One, what they come out with is different, than what they said it was going to be when they were going in. Or, different in our understanding of it, because the communication of the idea was not perfect. It’s not perfectly…it’s sort of opaque.

Another this is, maybe they just don’t come out at all. We never see them again. But I think, very notably, when the software development is disconnected from the world around it, it tends to grow in directions that it probably shouldn’t. Software is a very complex thing. And it has a complex integration surface with the world around it. And the process of getting that integration surface right, is the process of software development. And you have to communicate. Software itself is an active communication. And if it’s communication that’s tide and connected to the outside world, it’s far more superior to communication that’s just between one person and the computer.

So what improvements have we seen from these? I think it’s been really tremendous. In orienting our teams and our culture around communication and making high-bandwidth, high-integrity communication. The team value, we’ve seen all sorts of benefits. Not just the quality of the outputs satisfaction requirements, which is the most important metric. But, the trust shared within our teams.

So if you pair with people all day long, you learn to love them, except when you don’t. And when you don’t, and when people don’t get along, from a management perspective, we find out quickly and we know right away when teams don’t gel. And we can solve those problems. One, maybe we can make reassignments so that people that aren’t getting along don’t have to sit together all day. But when you’re sitting next to somebody and really communicating all the time, you tend to get pretty into it with your coworkers. And that’s a source of trust, which becomes a source of integrity in the product.

Kevin: And it leads to the ability to disagree usefully. And that’s something that comes up a lot. That there more than one flavor of ice cream in the world, right? Not every question has a single answer. And people can disagree. And the best conversations…I saw this transition over the last several months. Is, the best conversations are when we end with a solution and nobody knows whose solution it was, because it was just everybody’s.

We’re not talking about my answer or Jake versus Jason’s answer. And there’s this kind of thing, “Well, let’s take it out back. We’ll work it out.” We’re talking about pros and cons, and I come up with pros for what was originally not my idea. And it morphs into this third thing that is better than either solution. And we’ve got an answer. That’s really powerful. It’s also really when people have the respect of their peers. And to say, “I understand. And I can see that the group that has agreed, we’re going to get together and make this solution that’s not going my way, and I want out. I still don’t agree,” because I’m the engineer, right? “My opinion is not changed but I’ll go along with the group and I will build it in the way that we, as a group have agreed to do it. Not the way that I would build it. But that’s what we said.” And that’s pretty powerful. To be able to go along with the people that you respect, that you disagreed with. But you can see that that’s where the consensus is headed.

Jason: Yeah. We believe that team equals software. The quality of the software is the quality of the team. And specifically, of the integrity and bandwidth, and the communication of the team, which is why [inaudible 00:27:19], right? Because some people have optimized those incorrectly and pulled them off. Remote teams have trust each other in working together, right? But it’s harder.

I do want to mention, before we move onto the question, here. I want to mention one other key practice that’s really crucial. It’s been very crucial at General UI. Is, the retrospective. So, retros are our opportunity to make progress, as a team. In talking about what you did as a team over the last period, and what went well? And what didn’t go well. That’s a tremendous opportunity to build trust. But it’s also an opportunity to move forward, and not regress. So the goal of our retro is to advance. Put a stick in the ground of where the advancement was. And then try some new experiments that are going to either work or not work. But in the next retro, you’ll identify whether they worked or didn’t work. And thing that move you forward, you keep. The things that did not move you forward you throw away. And that process of continuous improvement and gradual improvement has been very, very important and very critical. I also think that’s a very profound idea that applies to a lot of situations in industries beyond software development.

John-Daniel: We do have some questions, here, coming through. So here’s one from Tyler Frye [SP]. Is, can you give a practical example of how peer-programming looks in your organization?

Jason: Great question. And I could actually put it on the whiteboard. Well, maybe we shouldn’t really put it, right? So we actually use Mac Pro Towers, which are the cylinders. They look really cool and they’re really fast, which is great. They have two thunderbolt displays. So we have mirrored thunderbolt displays side-by-side. And then, two keyboards, and two mice.

Now, the keyboards and the mice, they’re USB. They plug into the USB port in the back of the Mac Pro. And you can only move one mouse at a time. I mean you could try, but you’d fight, if you tried to move them both. And only one person can type at a time, or it gets really confusing. The point is not that you battle over input devices. The point is that you can very organically shift from one person to the other, without having to elbow somebody out of the way, and grab the keyboard. And without having to sit with your neck crooked, for an entire workday. That’s a really awful thing. And so we allow people…people are set up to sit straight and look at their monitor head on. But, in fact, the input devices are going to the same machine in the monitor, so a mirror of all this.

Kevin: And that’s to force a little bit of tension, right? Because you have these two roles. I don’t know if you’ve heard this before. But the two roles in pairing are the driver and the navigator. And everybody knows how to drive because that’s what you have to do to get anything done. And the navigator role is the one that people have to learn how to do. And having one computer, and having the inability for you to move the mouse and type while the other person’s typing, keeps you from being unpaired programmers, which is a Kevin Klinemeier term. But unpaired programmers are two people that are coding near each other. I’m on my laptop and Jason has his laptop. We’re both working on the same project.

That’s not what we’re looking for. We want to force the other person to not be in their comfort zone of typing into an editor. And to think about the higher-level stuff, right? Are there new language features? Or, what’s the next test? And really go through that checklist of being a good navigator. And that’s what that set up forces.

John-Daniel: Cool. Got another question, here. I work for a medium-sized nonprofit with about 20 developers. We are similar to a consultancy, in that we have 100 or so departments. So we’re still trying to figure out how to do resource allocation for projects. Can you speak more about what tools and strategies you use to schedule and prioritize workers? Also, any suggestion on how to help justify peer-programming, when management might simply view it as reducing our capacity by half?

Jason: Kevin, I’d like to answer the second one. Do you want to go for the first one, first?

Kevin: Sure. There’s no magic bullet, here. What you have is a limited…as you know, I’m sure you’re feeling the pain of this all the time. You have limited resources and unlimited requests. And any tool is going to make visible, that pain. And it may be less to do with the software process. And may be to do with the management and leadership challenge of who makes this decision. How do we decide when there’s 10 things we want to do, and we can only do five of them? And you’ve got to understand that about your organization before you can use a tool for it. A tool may help you make that visible if you’re in a situation where we have…we didn’t even know how many things we want to do and we don’t know how long any of them are going to take. Then the tool…may be a tool that just lists SaaS, and allows your developers to estimate them are going to help.

As a nonprofit, I’m guessing, you’re not all in the same room. But if you were, I always start out with the 3M solution. Which is some sort of sticky notes, and white boards, and something that’s very simple but more important — very, very flexible. We use JIRA, internally. JIRA is a powerful floor wax and dessert topping. It does a bunch of stuff.

And any time I set up a new JIRA project, the first thing I do is turn-off 50% of the features because we’re not actually using those. And so it can be sometimes taking on a tool is really confusing. And just having a piece of paper that you could write on and say, “This is the thing. And, how long will it take?” And I’ll draw a star on the ones that are important to this group. And a circle on that group. And that flexibility to just figure out what’s even happening can be a way forward.

Jason: I would add one more little bit of maybe our secret sauce. Which is that, when it comes to actual resource allocation to projects, we don’t assign people to projects. We assign projects to be completed. And we assign projects, in most cases, at pairing stations. But we actually let the people vote with their feet and move to the projects that they are the most…not necessarily the most skilled at, but the most interested in. And so typically what we really like to see is somebody who knows a great deal about the client, or the project, or the technology, or all of them. And then somebody who’s learning all of those. Because it increases the spread of knowledge.

But, fundamentally, the decisions on resource allocations are up to the developers that are in pairs. And the team sort that out. So we’re never in the regrettable position of saying, “You’re the last man standing. Why don’t you go work on that thing?” And maybe that’s not a fit. So the team work that out. Your second part of your question…

John-Daniel: [inaudible 00:34:55] a similar question from Tyler. Well, I think that probably overlap in your answer. Which he asks: when making a switch from non-peer-programming, start of peer-programming, would you encourage the amount of developers to potentially accomplish the same goal? We are small team of six developers.

So I think that might go hand-in-hand with, “How do I sell this to management?”

Jason: Yeah. Selling to management and talking about the brutal science of economics. In the short-term, as you adopt peer-programming, you may not lose quickly until your team masters the communication, the styles.

In fact, for the first five weeks, we’ve noticed a pattern that there’s five-weeks of frustration. And then, after that, it’s just extremely positive, from the developer themselves.

In selling peer-programming to management, the question you want to ask is, do you want to build a sustainable software product or not. If you want to build a product that is owned and curated and sustained by a team that shares the knowledge about the product and really owns it as a team, it is such a better choice. Because, when you’re pairing, if one person goes on vacation, or wins the lottery, or…we all know lots of things can happen to developers. They leave the team for some reason. You have trial knowledge of what was built. You don’t have this [inaudible 00:35:38] knowledge who knows everything about the codebase. Then walk across the street and never come back, and then your product dies along with that developer leaving.

But the measurable and pragmatic advantages are tremendous as well. And we have number of studies…and, actually, I suppose should’ve included those, some white papers in the assets. Maybe we can post them after the webinar is done.

But, showing the economic advantage of peer-programing. And it extends from shared engineered practices, shorter ramp up time, in-line bug fix and defect fix. And, overall, product quality leading to reduced need for successive fixed releases.

Kevin: There’s also an interaction with quality assurance that you want to work out for. Is, if you’re dealing with a team that is expected to do some period of development. And then there’s some period of quality assurance where you’re just doing testing in that period. That isn’t how we operate. But what you may find is that this period of software development does get longer. And so don’t fall prey to a problem of mis-measurement.

Because, it’s okay if this period of software development extends if, like Jason has talked about, you’ve caught almost all the bugs. I’m not going to tell you “all.” Everybody knows that’s a lie. But you’ve caught almost all the bugs in that period. And it makes quality assurance just a rubber stamp, then that’s really powerful.

Jason: A great way to explain it. This is the metaphor I fall back on sometimes. Is, security from point A to point B, and that’s your development path. Assuming that everybody knows where point B is, which is never the case. But you’re going from point A to point B.

With caveman developers you might move faster. But you’re not moving in a very direct path. So your path is longer. With peer-programming, same number of developers. You move in a more measured pace. But it’s much easier to manage risk. Much easier to manage quality. And when you get to point B, you have a sustainable solution that can last and exist as the software product. It isn’t going to die on the vine six-months later. Which is the fate of a tremendous work from software industry, regrettably.

John-Daniel: We have one last question from David. This comes back to you talking earlier, Kevin, about the opinions of people on the team and trudging up this idea. [inaudible 00:39:19] What do you do about people who, always, insist on being the teacher, and never the student? Who work on a team but act as if they own the team?

Kevin: That’s a good question. I’m going to think for just a moment, here. There’s a few things that you can do. Number one, they’ve got to understand that it’s a problem. And there’s a few ways to tackle that. The thing that I usually say is that, “The coin of the realm in most software development teams is the respect of your peers.” And this is keenly aware to me in my current role of the Director.

At some level, nobody cares what the director thinks. Only if you’re going to use some big hammer movement like letting people go or something. The rest of the time, nobody cares what the director thinks. They want to know if the people they respect in the project among their peers, respect them back. And so some kind of review process, like 360 reviews, where you have everybody share feedback about everybody else, can begin to get you the visibility to make the change.

If you want to go to Greek philosophy. If you’ve read Aristotle’s Wiki Page on Rhetoric, like I have…just the Wiki Page. But he says, “In order to convince anybody to change their mind, you first have to convince them that there’s a problem.”

And so, I think you’ve got to start there. And then, once you’ve convinced them that there’s a problem, then you can go forward and talk about, “What are you going to learn? When are you going got put yourself in the learning role with these other folks?”

And then, if it’s a challenge of, “You’re spending all the time being the talking guy but not actually writing the code,” you can begin to adjust this about them. [inaudible 00:40:58]

John-Daniel: Want to add anything to that, Jason?

Jason: Yeah. I guess I would just add that communication is key. And particularly, I think, in the retro process we have the opportunity to bring some of these things to the surface instead of letting them simmer. And by bringing them out, you start to develop a constructive cooperation.

That’s why we do retros periodically on the rhythm. And, with that check, we have the opportunity to improve. And most of the time, if there’s a real [inaudible 00:41:33] it can get worked out that way. But, you may have to face a situation where things are changing.

And another Kevin-ism that we might say is, “Well, if you can’t change your team, then you have to change your people.” But that’s obviously a last resort. I think that the goal of our team culture building and we really emphasize in trust and communication on a software development team. The goal is to work out problems like that, and through that communication. Maybe it doesn’t always work but you’ve got to give it your best shot.

John-Daniel: We’ll wrap up there. I’ll just jump back into the scene. And say, thank you very much for everybody who’s come along. I really appreciated all the questions. I’ve posted a couple of polls as well, to get your feedback on what we can do with the next session.

There was a couple of comments that the video quality, especially early on, was a little bit low. So we’re just experimenting with this software at the moment. Fortunately it was a discussion. So hopefully that wasn’t too much trouble. And we’ll grab those white papers and get them mailed out to everybody in the next hour or two, too. Thank you very much for joining us. And I hope you’ll join us for the next one. Thanks.

Kevin: Thanks, everybody.

Next level software intelligence across your entire stack.

One Comment on “Webinar: What to do after you’ve learned agile practices”

  1. Pingback: Agile Practices - What Comes Next? - The Raygun Blog

Leave a Reply

Your email address will not be published. Required fields are marked *