Cameron Philipp-Edmonds: Today we are joined by Jeff Nielsen of 3Pillar Global. First off, let me thank you for joining us today.

Jeff Nielsen: Happy to be here thank you.

Cameron: All right. Can you tell us a little bit about yourself and your role at 3Pillar Global?

Jeff: Absolutely. I am the senior vice president of engineering at 3Pillar Global which means I lead an organization of a little more than 500 software development professionals organized into roughly sixty teams in four different locations across the globe. At 3Pillar, we collaborate with businesses to create successful software products, build seamless customer experiences, and lots of other kinds of goodness related to software products.

I got a job as a software tester right out of high school. I grew up as a developer, tester, architect, and project manager. I was introduced to the ideas of Extreme Programming in about the year 2000 and have been an agile aficionado since then, both as a participant and then later as an executive in both consulting and product organizations.

Cameron: Fantastic. As an agile aficionado, you’re going to speak to us today about agile and about its role in 2015 to start things off.

Jeff: That’s what I understand.

Cameron: In your own words, what is an agile mindset or the agile mindset and how does it play into business decisions?

Jeff: Yes. “The agile mindset” is a concept that several of us have been talking about and writing about in the agile community for the last couple of years, and it’s really an attempt to describe this thing that’s at the core of what we’re calling agile software development.

If you look at how the agile movement started, it didn’t start with the agile manifesto in 2001, instead it was a bunch of folks trying to figure out better ways to do software development, each having different methodologies like Scrum or Extreme Programming or DSDM. The agile manifesto is really these guys getting together and saying "what is it that we have in common." And of course the document that we all know and love now—the canonical text of agile software development—the agile manifesto was an attempt to describe at a very high level this thing that we have in common.

What we’ve noticed as folks try to look at that and try to look at various agile practices, that you end up with a lot of people who have the form of agile but are missing the essence of agile. What is that essence? What is that thing that the values of the agile manifesto were trying to describe? That’s what I call the mindset. It’s really a way of thinking about how software development is most successful. That’s how I guess I’d characterize it—what’s your basic belief system about how software development works best. The things from the manifesto like individuals and interactions, and working software, customer collaboration, responding to change, those are all an attempt to describe this overall mindset of how you get the best software. Does that make sense?

Cameron: Yes. Absolutely. What does it take to achieve an agile mindset? You talked a little bit about capturing the essence. What does it take to get that agile mindset and how long should someone expect to take to adopt this frame of mind?

Jeff: That’s a good question and a hard one to answer because if it’s really about a way of thinking—about a belief system—and people don’t change their belief systems overnight. Our beliefs are built on our past experiences and our interpretation of our past experiences and people go to therapy for years to try to reinterpret their past experiences, of course.

In some ways, the answer is, it can take a generation if you really are talking about a shift in thinking. I’ve been in places where there’s been significant progress made in less time than a generation in helping people think about software development differently and what works. It takes repeated experiences with a new approach and with new things that you haven’t tried before you really start believing differently. I know that’s not a very satisfactory answer...

Cameron: No, it is, because it actually brings up my next question here. There are different shades of gray, so to speak, to an agile mindset. It is a process not a black and white, binary, zero and one.

Jeff: You’re not going to hit a day in your company where you say, “Oh, congratulations, everyone now has an agile mindset.” We necessarily come at these things when folks go to an organization and tries to adopt agile, they, of necessity, start with some specific practices. Because you can’t just hand someone a set of values and say, “Start believing this now. This is our new approach, just believe these four things.”

Cameron: Wait, that doesn't work?

Jeff: I haven’t found it yet. You get specific practices. OK, we think that the developers and customers should sit closer together. We think they should talk daily. We think you should work in these short time boxes. What if we talk about user stories rather than requirements?

You start with these specific practices and if you’re successful, people execute on practices a little bit on faith and then they start to say, “This actually is working a little better than what we used to do; why is that?” Then, that’s the kind of thing that can change a belief system over time. What you need is a whole bunch of people having a whole bunch of good experiences before the collective belief system changes.

I think the agile mindset is basically a belief that the best software gets created in a collaborative, iterative, trial and error type situation with lots of open communication, and lots of healthy interactions. You may or may not believe all of that, right? You may believe that, no, my most successful projects have come when we took a lot of time to specify up front and really think hard about what was needed before we started building. If someone has had some good experiences that way, you’re not going to convince them that, no, we don’t need an upfront requirements phase.

Or if someone has been burned enough times in the past by not enough testing, you’re not going to convince them overnight that we test as we go and we don’t need long test cycles at the end. It’s a problem in that way because you’re going to have different people with different beliefs, and they’re all trying to work together to get an optimal result.

Cameron: OK. Why really is the agile mindset an ideal mentality to have for taking enterprise to the next level? To really improving on what’s already been done?

Jeff: That’s a good question. A couple thoughts on that. You may have heard that we’re moving in to the age of the customer.

Cameron: Yes.

Jeff: This guy, Jim Blasingame,I think who wrote a book about that. This idea that for the first time in several thousand years the balance of power has shifted from the seller to the customer. The customer now has more information, more communication tools at his or her disposal. The customer is really in the power position.

One natural result of that is that you can’t get away with bad products anymore. As my boss, David DeWolf likes to say, for so many businesses whether you’re a software business or not, your software is your brand. It’s the primary way that you interact with your customers.

In this age of the customer, people aren’t going to put up with bad products. Bad software products can kill you literally in terms of your revenues and your reputation. The reason I think that an agile mindset is not just ideal but necessary is that it’s the only way I know to build great products.

You can build adequate, OK, decent products that mostly get the job done with some other mindsets, but the folks that I know that have built these really great software products all have what I would describe as this agile mindset. Enterprises have to figure out how to get more of that.

Cameron: In the age of the customer, it’s not enough just to be good, you have to be great and in order to be great, the agile mindset is the way to do that.

Jeff: Yes. I don’t know, everyone can’t be great, it’s like everyone can’t be above average.

Cameron: Right.

Jeff: Certainly, it’s a lot costlier to be mediocre or poor. I guess that’s the way I would characterize it.

Cameron: OK. Why is implementing agile methodologies challenging for enterprises and larger organizations?

Jeff: If we go back to again, what is the agile mindset? It’s a belief that you’re going to get good products by trial and error. By iterating quickly and learning as you go. Frankly, the bigger an organization is, the less optimized it is to take risks and the less OK it is to be seen as failing in some way.

You’ve got a five-person startup and everyone expects you to try some stuff and if it doesn’t work this week, we’ll try something out next week and we’ll just hang on for dear life. Your reputation doesn’t suffer because you’re a start-up. Somehow it’s less OK for a larger organization or an enterprise to be seen as having tried something and failed.

That’s one big challenge in terms of just adopting that mindset, really believing in that mindset. It’s a hard sell if you go to someone and say, “The way you used to do this where you figured out what you’re going to build and how much it was going to cost and you budgeted for that and planned for that on a year to year or bi-yearly cycle. You want to know the truth? What got planned in those sessions wasn’t actually the right thing to build.”

It’s a hard thing to say. It’s a hard thing to believe. If I put all this work into a plan, I’ve invested a lot of thinking and to believe that there’s something more to be learned—that there’s actually a better product out there that I can’t get to until I start--that’s a very hard thing to believe.

Cameron: With both internal and external perceptions, it’s almost a little bit easier for small organizations to adapt and implement an agile mindset.

Jeff: I think that’s true for a change of any significance. Large organizations develop a culture, they develop a way of doing things, and they become risk averse. They become, out of necessity, focused somewhat on preserving the organization itself (which is necessary). There are more people that want to be involved in decisions and probably more people that ought to be involved in decisions.

When we’re talking about learning quickly and learning as you go and making decisions based on new information, that just gets harder the more people you have. A great example of this is what happens with this practice of user stories which, if you’ve spend any time in the agile project, you’ve heard the term user stories.

User stories started out as this lightweight construct for communicating ideas and planning with just enough information to plan responsibly and to track. If you look at the way user stories get implemented in an organization of any size (in most cases not in all cases), it’s become just another requirements artifact. Instead of calling it specs, we call it stories. Instead of calling it tickets, we call it stories. We still have this multi-step process for getting a story written and approved.

Before you know it, you’ve ended up with a process that takes five steps and two months before something is approved for development. That’s an example of how we’ve adopted the language of agile, even the practice of user stories (maybe even Mike Cohn's template “As a <this kind of user> I can ... so that ...”), but what we’re doing—our behavior—exhibits this belief that we really need to go slowly and carefully.

I’m not trying to suggest that every large organization is slow. Just that there’s a strong tendency toward wanting to involve more people in decisions. It’s very hard to decentralize power the bigger you get. It’s scarier to be seen as taking risks and failing.

Cameron: Right. I’m glad you brought up the fact of more people being involved and more people having the ability to make choices because as agile grows both in popularity and adoption, do you think this will result in a team restructuring in the year 2015 as smart creatives inherit more responsibility.

Jeff: Certainly a lot of big organizations are experimenting with different structures and different ways of empowering teams. You used the term “smart creative,” which as far as I know comes from Eric Schmidt in his book about The Google Way, and he talks about how these folks that are both technically savvy and have some business acumen and are creative are really going to rule roost.

Cameron: Right.

Jeff: The way to structure a company in the age of the customers is really to push power down to small teams and let them go. I think Google is a great example of that. I think there are plenty of other companies that are good examples of letting stuff bubble up organically.

I think as companies experiment with that model of really empowering teams and how do we strike the right balance between empowerment at the team level and still having coherence as a larger organization. How do we budget and be responsible and accountable to our stakeholders and at the same time leverage this good thinking and great results that can really only happen best in small teams that are as autonomous as possible?

Cameron: Getting back to agile and its impact in 2015, how can businesses make agile a reality for 2015?

Jeff: Anyone these days that’s involved in software in any way is foolish to ignore the lessons of the agile movement. I think that the kind of things we’ve been talking about is getting people not just to do the practices of agile but really understand what is our corporate belief system, what’s our culture, what’s our belief around how innovation happens.

What I hope to see happen with agile is that it becomes less of a thing in itself and more of an enabler towards working differently and thinking differently. For an organization that hasn’t adopted agile and even a small scale, go out, hire a coach, try it. For organizations that have it working well at a small scale and are trying to figure out how to scale it, keep trying. This was a hot topic at the Agile 2014 conference: what is the right way to scale agile. I don’t think there’s one way or even necessarily one model that’s appropriate. Keep experimenting with that—with scaling and finding that balance between empowering teams and achieving overall coherency.

Cameron: OK. Jeff you’re a very well-respected expert in agile development and as you said earlier, an agile aficionado. I’m going to ask you look into the future here, in board terms, what do you think the future holds for agile both in 2015 and possibly beyond?

Jeff: One thing we haven’t talked about today, Cameron, is the DevOps side of agile and the DevOps movement that I see gaining tremendous traction. You’re familiar with what I mean by DevOps?

Cameron: Yes. Absolutely.

Jeff: This idea of automating not just the development process but automating the process of getting new code into production and the single push button. We’ve seen tremendous growth in that area over the last couple of years. I expect that DevOps will do for the enterprise what these practices like automated developer testing and continuous integration refactoring did for smaller teams.

I still remember the feeling of power I got on an agile team when I realized that I could go from making two or three changes an hour with a responsible code, build compile test cycle to multiple changes a minute with tools like JUnit and (in the olden days we didn’t have Jenkins,) CruiseControl.

Just as those tools enabled that cycle to speed up and enabled to feedback loops to speed up, I expect that DevOps will have that kind of effect on the enterprise. Because once you automate your whole process of getting new ideas into production, now suddenly you can put out multiple releases per day instead of a release every quarter or so (which was even good for a lot of enterprises).

Cameron: Right.

Jeff: That changes the dynamics significantly. As agile has been progressing along this dimension from smaller to bigger, which we saw early on in early 2000's, oh this is great for small toy projects. OK well this is great for small teams but it won’t work for larger teams. All right, this is good for small company but this won’t work for larger company. Now no one is saying it’s not going to work in a large company. 

As we progressed along that dimension, which I expect to continue in 2015, just kind of people cracking the nut on how you’re getting agile mindset in some large companies. Another dimension that I see is this dimension of going from practices that assume it’s super to change stuff. A lot of the agile practices like short iterations and lots of collaboration and trying stuff, those assume that the cost of change is low enough to make that feasible. Shifting from those agile project management practices to the agile technical practices like automated testing and DevOps, which are real enablers of a flatter cost of change curve.

I think early on, some of us were worried that “the project managers have taken over the agile movement” and we’d lost all these interesting thinking like from Extreme Programming. And I mean not lost it in individual situations, but lost it as a whole. I see that DevOps has brought a resurgence in the realization that if I’ve got these practices that significantly flatten the cost of change curve that I can work in totally different ways. I think that will happen at the enterprise level.

Cameron: OK. Do you think that more organizations will begin implementing agile?

Jeff: They might not call it agile. I think the numbers on adoption of agile practices are pretty staggering. Something like 80 or 90 percent of organizations are doing agile in some way. I don’t know if there’s that many more left at least to start agile adoption.

I think that if we go back to the original question about mindset, I think that once people realize that I’m free to make multiple releases in my software per day, that all the things I thought I knew about how to responsibly develop a product, well not all of them, a lot of them will change. I think a lot more people will adopt this mindset of trial and error and frequent iteration and collaboration and high touch. Here’s another way to think of that. If agile is an enabler, what’s an enabler for? You may have heard of the term design thinking.

I see agile as one of the key enablers of a company to execute on design thinking which is this intersection between, not solving a specific challenge, but improving your customer’s overall situation, gaining empathy for the customer, figuring out what our constraints are and then figuring out how to create an improved situation and improved experience at a micro and a macro level.

If you can get good at agile practices, that enables you to have a lot more of this design thinking permeate your culture whether you’re a software company or not.

Cameron: You think whether or not they officially implement agile, in official terms, that a lot of companies and organizations may implement an agile mindset, whether or not they realize it or not?

Jeff: Yeah. I expect it to go the same way that object orientation went several decades ago where it used to be a thing. We’re going to adopt OO now, right? You don’t hear people having OO initiatives anymore. It’s just the way that stuff is done.

I expect that to happen with agile. I expect it to become less of a thing, more of just a way that stuff gets done. We’ll look back and we’ll say, “Oh yeah, we’re working pretty differently than how we thought we ought to be working in the ‘80s or ‘90s.”

Cameron: You know, that’s a pretty good quote there. Agile is going to become less of a thing and more of a way that this gets done. I like that. That’s a good quote. Now, one final question here: In your opinion, is there an industry where agile has grown the most and is there an industry that’s going to be right for a widespread agile adoption going forward?

Jeff: You know I’d be hard-pressed to pick one industry that’s grown the most in terms of agile. Certainly internet companies, companies where their main focus was getting people to interact with software over the internet, whether that’s Amazon or Netflix, those companies obviously have been in the forefront of these movements and adopting agile and an agile mindset on a wide scale.

If I had to pick one that I think is right, I’d probably say government. I spent several of the previous five years of my life working closely in some federal programs. Talk about risk aversion there. One of the common things I’ll hear is, “We can’t operate the way those Silicon Valley guys operate because we have to be responsible. We are responsible for the well-being of the populace at large. We can’t just throw caution to the wind.”

I think that’s a little bit of a misunderstanding. Because when we talk about taking risks and being willing to fail, it’s not about taking risks that endanger people’s lives or that wouldn’t be responsible government. It’s about acknowledging that a lot of these things, that creating a better place, a better experience for our populace is about experimentation, is about trial and error.

Our traditional procurement processes in government, the decision making processes don’t let us iterate quickly enough to really create those optimal experiences. I’ve seen that change. We saw with the aftermath of healthcare.gov, some significant changes from the White House on down about the kind of thinkers that they want leading government IT projects.

I think that [the government] is ripe for agile. I know several leaders in the federal government personally and you’re going to see great things there [in the next few years] in terms of more an agile approach and agile mindset.

Cameron: Fantastic. That actually wraps up our interview today. Once again, this was Jeff Neilson of 3Pillar Global and he spoke to us today about agile and its role in 2015. Thank you so much Jeff.

Jeff: You’re welcome. Thank you Cameron.

 

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.