Lesson: Agile Development with Ian McFarland

Step #7 Culture: Agile impacts all aspects of your company culture

I had a long conversation with a senior person at a bank who was talking about Agile and their attempts to implement it and they did it only on one team. And the fact is, Agile has such a different life cycle from certain traditional waterfall life cycles. There was a lot of friction between that team and the other teams. Everybody recognized that that team was more effective but there was no way for that team to mesh effectively with the rest of the organization.

So, I mean, well-functioning Agile teams really transforms the whole way the business operates. It's not just the software development team. And this is again, when I left Pivotal Start before Neo, it was about being more holistic in terms of how we approach Agile concepts. I mean, we're doing design but also the way we run the business is much more collaborative, much more value-driven. I mean, it's very attentive to externalities and how those impact the business.

So it is a fairly fundamental mind shift and I think, how you, this is also true for Lean, obviously from a Lean startup, how you think about what to pay attention to in the business is really, fundamentally impacted by having collaborative teams, by having a trust-based organization. It's much flatter, it's much more collaborative, it's much more meritocratic. The fact is, there's no person in this organization who, if they have an idea, doesn't feel comfortable saying, "Hey, I think we're doing this wrong or I think we can improve in this way." This notion that ideas come from the whole organization and that the good ones get recognized, that's fairly fundamentally different. Well-functioning Agile organizations look really different from traditional top-down organizations.

Another thing that's interesting, you know, it feels like kind of a soft metric to care about but developer happiness, it turns out, is strangely correlated to developer productivity. This is true I think in general for smart, knowledge-worker type people. People actually tend to be the happiest when they are producing the most value. It's unclear whether or not this is true as you move further down the need hierarchy. In highly engaged people, if they're unhappy it's probably because there are things in their environment that are making them unproductive. So it's strangely a very strong signal if you have unhappy people then you have something that's creating friction in your work environment. It could be the quality of the tools they have, maybe they don't have the right equipment to do their job, but it's funnily correlated.

Of all the things to care about as a manager, it turns out, and I'm not saying just you need to have lots of volleyball, usually people are the happiest when they are engaged in meaningful work activities at work, and then again have their home life to do home life stuff. But it is actually a strong leading indicator of the quality of the culture that you have. The fact is the competitive landscape for high end talent in software development, in design, in all of the startup related spaces especially in the variate, but globally, it's a very competitive market.

You need as an employer to think about, "Am I creating an awesome work environment, a place that people feel welcomed, people feel respected, people feel valued for their contribution?" Which is not to say they should be slacking off. Honestly, you won't retain good people if the work culture isn't a rigorous one. People need to be producing results. People need to know that there is urgency to get stuff out the door and having that shorter cycle time helps them to see the productiveness that they're bringing to the game.

How you get the right people in the team is a really, really fundamental question for any startup, for any organization, because at the end of the day the quality of the product that you produce is really just the function of the people that you have in the organization and how you manage them and how you enable them to interoperate. But the critical piece is getting the right people into the organization. It's interesting, the longer that I spend in management the more I realize that all I can do is create a context, put smart people in it, and help them to actually find successful pathways through the world.

The critical part then is getting the right people in. Our hiring process is we'll use traditional methods to put out the word that we're looking for people. We'll post ads on Craigslist or various other places. We'll go to meet-ups. We'll talk to people. We'll talk about what we're doing. We have a bunch of smart people and smart people attract other smart people. Talking about the ideas and talking about what you do is a great way to get people engaged and get people to start to think, "Oh. This is an interesting place to work." Then there's a filtering process and the filtering process starts with, "Let's sit down and have coffee with the person." Sort of figure out if there's a team fit and a like-mindedness and if we feel like this person would be effective in the organization.

Next phase is once we feel like they're the right kind of person now we need to figure out fairly quickly do they have the capabilities that we want. Not just, are they people we'd like to be friends with and people we would like to have conversations with. But are they effective? In the software engineering space what we would do is a pairing interview. A pairing interview isn't necessarily what you would think. A typical hiring process is like, "Go explain something complicated. Tell us how you think through a problem." That's still useful and it still comes out of the coffee and various other things. But what we'll do is we'll actually sit down, pair a program with somebody, and what's interesting is that the interviewee isn't actually touching the keyboard at all. They're sitting there walking through the problem.

It doesn't even matter what language the interview is being done in, like what computer language. You're sitting there writing code and the first question is, "So we're going to test drive a set. Let's pretend that sets don't exist in this language that we're using. So what is the first thing we should do? What is the first thing that we want to know about a set? What assertion should we make about the set? Let's just start...” Then it's empty. Like when we make a new one that is empty, so we write a test for that.

Then we go through this process of what is the thought process that you go through to produce code? We're not worried about the mechanics. Are they able to type? That is not usually the problem. If that really is a problem it will come out when we actually sit down and do real work pairing with them together. The next phase is then to pair with them for a half-day on real code and really get a feel for how we work together. So it's actually modeling the thing for the outcome that we're trying to do. It turns out by actually working with somebody you learn a lot about how they work.

I think prior to this kind of approach I think every hiring manager has had the experience of hiring somebody and then knowing the first day that this was a real big mistake. So what we're looking for in the pairing interview is how does the person think? Can they communicate well? Can they advocate for their ideas? Can they respond well to criticism of the idea? I don't mean like attacking the idea but when there's push-back do they respond and engage in the way that you'd like to see in somebody who's actually going to solve real problems? So ultimately you're really looking for team fit and aptitude.

To me team fit and aptitude are the main things. Everything else is trainable. Everything else kind of comes along. Experience with software, again, languages change. So some of the best interviewees have been people who've never worked in the language that the interview is in. That's fine because they think through problems well. That's ultimately what to look for is the super-star people are good. In an Agile team it's not the rock stars. It's the collaborators who are really thoughtful and insightful but not such big personalities that they don't allow anybody else to exist. Because again ultimately what we care about is the throughput of the whole team not some star contributor who might be famous or brilliant but that destroys the effectiveness of the entire team.