Are Your Teams “Wired for Agile?”

Agile "out of the box" looks easy. Heck, it is easy. Take Scrum: a light framework (three meetings, three roles, three artifacts) within which teams self-norm. Form a team, plug 'em in and let 'em go…success! And the business side of the house and organizational leadership just kick back and reap the benefits, right?


Wellll…no. This approach belies the social and, frankly, psychological complexity in making the move to highly functioning Agile teams and Agile organizations. If you've tried the simplistic tools/processes-based approach, you've most likely struggled or enjoyed, at best, limited benefits of Agile (the "qualified success"), whether you or your organization is aware of it or not.


When I conduct trainings or speak to groups about Agile and Scrum, I'm often asked questions like "if I have a good traditional project manager, will he/she make a good Scrum Master?" or "what kind of personality is 'right' for Agile?" These are insightful questions to ask, because the reality is Agile is not right for every personality, and not every good traditional project manager will make a good Scrum Master. For that matter, I think the reverse is often true: a team member floundering in a traditional project structure or an underperforming traditional PM may thrive in Agile. The key is digging past the nuts and bolts of Agile – the roles, meetings, artifacts, tools, and processes – into the values and beliefs shared by highly functioning Agile teams and organizations. Then, you have to decide whether your team members and organizations have, or even want, to embrace those values and beliefs. In this multi-part series, I'll be doing that deeper digging, and looking at what it really means for teams, Product Owners, Scrum Masters, and ultimately organizations to be "wired for Agile." In this first installment, let's look at the team level.


At its core, this is about the values and beliefs of team members. Your values and beliefs define how you interact with the world around you. They drive your assessment of which activities you find helpful in your workday, which you identify as impediments, and ultimately why I can present the same process to two different people, each will rate its value very differently, and they'll both be right…because it's subjective. Life coach Tony Robbins, in his series "Personal Power," talks about values and beliefs as being the drivers of your behavior. He teaches that your values define what's important to you: success, love, freedom, simplicity, transparency, etc. Your beliefs, then, are tests of whether those values are being met. Ask someone to state something they value, and then ask them "how do you know you have <the value>?", and they'll tell you the underlying belief. This is how two people can have the same values, but wildly different beliefs of what it means for those values to be met.


Take the value of Success as an example. Tony uses this example in his series. He had two attendees at a conference that both stated they value Success. When asked if they were successful, the first attendee, a corporate executive, surprisingly said "No." His definition of a success was a litany of criteria: you had to make $1 million/yr (he was something like $50k below that), you had to always be positive and never be down or depressed. The list went on and on. Tony asked the other attendee if he felt successful and the man replied with an enthusiastic "Yes!" How could he tell he was successful? Easy: he said "well, I feel that every day I'm above ground is a successful day. So I wake up, look around, and if I'm above ground, I'm successful." We see two very different belief systems feeding a shared value.


So how do we apply this to building a team "wired for Agile?" It takes more than just a cursory glance at the Agile Manifesto, but that is a good place to start. Even though the Manifesto says "…we have come to value…" what follows (Individuals & interactions, working software, customer collaboration, responding to change) is a mixture of what I term as "Ends" values (goals) and "Means" values (methods). They're not all exclusive to Agile teams, either. Waterfall PMs value the "Ends" value of working software too, for instance. But a "Means" value of customer collaboration – interaction – over comprehensive documentation won't likely be shared by lovers of documentation, as I noted in a previous blog. We have to sift through the Manifesto and then do some further digging for "Means" values that highly performing Agile teams should embrace, and what beliefs would need to be present for people to be happy working on those teams.
Here are just some of the values you should look for in choosing people for an Agile team:

1. Collaboration: Effective Agile team members don't work in their own silos. They talk to each other, and the Product Owner, frequently. A former instructor of mine described programmers as "sitting alone in a dark room, growing mushrooms all day." Potential team members that prefer to spend 8 hours a day, every day, alone on their own tasks may not be the best choices for an Agile team. Ideally, you're going to colocate these team members. So look instead for people who value collaboration, and favor face-to-face communication over channels like email, instant message, or phone.
2. Adaptation: Some people get very uncomfortable with change. These are people happy with predictability in their daily work. The antithesis of this might be the person who gets bored being on a maintenance project. Look for people who value adaptation, and express a belief that goes something like "I'm adaptive if I'm able to – and maybe enjoy – shifting direction quickly in response to changing conditions." If they get bored with routine, that's also a good indicator that they're right for an Agile team.
3. Autonomy: This is a concept from the Self Determination Theory in psychology that addresses our "…universal urge to be a causal agent of our own life." In other words, "having the freedom to make your own choices." This is an important characteristic of Agile team members because we want to set the goals for them (the prioritized Product Backlog), and give them the autonomy to decide the best way to achieve those goals. But the team must still be on the hook to deliver business value, so with autonomy must come a sense of responsibility. "I like to be left alone" is not enough to tell us if a person has the right beliefs related to autonomy. Someone who says "just tell me what you want me to build and I'll build it" seems to value autonomy, but likely doesn't believe that responsibility goes with it. Keep that way of thinking off your Agile team.
4. Transparency: On a properly functioning Agile team, there's nowhere to hide. We hold daily standups where team members talk about what they did since yesterday and what they will do before tomorrow. Teams share work in progress with the Product Owner, at whatever stage it's in. We post our progress, or lack thereof, in clear view for any passerby to see. This can be difficult, and is not for everyone. It's about daily accountability. Look for someone that favors true, honest transparency and defines it in terms of sharing daily successes and failures throughout the process. (NOTE: you have to commit to making it safe for them to share the failures). If someone tells you that the hardest thing about Agile is having to say what they are doing on a daily basis and how long it will take, they are unlikely to be happy on an Agile team.
   
5. Teamwork: It's an overused term, but important in Agile. There's no such notion among Agile team members as "you failed your sprint, but I succeeded in mine." Here, you want to look for people that define teamwork as "doing whatever I need to do to help the team succeed." You want to seek, for instance, a developer who wants to help the testers test if they're behind and the developer is available. Avoid the "it's not my job" people here. In addition, look for people who like to be sociable with each other to at least some degree. These folks will spend a good amount of time interacting. If they enjoy each other's company, it will make that interaction much easier and more likely to happen.
   
6. Efficacy: This can be a tricky one, but let me explain what I mean. In the field of electrical lighting, efficacy is defined as "the amount of energy service or useful energy delivered per unit of energy input." In Agile, we place high value on reducing waste and spending as large a percentage of your time as possible adding value to the product. So look for someone who has an aversion to "Process at the expense of Product." This might be someone that dislikes going to a lot of meetings in which they just sit and listen, or dislikes heavy overhead processes that take them away from developing for a significant amount of time. Avoid people that tend to call these type of meetings, even in spite of the effectiveness of the outcome. They may be overly favoring process.
   
7. Simplicity: To maximize efficacy, it is wise to seek the simplest solution to a problem. People who fit this value should be easy to spot in design meetings. They'll be the ones likely, as I say, "clouding the issue with logic." Again, this can be a fine line to evaluate in someone, but people who like to spend an exceptional amount of time in elaborate design before beginning development may end up feeling pressured on an Agile team that values simple approaches and learning as they go. The adaptive approach is also known loosely as the "ready, fire, aim" approach. Tom Steele has a nice blog explaining this phrase over at the Scrum Alliance.
   

As I said, these are just some of the values you could look for to build a successful Agile team. I would very much like to hear yours. I welcome your comments.