Human Driven Development

Chris Young: This time with more confidence, hopefully.

Derek Neighbors: More something. Keeping the principle of Agile‑ish would make it simpler and half‑less.

Chris: That’s true. Why don’t we timebox this? What do you think?

Derek: OK, then will go 10 minutes?

Chris: We’re just going to try 10‑minute talk, and will reveal, and see what we did.

Derek: Yeah!

Chris: OK.

Human Driven Development

Announcer: You’ve heard on test‑driven development, and I bet you’ve heard of contract‑driven development, but have you ever heard of human‑driven development? Today, Derek Neighbors and Chris Young will discuss this topic on the second episode of ScrumCast.

Chris: Just what everybody that we talked to about Scrum and Agile, nobody knows what it is all about anymore. There’s Scrum, there’s Agile, there’s Lean, there is eXtreme programming, there is various incarnations of all of these, so we’re trying to find out what is the one true scrum, if you will or the one true agile.

Derek brought up something that was interesting to me, and that’s that the underlying of all of the principles, the methodologies and practices, are human beings.

That it could be that by putting our focus a little bit closer to the human, and a little bit less from our procedures you might be able to get to something that sort of will alleviate and remove us from this whole mess of philosophical positioning that we tend to read in books, and get down to actually, me and you sitting in a room trying to make some software again.

Essence of Accountability

Derek: When I really think about it, at the end of the day, I think Manifesto for agile software development sums it up pretty good, when it talks about uncovering better ways to develop software by doing it and by helping others do it.

If you look at most of things they value over the things they put less emphasis on, there’s certainly a humanist to the way they talk about individuals and collaborations, and talk about people. If you look at the declaration of interdependence and if you look at the manifesto for software craftsmanship, you’ll see the same sort of thing if you look at the values and principles back and others put forward and in next piece, see the same thing.

I think that as software engineers, that’s the first thing that we throw out the window when it comes to resolving conflict, when it comes to determining the best way to do things.

We make everything about analytics and pragmatic choices. At the end of the day, where it really started to hit home for me is here at Integrum. We’re working through a myriad of different issues and refining our process. We’ve squeezed out a lot of the inefficiency. We’re really now getting down to almost really picking nits in a lot of our practices. I find that people generally hold on to beliefs or value systems.

Not because they necessarily have the belief or the value system, but because of something internal. I think that sometimes to overcome those roadblocks you really have to get to why does somebody believe that, not the fact that they do or they don’t believe it.

If somebody thinks that we should be more lean, and have less process, what’s the real reason behind that? If someone doesn’t like a commitment driven planning approach and would like to be a little less heavy in process or a little heavier in process, or wants to be more accountable or less accountable.

What I find is most of the practices ultimately break down to some form of accountability to yourself, and an accountability to a very small portion of teams. I think, if you take accountability and you cut that back one step further, it’s really about trust.

I think that as human beings, especially in this day and age, in this society, where things are disparate, often we work on teams with people that can live thousands of miles away from us. Even if they work in the same office with us, we’re not as connected as we were a hundred years ago. Some of these trust systems just aren’t there. We all bring our baggage to the table, from our childhood all the way through to our professional careers.

You see somebody act out. Maybe they don’t want to commit to a particular velocity, so they lash out and they get frustrated. Certain team mates can take that as an aggression move. At the end of the day when you really break things down, really that team member that’s lashing out is probably afraid of something bigger than the commitment, and what that commitment brings to it.

I think when we start to see each other as humans, and we start to ask those questions like, “Why is it bothering you to commit to this? What’s the real problem?” I think a lot of it goes back to root cause.

Root cause is human beings. We all have our fears. We all have our egos. We all have these things in place. When we can start to be human enough to have real conversations, authentic conversations with each other, it really allows us to do powerful things as a team.

Building Intimacy

Chris: A lot of the literature that I’ve read about scrum agile software development, basically, any sort of professionalism, they talk a lot about leaving your home at home, leaving your problems at home. It’s an interesting line that you’re walking, starting to talk about how people are feeling at work. How do you think that we could start to look at bringing some of those things up into our regular work process?

Derek: It’s interesting because for me, those that know me somewhat professionally or certainly personally know that I’m kind of the anti‑feelings person. I’m kind of the, for lack of terms, the pragmatic asshole in most circles.

For me, the thing that really sells me that feelings matter in software development is that I’m a firm believer that if everybody in an organization thinks the same way, values the same things entirely, they’re duplicative in their ways. They probably need to go. You don’t need two people that think exactly identically.

The very fiber of every human being is different. As part of that, their reactions to things are different. The way their mood affects what they’re doing is entirely different. If we really want to unleash creativity and innovation in work that we do, and we really want people to be energized, we have to understand the people we work with.

That doesn’t mean that we need to be best buddies with them. It doesn’t mean that we need to be their psychotherapist. But we need to understand what motivates people, what makes people fearful, and more than anything, build that proper trust train between people.

I’m not talking the little trust fall, weirdness, and things like that, but I think that people that engage in that thought process are getting the very similar thing that we’re talking about here, and that is that trust is that important that it can really shape a team dynamic. The question is how do you get there without having…

Exposing Feelings

Chris: …or without falling into these cliches, because we’ve been trying, obviously, the whole self‑help section at the bookstore. There’s the Myers‑Briggs. There’s this trust falls. There’s hundreds and hundreds of different ways that people have tried to get at feelings. What I’ve seen a lot is this attempt to use feelings to approach our work, but here we’re talking about something a little different which is our work to approach our feelings.

Maybe I’ve had a discussion with a developer, and they’ve agreed to try some sort of practice. Then I found out, say the next day, they didn’t at all. I was upset about this, and Derek suggested that I should find out what they’re afraid of.

To me, I was thinking about, “Oh, what do you do if somebody’s insubordinate if you will,” Air quotes around that, “on an agile, self‑organizing team?” How do you deal with somebody who just isn’t going to do what they say?

I was already to come in and start to, “Let’s go through a logical process and start putting things on the board and catch people in their logical fallacies” or something like that. As I said, Derek suggested, “Maybe just find out what they’re afraid of.”

I had a discussion with the person, not directly asking about that, but just like, “Why is it so hard to make this commitment?” By offering myself as a friend, this person felt very open, and was able to express a fear which was immediately resolved.

It was actually about fitting in with the organization at all. That’s what it came down to was, “Hey, do I fit in? Am I going to be liked here? Am I going to be performing at the level that you want?” I was able to say, “Hey, listen. Basically, what Derek has just said that having a lot clones and a lot of people acting exactly the same is not going to bring a lot of innovation to our company. We need more people that think differently, not less.”

What was great about that, though, was that I didn’t go in and ask him how he was feeling. I asked him at first ‑‑ this is hypothetical ‑‑ but, “Why is the velocity off?” Then from there we got down to feelings, having some knowledge that underlying any sort of actions are people feelings, because that’s the thing that gets ignored over and over again.

We’ve had people come and go that had we have a better understanding of them we might have been able to have a better outcome. I’m very interested in learning more about how we could start to apply this. Maybe that’s something that we could talk about in our next podcast. Exactly how we might approach people in ways that could get this information out, so that we could start building better relationships at work that should result in better productivity, and profitability for our businesses?

Derek: Absolutely. I think that, for sure, we don’t take enough time to communicate with each other. We talk a lot about customer communication, but I think a lot of times, when the rubber hits the road, we don’t have the real conversations internally as a team. I think it’s a great segue to the next episode of the podcast on how can we address some of those issues. How can we make those conversations start to happen?

[music]

Chris: Thank you for listening to another episode of ScrumCast, a production of Integrum technology in beautiful and wonderful, better than your city, Chandler, Arizona.

Derek: Absolutely. 85225, baby. Good job, man.

Chris: That was better.

Derek: Yeah.