Where do I start? I’ve been in software development since the early 90’s, and I’ve been in a variety of roles and what I am known for is falling early into Agile software development. I started with extreme programming on a team in 2000 where the consultant was Kent Beck, the guy who wrote the book on that, and then just fell very deep and hard into Agile software development since then and I am the person that’s always had a problem with Agile development, that it didn’t focus enough on users and enough on product stuff so I tend to be known as the Agile guy that focuses on user experience in Agile development and good product design in Agile development. I worked as a product manager for years, worked as a consultant for many years for a company called ThoughtWorks and these days I run a tiny consultancy of two people and an office manager called comakers. That’s me.
2. And then you’re here talking about comaking?
It’s been just this summer that I’ve went from just Jeff Patton to comakers, I had to give the company a name, and I am seeing an emergent different better way of working that’s sort of a step above Agile, sort of a synthesis of a lot of the things that are going on in the product communities, the design communities, and the Lean startup communities. One where we’re moving away from this traditional Agile role of customer product owner tells team what to build to one where whole teams take responsibility for working together and figuring out what to build and taking responsibility for it, the terms for that are cocreation and comaking, I like the word making better because it seems like your hands are a little dirtier, so comaking is the best word I have right now to describe this way of working.
I’ll start as, where do I back up? One of the fundamental problems I see in software development is teams are taking responsibility of building stuff and meeting deadlines and success is often this project success definition of delivering all this stuff on time. But if we widen our view to be product sensitive, the life of the product doesn’t start until after it’s delivered, the project ends, the product’s life starts and what really matters is the results of delivering that product. So, you were at the talk I gave yesterday and I’ll talk about the thing we deliver is output, what we get after we deliver is an outcome. So we first have to start by saying “we have to be outcome centric, teams now care whether this stuff is good or not, it isn’t just the product owner’s responsibility, it’s the whole team’s responsibility.
Now, if we care about outcome, we need people that understand, it’s not a simple, it’s a mix up of a lot of different concerns, is the product we’re building is it valuable to the people who want to buy it and use it, is it valuable to our organization to invest in building it, can people actually use it easily, is it fun and then is it feasible, can we build it on time using the tools that we’ve got. So to cover those valuable, usable, feasible concerns you’ve got to have people that understand product and business, people that understand users and use and people that understand technical concerns. So we refer to that as a balanced team, so to get some balance in that team you’ve got to have a mixture of these kinds of people and not separate them into different teams.
Your question was how do you build a comaking team? First you get some balance into it, second what we might call a product owner isn’t, since everyone owns, we’re looking for leadership, we’re looking for vision and sometimes the leader emerges out of the team at times, but it’s best to be aligned in the same direction and not competing with each other for ideas. Where do we start? There’s a lot of components, you need a place to work and a way to deliver and a way to experiment and an organization that’s friendly to all this and that seems to be the biggest impedance I see, is organizations to see software development as the ditch diggers of the organization and the people that decide that a ditch needs to be dug and where it needs to go, they’re on the other side of the building.
Harry: That sounds like a lot culture or sponsorship is very important for this effort.
We were talking ahead of time about the culture issues and this way of thinking is a big culture change. So many organizations look at their IT group as the people that, once we figure out what the work is that needs to be done you will have them do it for us, and since we aren’t the ones that are technical, we know how long that’s going to take, we’ll tell them what it is, they will tell us how long it takes, we will complain that it’s too long, we’ll pressure them and they’ll finally come up with something that they can deliver on time, it doesn’t work right, we blame them, they blame us and that’s the kind of culture most organizations are built around.
In a weird way, we treat our internal software development teams the same way we treat outsourced vendors, we treat them like vendors we bought, and so they work for us, oddly they behave like outsourced vendors with only one client, which means that they don’t have a choice but to make them happy or they’ll go hungry. But culture change is moving over to a culture: we are all in the same team, and we all work together to be successful and business success and development success aren’t separate things or two different things. But the idea of other people, other than management, being responsible for making choices about what to build that’s a tough culture change, that’s a tough change that a lot of organizations are struggling with.
Oh, that’s a good question. Well, where do we start? We can attack the way that we’re working, let’s go up a level. The first thing to start doing is asking more questions, the simple questions are who’s using our product, what will they do with it and how do they benefit from it and to start having conversations about that. The minute your conversations start becoming a bit more about that, the minute you start realizing that some of the things we’re doing we don’t need to do, and some of the things, now that I understand who we are building for, some of the things we should be doing we are not doing, the minute you start sensing that there’s problems, and we stop talking about the specifications of the thing we’re building, what the requirements are and start talking what the needs of people are.
So step one is to elevate the conversation and make sure it is indeed a conversation, you’re working and talking to other people about this. Now, in a lot of organizations that I work with, people start asking questions like that and the first answers are often “I don’t know” and “I am not sure”, and then I’ll recommend some insurgent behavior of just getting out and finding those people. Actually, I won’t name any names, but I spoke with somebody who works for a very large company that everybody knows, whose name starts with G and he had a goal to learn about users and he couldn’t seek approval from his organization for his plan to go find users and that would have taken time and talking with him he said “if I would have asked they would have just said no so I didn’t ask, I went out and found them, and talked to them and learned about them”, and that starts to be a next step, you can have conversations about users, but if there aren’t people in the office that understand, that’s the go and get learning.
Harry: So, once you understand the goals for comaking it almost falls on your shoulders to take advantage of that and start walking the walk, so to speak.
Yes, and walking the walk means becoming very deliberate about understanding who you are building for and making sense of it, understanding the way they work and making sense of it, so I’m known for a practice in Agile development called story mapping. And story mapping is a way to come up with a product backlog, but it’s a simple practice where left through right I’ll think through given some understanding of who’s using the product, I’ll think through a day in their life or how they use the product and that’s left to right flow and I’ll break it down top to bottom to decompose it into parts or things we can build, it’s a great backlog building technique because it helps you find holes, it helps you not build things you don’t need to, helps you not forget things you need to build, but where that practice goes wrong sometimes is when people don’t understand users, but once you do, you start making sense of it and modeling it that way, you can start slicing away small parts and start building small parts as simple tests or prototypes and vetting it, getting that back in front of the users or in front of people, testing whether that solves a problem for them or doesn’t solve a problem for them.
And those start to be next steps, next steps are even testing ideas verbally or testing ideas with simple paper prototypes, testing ideas with more rigorous prototypes and really taking responsibility for whether the thing you are doing is going to solve people’s problems or not.
Harry: And then hopefully gaining support from your teammates and hopefully making that critical mass.
You can’t do this alone, it’s hard to do it, you’ve got to convert people. The fastest way I’ve been able to convert people to want to do this, you can’t talk people into caring, but how can I say, I remember back when I was running teams the fastest way for me to get developers to start to think like this was not to talk with them about it or tell them to, it was to say “come on, we’re going on a field trip” and taking them, driving the car out to where someone was using our product and having them watch them use the product.
A colleague of mine that was working with a large chain of hotels and he was working with executives there, they’ve been trying to tell the executive there that people using your product they don’t like it or having trouble with it, things like that, and he was saying “oh, we’ve got this road map and we’ve got these demands” and he told me about inviting the guy to lunch and they’ve met the guy for lunch, “ok, it’s time to go to lunch”, the guy said “I can drive”, he says “oh, no, I’ll drive”, they got in the car and he drove him straight to one of the hotels where they wrote software, walked him straight into the backroom, the guy’s “where are we going?” And then before he knew it he was standing behind someone using the product. As soon as you watch someone use your crap software, one of two things happen: First off, you’re always horrified and then secondly, you either care or you drop back into “the stupid users don’t know what they are doing” sort of talk.
But most people care or maybe secondarily they say “I care and I know this is really important, I don’t ever want to do that again, but I want to make sure that somebody else does”. You need to do this with other people and the fastest way to make them care is to have them feel some empathy for the people they’re building for, and some responsibility for what they are building and then ideally some pride. We’re sitting in San Francisco and I just came to you from, I just walked over from one of the customers I’ve worked with before and this is a company that makes software for travel. I first started working with them a little over a year ago and it’s been just incredible to see the change in this organization. We were making fun of one of the product managers because he was so successful and the guy just has this big grin on his face, the corners of his mouth go up to his ears, and he has so much pride in what they’ve done, they’ve figured out some interesting things that have made things a lot better and that’s the stuff that just pumps me up, we are no longer having stupid conversations about story points and backlog prioritization or any of that crap, we are talking about people that are building stuff that have strong outcomes and impacts on their organization and they’re proud of it. That’s what matters.
Yes, and as you latched on to, it’s a bit of a culture change. Maybe I’ll be blunt with you, I was talking with another friend of mine, since we are at a conference talking, this is a great opportunity to meet a lot of people I don’t see all the time, I was talking with another friend of mine last night, and I was telling him I prefer to work with clients where the adjustments I am trying to make are more chiropractic, I might go see a chiropractor to knock my skeleton back into place. Versus going to somebody who is an orthopedic surgeon who has to really mend some seriously broken bones, he’ll never be quite right again.
I’ve worked with organizations whose culture already has the seeds of people caring about this stuff, people already have a sense of what they are doing, they have a sense of who their users are, a sense of what they are doing can matter and sometimes with just a little bit of nudging to get out there and meet the users, to pay closer attention to what the outcomes are, they snap back into place and before you know it they are there. But if you are in an organization that needs orthopedic surgery so to speak, some of those tactics just don’t … it’s going to take more and I don’t know what it is.
The shift I’ve seen, and hopefully we are on the same wavelength here, I started with Agile software development in the 2000s and this was a big shift into getting a lot more deliberate and better at how we deliver software, and then the minute you get better at delivering software, the minute you learn some of the basic collaboration things it takes to make Agile work is the minute the bottle neck starts to shift upstream to realizing that what matters more is that we are making better decisions about what to make. The bigger things that are driving public awareness of this shift are the rise of concepts like Lean Startup, where Lean Startup describes a cycle of build, measure, learn. Where measure and learn are things that have to take place not inside of our organization, we’re not measuring development speed as velocity, we are measuring what people do with our product or don’t do with it, and that’s what we learn from. But most of Lean Startup activity takes place outside of your building or outside of the development team, that’s driving a shift.
Some of the organizations I’m working with, what’s driving their shift in thinking comes from design thinking, and design thinking as popularized by companies like IDEO and the Stanford Design School, and they describe this very collaborative, energetic way of working together, to solve problems. And when you combine Lean Startup learning and design thinking, design process, that starts to drive culture change and none of this crap works if you can’t build, if you don’t have that raw Agile engine underneath it, that delivers predictably and high enough quality. You start to combine those things and you end up with a really strong secret sauce. Does that answer your question about what brings this shift around?
Harry: Absolutely. Thanks a lot for your time, Jeff.
Thank you, it’s been a pleasure.