CTO Q&A: The Benefits of Driving a Successful Team Beyond Agile, Pt. 1 of 2

One-on-One with projekt202: CTO Rob Pierry

projekt202 Chief Technology Officer Rob Pierry
projekt202 Chief Technology Officer Rob Pierry

In the first of a two-part Q&A, projekt202’s Chief Technology Officer Rob Pierry discusses the value of keeping the right context and communications alive throughout the course of a development project.

Rob highlights the ways that businesses can benefit from creating a dynamic team focused on solving problems, rather than one that’s content with merely taking orders.

Let's pick up a previous conversation on the subject of moving beyond Agile. You talked about ways to more fully integrate design into Agile teams and drive research. Can you recap that for us?

Lately, you start to see some of the larger, traditionally more slower-moving organizations fully investing in these types of Agile transformations. Obviously, that's a good thing, moving towards agility, but what ends up getting lost sometimes is the fundamental idea of aiming before you fire. Agile is really good at helping you make small, incremental corrections to the direction that you're traveling in, but if you set off in the wrong direction in the first place, it's going to take you a long time to get all the way back to the true, productive direction that resonates in the market.

By starting with research, you're able to aim correctly in a direction that you know is going to be productive and that you know resonates with people, because you went out, you talked to people, you observed people, and you used behavioral science techniques to figure out what they actually wanted. Then you get this context and you don't want to lose it. To keep that context alive throughout the course of the development project, you want to make sure that that research and the design that's built on top of it – and, really, the practitioners of those respective crafts -- are included in your development teams as first-class members.

How would we use that in practice?

The typical way that we communicate with development teams -- to tell them what it is that we want built -- is through this vehicle of user stories. Oftentimes, that's all the developers have to go on. They look at a couple of sentences: "As a user, I want to X so that I can Y." I'm supposed to know everything there is to know about this problem right now. I think it's pretty obvious that that's kind of a poor communication mechanism because there is all of this context. When we were talking last time about research and design, that's context about user goals, user needs and aspirations.

What do the people who are using the system actually want? Also, as sometimes silly as it seems to sound, what stories do they tell themselves about themselves when they're using the system? Who do they want to be? Not just, what do they want to do? These are things that obviously lead to more compelling experiences if you take them into account. How do you document some of that stuff in a user story? "As a user, I want to X so that I can Y because I feel Z about myself?" That's kind of a weird thing to write down, especially in black and white.

How do you refine that into one user story with some acceptance criteria? It's hard to do.

I think one approach to that -- and something that we've taken and found productive -- is to say, "OK, that's not what, technically, user stories are for." User stories, like features or pieces of software, exist in a broader context. There's a background brief kind of thing. There's the rest of the system, if you're talking about a development feature, but fundamentally we say, "OK, there are broad, coarsely-grained types of information about the user context, about the business context, that the development team needs to be familiar with."

A lot of times, Agile likes to pretend that stories don't have any dependencies. All that means is that we end up not writing down the dependencies between stories. That doesn't mean that they don't exist. Someone is holding that context in their head, just like they're trying to hold in their head, "Users need to feel like they're mastering a complex skill when they're working with this or they're going to reject it because they need to feel powerful," or something like that.

Then what happens is you have this context for the user that's in a research findings document, or it's materialized in a journey map that you've hung on the wall, or personas that are based on objective observation rather than marketing story time, where you just sort of make up little slices of people. That becomes input to the development team as well, where in the past, they were just getting two sentences about, "Well, we need to build this thing," and that's your context for the project. It becomes this much deeper kind of understanding. I think what you find in this case is that's a different way of working.

"It’s not just user context that the development team needs. It's business context, so breaking down those walls between business and development is important as well."

If you're used to getting handed what to do, effectively being order-takers, that requires a different skill set than saying, "Here is the admittedly rough definition of the problem that we want to solve, and a bunch of context. You -- empowered, informed member of this dev-team working with your peers -- go solve this."

To me, that's the fundamental changing of the conversation that has to happen, admitting to ourselves, as business stakeholders, that we don't have the entire problem defined, or the solution even. We have a hypothesis about both the solution and the problem. Then we need to think about, if we accept that as true, can we build a team that can help us fill in the gaps, instead of building a team who is going to execute my will as communicated via iron-clad user stories?

This team is really good at taking user stories, doing exactly what they say, and producing the work from that, which means that all of the problem-solving is on the shoulders of the people who are writing those stories. From what you were saying, are those user stories fundamentally flawed when it comes to adding the amount of back-story detail that you need?

Yeah, oftentimes the people writing the user stories are somewhat removed from both the users and the business context. None of this is to say that those folks are doing a bad job or anything like that. They have certain inputs and they're producing certain outputs, but they only have some limited level of context in a lot of cases, so they're constrained about the job they can do.

Thinking about these teams, it's the nav-system driving you over the cliff thing. If you've built a team that stares at the GPS -- "It says to turn left. Here we go." -- and off the cliff you go. Obviously, that's not the kind of thing you want to do. You want people who are thinking about, "Wait a minute. Where am I trying to go? I also happen to know it's 5:00 and I'm in downtown Austin, so it's going to take me a lot longer to get where I was trying to go, and maybe there's an alternate route I could take. I happen to know somebody who knows this back way. Oh, and actually, I'm going to get on a motorcycle because it's going to be faster."

You want someone thinking about: the stakeholder has said, "Get to Dallas tonight from Austin," and you haven't said, "… and turn left, and turn right, and turn left," but we've got a team and we're sitting around thinking about, "What's the most effective way to do that, given everything?"

How do you build the type of team that will do that problem-solving, instead of taking orders from a user story or a business stakeholder?

I think some of it is setting out to build that kind of team in the first place. You really have to be honest with yourself about what kind of organization you are, and what kind of team you're looking for, because if you set out and try to recruit a team of problem-solvers, and then you put them in an order-taking kind of mode, they're going to leave. They're not going to be happy. It might take them a while to realize why they're not going to be happy, but they're not going to be happy.

"Culture is a hard thing, but I think it's one of the most important things as far as building effective teams."

Part of being able to support that kind of team, which is incredibly efficient and effective, is creating an environment where they actually get to exercise those skills. In some respects, that's the hard thing. A lot of times, that involves letting go of control. You have to say, "You know what? I don't have all the answers. I've got some good ideas. I think I've got some really well-founded hypotheses because I've got years of experience, judgment and a lot of business context in my head, but I don't know everything." That's a hard realization sometimes.

Trust like that doesn't happen overnight, either. How does that work? Does it start with one or two good team members that can start mentoring other team members?

Yes, I think it definitely builds on itself. The trust angle is a little bit interesting in that there's still this assumption that I'm going to have distance from the team. "I need to be able to trust you as the team member because I don't know what you're doing. I don't have any idea." It’s not just user context that the development team needs. It's business context, so breaking down those walls between business and development is important as well.

I need to be a part, as a business stakeholder. I need to be a part of this Agile team because I've got the business context. I can explain it to others, but it's in my head. That's my craft, just like the developer has a development craft and the designer has a designer craft. They're never going to teach me enough to be a designer, but I can learn enough through interacting with them to understand relevant constraints and motivations and stuff like that. When we actually collaborate, that's how you build mutual trust because I'm working with you every day.

It seems like it's about removing the roadblocks of those knowledge gaps and being more integrated in the team, so that everybody has that background they need to be the problem-solvers that you would want on that kind of Agile team, correct?

Yeah, you can sort of self-select for people who are biased in that direction in the first place, and then you need to arm them with the inputs that they need to be effective. You need to give them the freedom that they need to actually solve problems. You do find that it builds on itself. The more you do this, the more you have established a culture of this kind of behavior, so adding new people to it effectively indoctrinates into the way that you do things anyway.

That's just how it is. You come in and you're the new person. You sit down and just look around. You look at all these people questioning each other, and having these healthy dialogues, and you're like, "Oh, so that's how it is around here." That's something that we do really well, I think, but it's hard. Culture is a hard thing, but I think it's one of the most important things as far as building effective teams. You have to do that, but the rewards for getting it right are obviously huge.

Coming tomorrow: Pt. 2 of our Q&A with Rob

Stay up-to-date on projekt202’s news by following us on LinkedIn, Twitter, Facebook,YouTube and Instagram.