The Importance of Trust in Agile: An Interview with Jeff Nielsen

In this interview, Jeff Nielsen, the senior vice president of engineering at 3Pillar Global, tells us about the key qualities of an effective agile team, the importance of trust in agile teams and how to establish it, and even some of the hot topics of programming today.

Cameron Philipp-Edmonds: Today we have Jeff Nielsen. Thank you for joining us today.

Jeff Nielsen: Happy to be here.

Cameron Philipp-Edmonds: All right, can you start us off by tell us little bit about yourself?

Jeff Nielsen: Sure, so me in a nutshell. I build software that people love to use, I build teams that customers love to work with, and I build organizations that developers love to work in. That's my little credo for life. I got a job as a software tester actually, right out at high school, and got bitten by the development bug shortly after that. I spent a number of years as a programmer, architect, tech lead, project manager, that kind of thing.

Then around the year 2000, or in the year 2000, I got exposed to some of Kent Beck's writing on extreme programming and I was fascinated by this. Spent the next three years, trying to figure out how to put together a really high performing extreme programming team at a medium size consultancy, and later a set of teams. Then spent the next four years after that, trying to figure out how to replicate what we've done or take what we've done in having the success with extreme programming and agile software development and see if I could apply at other organizations that were very different from where I learned how to do it, or figure it out how to do it. Really figuring out what was the essence of these ideas, the values, and the principles behind the agile movement as opposed to any specific practices, and how could those ideas in values benefit, like I said a lot of different types of organization.

And since then, I've had a variety of executive roles, either in consulting organizations, or software development organizations actually practicing what I preach. Now, I'm the senior vice president of engineering at 3Pillar Global.

Cameron Philipp-Edmonds: Can you tell us about what 3Pillar Global does?

Jeff Nielsen: 3Pillar works with our clients with businesses to develop successful software products, really focused on seamless and good customer experiences, that's our mission at 3Pillar. We consider ourselves a product development partner. And my particular role I oversee 500 plus software development professionals organized into roughly 60 teams that are in three different locations worldwide.

A lot of smart people building a lot of great software product that we hope is helping a lot of our customers.

Cameron Philipp-Edmonds: All right, fantastic. You're a big proponent of trust and agile. How has agile development change the landscape of modern software development?

Jeff Nielsen: One of the things I think that, the agile software development movement has helped with, is to help people understand what really goes on in software development. It's one of those things that I think a person that's not a practitioner, someone that hasn't actually been involved in producing software. They can have a very hard time conceptualizing, and there's a lot of I think misconceptions out there about what is software development, how does it work.

Is it just a bunch of guys sitting in around on computer's typing? And you know what's so hard about that? And or is it like building a bridge, or building a house? We call it software engineering. I think the agile movement has been successful at dispelling some of this myths about how software development works, and how it works best. This idea of individuals and interactions being more important than processes and tools.

I think for a long time, we chased up this process tree, just thinking that if we could just figure out the right process, the right approach for building software that our projects would go better and it wouldn't really matter what kind of people we had doing the work, that we just need a better processes. Or if it's all about getting the requirements right up front, and then that's the thing that saves you.

We spent a lot of time as an industry working on better tools for that. If that turns out to be a fundamentally flawed premise this idea that you can specify mostly in advanced what the right system is to build. But, if that turns out to be a flawed premise then where does that leave you? Again I think that's one of the myths that the agile movement has helped to dispel it, that really you learn by doing that the working software part of the agile manifesto.

You're going to learn more by producing software that works in getting into the hands of people than you will by comprehensively documenting everything. I think agile has helped us refocus in general, on the things that actually do make more of a difference that are more of a determine in a project success like collaboration, like communication, and less focus on software development is typing, over that the construction part of software is somehow the expensive part that we have to optimize.

I think I see a lot of organizations focused on, optimizing communication and collaboration and keeping good results, even if their processes aren't perfect, even if their our tools aren't great.

Cameron Philipp-Edmonds: Right, you talked about collaboration, and really having good team work there. What are some other key qualities over an effective agile team?

Jeff Nielsen: Well I'm speaking at the Agile Conference here in a month or so in Orlando. I've actually chosen to focus on the topic of commitments, and the power of commitments. Because that's something I think is misunderstood by both consumers of agile software development teams, and even participants in agile software development teams. There's this idea out there with agile, you don't really know what you're going to get.

You can't pin down the deadline, you'll get it when you get it and that's just the way it has to be. I think both there's like I said customers to believe that and developers to believe that. That's not a very effective way to work in my experience. One of the ways that I look at agile is how would we work if we could really trust the people we were working with?

That idea sort of permeates how little can we do, how little process can we put in place and still be successful, what's the simplest thing that could possibly work. I look at agile that way and I've explained agile that way. Is how would we work if we really could trust people? As opposed to some of this other process frameworks that assume, that people are inherently lazy, and won't do a good job unless you take meaning minutes and follow up incessantly.

I don't think that agile software development works very well without a high degree of trust. The best way that I know to build trust, and this is trust both within the team, and between the team and it's customer is by successfully making, and keeping commitments. I've chosen to do a little bit of writing and thinking about that this year, and that's what I'll be speaking about, is how the ability to making keep commitments which is hard, and which is not a scale that a lot of people or teams have.

How that can be the key element of building high trust?

Cameron Philipp-Edmonds: Kind of building upon that. You talked about trust, of being a key component there. When you talk to people about agile, they always say, collaboration is super important, constant adaptations are super important. Trust is often overlooked. Why is that?

Jeff Nielsen: That's a good question, I think if you have it, you take it for granted. If you don't have it, you don't realize that's the problem. I worked in low trust environments where people believe that the problem is just, well the contract aren't good enough, or my boss is an idiot. Or these guys don't really know what they want, or this people aren’t skilled enough. There's all this symptoms that you can often trace back to low trust.

It's like you can't see in front of your own eyeballs, you don't realize that the trust is the key problem there. Conversely if you're on a team, where there is that high trust relationship. You look at these people that are struggling with contracts, and unhappy customers, I think what's their problem? What practice? Maybe they're not paired programming. We tend to try to find practice solutions rather than looking for root causes.

That maybe one of the reasons is people just don't realize what's going on. They don't ask themselves, what is our trust environment?

Cameron Philipp-Edmonds: Talking about the trust environment. The trust environment, or is trust in agile teams more important, or what degree is trust really important as compared to other software teams.

Jeff Nielsen: This waterfall teams that are still out there somewhere, that we can't seem to find?

Cameron Philipp-Edmonds: Those mythical waterfall teams?

Jeff Nielsen: That's right, that's right. With all these unenlightened folks. It depends on if you're following more of a process-centric approach, a rules-based approach I guess, you could say, "Well trust isn't as important, because we've got all this safeguards in place. Because we don't trust people." A process that verifies that everything has happened appropriately three times and the right people were at the meetings. I guess you could say that trust is less important, in those environment.

Although, having been in some of those environment it still a lot harder to get things done. I don't know if there's anything particular to agile just it exposes this problem, or it strips away a lot of this things that are substituted for trust and lets you know whether you've got it. You find out pretty quickly whether the customer believes if the team is doing what is in their best interest.

You found out pretty quickly whether you think that people believe that others around them are working hard enough. It's very hard to hide a broken promise, or a missed commitment, in an agile environment where you're showing the results of your work every week or two.

Cameron Philipp-Edmonds: You talk about that broken promise, and that missed commitment. Once trust is really lost in an agile team, what is a good way to reestablish it, and can you reestablish it?

Jeff Nielsen: You mean trust within the team, or trust between a team and it's larger project community?

Cameron Philipp-Edmonds: Let's go with both.

Jeff Nielsen: Okay, somehow I thought you would say that. Well let me start with the latter. If you run into a situation where the stakeholders call it a product owner or whatever you would, starts to believe that the team is not good at keeping it's promises. That's a very toxic situation and difficult to regain. They say it takes years to build trust and on the moments to break it. That is trust. I've seen teams that failed to deliver what they promise to do in iteration or two, and then for the next six months that's the story that gets told, and that's the belief that's going around the project ecosystem is this team just doesn't deliver.

That said, what I tell teams and the way I coach teams is the best thing you can do is make a promise and keep it. And once you do that several times in a row, that becomes the new story. This doesn't have to be a promise about we'll get this much work done by the end of the iteration. Although that's a very effective promise to make at an iteration level or sprint level in an agile team.

We'll do this six stories come heck or high water and if we finish these, then well these three more will treat as stretch stories, delivering on that commitment for a couple of iterations certainly goes a long way in building trust. It can be smaller things, it can be "We're going to show up to this meeting in time or we'll commit to a certain" often when you're in an environment when the requirements really are changing fast, and you keep up with.

One thing I encourage team to commit to is a certain level of output, a certain velocity. You say "no matter what, we will produce twenty points worth this iteration." That's a promise you can work on. At the individual level, within the team, it's no different. You think about what the people that you trust, and the people that you don't trust. The people that you trust are those that do what they say, they're going to do most of the time.

When they don't, they let you know, right away when something comes up. We've all been in this situation where we find we're unable to keep a promise we've made. Sometimes that's lack of ability, sometimes it's our own foibles and weaknesses that get in the way. As soon as something changes, and you realize you're not going to be able to keep a promise, communicate that right away.

That goes a long way towards building a trust. The other key aspect of trust is trusting that someone else is considering your interest. It’s great to have someone that always does what they say they will do, and it's easy to trust that kind of person. It's even better if you trust at that person will do what they say they're going to do and keep your interest in mind as they do that.

Think about a relationship or a marriage relationship for example, that you have to have that.

Cameron Philipp-Edmonds: It's kind of like having a good teammate that not only produces on the court or on the field, but also wants you to succeed as well.

Jeff Nielsen: That's right, yeah.

Cameron Philipp-Edmonds: Okay, now you talked about trust being really important, the communication being really important. Let's say theoretically we have a team that has a great process in place. They're all very skilled, and they have a product that customers really want. There's no trust. Is the writing kind on the wall, is it just a matter of time. Can agile team really survive without trust?

Jeff Nielsen: So everything looks good on the surface, but you spent some time with the team and you realize that so-and-so really doesn't think highly of the other person, and the customers are talking badly to their friends behind the team's back. Your question is what do I think will happen?

Cameron Philipp-Edmonds: Yes.

Jeff Nielsen: Well it's hard for me to imagine the situation where everyone is happy, but the trust is not existing. I can say based on my experience if you neglect trust if trust gets broken, and you don't address it, that's a recipe for a failure sooner or later. Failure usually meaning the things get canceled, the projects get canceled, the team gets disbanded, people leave, you find another vendor, I would say it's that important.

Something to be aware of, like I said earlier, ask yourself, what is our trust environment? Are these symptoms that we're seeing brought about by people not trusting each other?

Cameron Philipp-Edmonds: Okay, now you've work with a number of different organizations from startups to industry juggernauts. Do you find that trust, as a critical component to agile success, is more important in small or large organizations and why is that?

Jeff Nielsen: Well, the biggest difference that comes to mind for me the large versus small organization is that, a large organization has reached the size that you can't know everybody that you depend on for your success. It's hard to trust someone that you don't know it's harder to trust someone that you don't know. A quick example: If I've got an organization of 20 to 50 people and I'm the CFO and I pretty much know everybody. We can have a expense reimbursement policy that is pretty simple and straight forward, and I can believe that if something goes wrong, I can deal with an individual level.

Whereas if you're in a five-thousand person organization and you're the CFO, you're default is going to be put, in place a lot more regulations and rules, just because there may only be five people out there that are ready to take advantage of the policy. But those five people are there, and you don't know who they are, and you don't know how to deal with him accepting policy.

I would say in general the culture of trust is lower, in a large organization because you've got all these things in place and so that culture can be absorbed by a team. If they come in, they form and you still got a team, either way of large organizations, it's still some team that people are building software and if it's an effective team, it's probably a smaller team. That culture of mistrust can seep in more easily in a larger organization.

I would say if you're in a larger organization, that's more likely to be a problem you're experiencing.

Cameron Philipp-Edmonds: Okay, basically to summate that, a little bit if I could, trust doesn't matter if you're large or small, trust is really important, it's just the matter of fact that with a larger organization, you're more likely to have barriers to establishing and keeping trust.

Jeff Nielsen: I think that's right, yeah. Certainly within your organization. That's not to say, there can be a team embedded in some huge organization that has a fantastic degree of trust both within themselves, and with their particular customer. I've seen that.

Cameron Philipp-Edmonds: All right, and Jeff you hold the Master’s Degree from Virginia Tech in computer science and instructional technology. Implementing computer sciences in primary school has been a hot topic recently. What are your opinions on making it a part of the public school curriculum?

Jeff Nielsen: I've got six kids, have tried to get various ones of them interested in programming at different points in their lives. I don't see any reason to shy away from teaching programming skills as early as we start to teach writing skills, or other artistic skills. I feel like programming shares a lot in common with all of those kinds of activities. And certainly we live in a digital age, we live in an age where almost everything we interact with, has some sort of software behind it.

Logically, it would make sense that we would want our kids to be literate in what makes those things work. I've got some friends in that community, Llewellyn Falco's name comes to mind, who spent a lot of time figuring out how to teach the kids the program and very successfully. It's different than teaching an adult to program, but I don't think there's anything age specific, that means you can't think that way until you hit puberty, for example, I don’t think that's true. So yeah, I think it's a great idea.

Cameron Philipp-Edmonds: You've done a lot of things, we talked about at the beginning of the interview. Knowing what you know now what advice would you give to yourself in your younger days?

Jeff Nielsen: A younger Jeff? Counseling a younger Jeff? The biggest thing that comes to mind is I would say is towork harder to get your ideas out there. If you built something that you think is particularly cool that you find particularly helpful, a piece of software, or if you've created a team that's functioning especially well, there's probably a lot of other people that need that same solution that you've stumbled on.

The reason I would give this advice to myself is looking back, I don’t think I realized how many great things we were doing in some of my early professional days. Later folks would write in best selling books about some of the things we've implemented within a process wise, "We were doing that, I guess not everybody had figure that out." Same thing with software, I can't think of, of several occasions where we built a great piece of software then two to five years later, I see an open source project that takes off or a framework that takes off, that have that same ideas in there and just never occurred to me to well maybe this is something that other people would find useful. That would be my advices, is in addition to building cool things and building great teams. Put some more effort into spreading spreading those things that you've built.

Cameron Philipp-Edmonds: All right, that actually wraps up out interview for today and thank you so much for joining us today, Jeff Nielsen of 3Pillar Global, always trustworthy. Thank you so much.

Jeff Nielsen: Thank you.

Jeff Nielsen is 3Pillar’s SVP of Engineering. In this role, he oversees the delivery of technology services to all 3Pillar clients. Jeff is responsible for all development processes in the company and manages numerous global client-based engineering teams.

Prior to 3Pillar, Jeff was the CTO and SVP of Delivery at the Santeon Group, where he ran their global software development initiatives and their agile coaching practice. At Santeon he provided executive-level coaching to federal agencies and Fortune 100 commercial clients making large-scale transitions to agile. As Head of Engineering at TrapWire for three years, he oversaw more than 50 production releases of the company’s flagship SaaS product. Jeff was also Vice President/Chief Scientist at Digital Focus, pioneering their use of agile methods in early 2001. Jeff has worked with a number of organizations – from startups to multibillion-dollar firms – over the course of more than a decade to help them improve their software development processes.

Jeff holds M.S. and M.A.Ed. degrees in Computer Science and Instructional Technology from Virginia Tech and a Bachelors in Music from BYU.

Podcast Music: "Han Solo" (Captain Stu) / CC BY-NC-SA 3.0