Lesson: Agile Development with Ian McFarland

Step #10 Evolution: What is next in the waterfall, agile, lean, customer development trajectory?

There are folks who are more focused about measuring the impact. Jeff Sutherland's got lots of really good stuff on sort of quantitative analysis that shows that it works. And this is again a place where I feel like you can get too caught up in the analysis instead of just actually producing business value. So let's talk about different parts of agile. Not from a theoretical, more concretely. So, why is pair programming good? There are lots of reasons why pair programming is a super powerful tool. One. Knowledge transfer. If you have pairs that you rotate and split and you have good pair rotation, you're not going to have one person who knows how to do such and such in the code base. Everyone will have touched every part of the code base at some point. They would have done it all in the context of some other person who wrote the code. So they understand the intent behind the code. So this is a very powerful tool for reducing team risk.

Traditional software programming teams, this came up even in a talk last night, even well functioning classical software teams worry about what happens if Joe leaves or if Katrina is out next week when we have this push. That is because they have specialized knowledge. Honestly, there is no excuse in the modern software team for one person having the only specialized knowledge around this piece of code. Somebody might have deeper expertise. You may have someone who is a great database person or a great functional programming person, but by pairing them with other people on the team, you spread that team knowledge around and then you don't have the bus number problem. You don't have, "How many people would have to get hit by a bus before my company goes away?" If it's one, you're in trouble because there are too many buses; cars are way more dangerous than airplanes.

You really need that resiliency. This is a little harder to quantify but the fact is that it's demonstrably true over and over again that when you have good knowledge sharing within the team; you reduce your team risks. You reduce the likelihood that one person leaving causes a problem. You can see it in teams that have had this methodology and haven't had this methodology. Talk to any manager of any development team who doesn't do rapid pair rotation and they will tell you about how worried they are that such and such person is going to not be on their team at some point in the life of the company.

So there is the team risk piece, there is the knowledge transfer piece. The other thing that you are doing is leveling up all your other people. You're introducing a new technology; you have your functional programming expert. Suddenly you have a whole team that knows enough about functional programming to be able to implement things well using the toolset that you're using. So there is this rapid knowledge transfer piece that comes out of it. There is the continuous code review piece; the fact that you have two brains working on one piece of software produces better thought through code at a higher rate of speed. And you can measure this. There are studies that measure this. But, it is the practice that matters more than the theory. I think is sort of what it comes down to.

Talking about the history obviously, with software development, I started with like no process and sadly there was this paper that talked about Waterfall development which is actually descriptive of something that it saw as an antipattern but people sort of glommed onto it. Agile was going along great and then, about four years ago, I and various other people started to become more and more frustrated with this friction between Agile development and the design process. And so there was this get together over at Cooper Software, Alan Cooper was there, Ward Cunningham who invented the wiki was there, I was there, a bunch of folks, a bunch of Neo folks were there. This was before Neo existed, but pre-Neo folks. And we really started to dig into how do we solve this problem.

There is an impedance mismatch between how design is practiced in the world and all the great stuff that we've learned from Agile about rapid cycle time. Interestingly, this all kind of lays on top of user-centered design, and really what kind of came out of it was what we call now Lean UX. I'll put a plug in for Jeff and Josh's book on Lean UX and the O'Reilly series, they really sort of capture how this team structure piece comes into this. The idea of not separating the software development piece from the design piece was a really core idea that came out of that discussion. And what happens there is a little bit magical.

It used to be that we would do research in the design world and go figure out what people wanted, but really rapidly you would get to the end of where classic research methods worked very well. You could show them a prototype, you could show them a click-through prototype, and that was good, and you would get a lot of useful feedback from that. You can tell a lot from people looking at interfaces and telling you what they would do, but you can't tell what their actual behavior is going to be. So by integrating the software development cycle into that process, one thing that happened was Agile development happened, and the other thing that happened in parallel with that is languages became more responsive, so the cycle time in producing software became shorter and shorter, so that you could start to do it in band with your design cycle.

And so that was a really fundamental shift in the thinking around how do we go about validating ideas. You could take this idea, you could get through the paper prototype phase, have some notion of signal, but at some point you started, actually surprisingly rapidly you'd get to the point where you realized that the feedback you were getting was not predictive enough and you actually needed to reduce to code and see what people actually did on the system. So, that's kind of how the Lean UX thing happened, this was happening in parallel with Eric Ries' work around Lean Startup, and he was kind of coming to it from a slightly different angle, but we were all having these conversations together and it was all converging on this idea of customer validation. again, customer validation and UCD are kind of the opposite perspectives, but it's still about how do you create this nexus between your customer, your designer, and the thing that you are making.

That was kind of the big convergence that turned into Lean Startup and turned into Lean UX. Where we're going from here though, I mean, this is always a continuing evolution, Agile was the bee's knees five years ago and some of us were really unsatisfied with what is was doing. It was producing really flexible code but it wasn't necessarily producing great outcomes, and that was the frustration that lead me to leave Pivotal and start Neo was that I wanted to be able to influence the outcome, not just make really well-factored code that was based on the false assumptions. There is still refinement obviously; this is something that will evolve. We will continue to discover new tools that help us to solve endemic problems in software.

Agile and Lean are not really things that were invented, but they're more things that were discovered that sit on properties of the nature of software. Shortening cycle time helps us to reduce waste because we discover defects faster, and so we focus our energy on things that are valuable instead of things that are not valuable. It's what Ted Nelson always used to call retroactively obvious. It's like, you discover the new thing and then you look back at the old way you did it and go, "That's not very good." Ten years from now we'll be sitting in a room like this, and we'll be saying, "Wow, that Lean stuff, that was certainly very progressive for the time, but boy, it's nothing like what we do today and what we do today is so much better." So there's always this evolution towards new ideas.

I think one trend that I'm seeing now that I'm trying to really instill here at Neo especially is remembering how important the design impulse is. I mean, I've talked about this even since my first talks around Lean, you expect enough design talk. There's a balance between that moment of insight and that vision and creative impulse, and the validation. You can't just validate your way to a great product. You still have to have some core idea that you're trying to create and trying to serve. So it's really easy to get very quanty and go to some growth hacker talk and they're like, "How do you make sure that more people show up?" Actually one way to make sure more people show up and stay is have a really great customer experience. So there is this balance and there's a natural tension to be very quanty.

But quantification's only as good as your model for what you're quantifying. Measurement is useful and it's critical, but it's not sufficient. You have to also know how to interpret the numbers and choose which numbers who care about which things are really leading indicators to the success of my business. So there's a lot of subtlety and art around that. I think just a lot of tooling has still to come. It's still too hard to do good A/B testing easily.

I think the next phase is the same way test driven development took testing and moved it to something that you do all the time. Having the right infrastructure to be able to do A/B testing every time on every idea and making all this stuff easier and part of the flow. That's kind of where we are now, just at the beginning of. But there's going to be more and more stuff like that, that we'll learn new things. Every time we get to a new plateau, you look out and you see all this new stuff. So there's always some new thing to go and try to improve and discover.