Agile projects are highly collaborative and involve constant feedback in tight cycles. This allows user expectations to be met while not wasting time on mere nice-to-have features or extra effort that doesn’t impact the business, but unfortunately we’re constantly hearing that it only works if your team is packed with top performers.

Is it true? Are the benefits of Agile reserved only for a tech elite, with the rest of us doomed to non-agile projects and missed expectations?

I have managed many software projects in my life. I transformed a global professional services organisation that delivered our software late and over budget to on time, on budget with excellent results using agile methodology. My biggest achievement was to develop a cargo management solution from scratch for a UK cargo handler that became a global solution and is run in more than 100 airports around the world. I understand the power of agile and I refuse to believe that it’s just for a tech elite: while having a team of superstars is clearly going to help, I believe that with the right awareness and management, you can get almost any team acting in a more agile and productive way. Here’s how you can create a successful agile team when you don’t already have an agile culture:

1)  Users

A key aspect of agile is that your users need to be engaged in order to get the most out of the project. This represents a cultural shift in many organisations where users have been trained to focus on their jobs and are unwilling to take ownership of problems or action items.

If you find users are avoiding taking on responsibilities, exhibit a lot of blaming or add delay and ambiguity to what seemed to be straightforward items, then they certainly aren’t acting in an agile way. As I’ve previously written, identifying and empowering user champions is a great way to involve users.

Users tend to struggle to become agile because it requires them to learn new behaviours: not only do people tend to resent this because they really feel that they don’t have the time (and vitally – don’t see it as important) but also because they fear getting it wrong and being exposed. This isn’t easy to address: it requires a concerted effort across all parties with strong management backing. You need to address:

• Time: you’re not asking users to be involved in an agile project for fun, but because it’s the best way to get results. This needs to be communicated not just to your users, but also to their management who need to support their involvement in the project
• Fear: ideally, find users who are keen to get involved; but also work to create the culture of learning rather than blame that agile requires, across the users, developers, management and any consultants
• Getting it wrong: as well as avoiding a blame culture, consider whether what you’re asking users to take on is outside their experience. It can be worth taking agile projects in small steps to start with, so you can complete a small, carefully bounded piece of a project and learn the behaviours before embarking on the next stage.

2)  Developers

Agile is a difficult mindset for users to adopt because they aren’t used to being so involved; but it’s also difficult for developers as they need to learn to ask questions, communicate, and care about users rather than technology. It’s not that they can’t learn these behaviours, but in some cases they may have to overcome long-standing habits in order to do so.

Typical warning signs from developers include being unwilling to pursue a roughly-defined solution or insisting on perfection; avoiding criticism; hating users or lacking communication skills and being unwilling to listen. Addressing developer problems tends to involve nurturing from management because again many problems stem as much from fear of failure as from unwillingness to engage.

Developers are used to working behind the scenes, free to focus on technology and only occasionally having to interact with users. Agile turns that on its head and forces them to work closely with users so:

• Perfectionism: developers are used to having the luxury of being able to refine and refine, adding more nice to have features, but in an agile environment they need to work to tight deadlines. Further, they need to interact repeatedly with users and get frequent feedback, which means that far less polished work gets reviewed. This is naturally stressful, and creating a blame-free environment where they feel safe just “getting it out there” is vital
• Focus on technology: developers tend to focus on technology because it’s what they know, so when you put them in an environment where they feel insecure, it’s normal for them to retreat to this area
• Dislike of users: Many developers lack empathy for users, even if they don’t actually dislike them; this is usually because developers see themselves as part of an elite group and see users as Luddites who go out of their way to misuse or break technology. The good news is that your individual users are rarely that bad, so with nurturing management you’ll often find that putting a developer and user champion together will overcome these reflexive habits
• Poor communication skills: It’s true that developers can lack communication skills, but this doesn’t mean they can’t develop them. If your developers are willing to engage but lack skills, a little training can make all the difference.

3)  Management

It’s not just users and developers who need to learn new behaviours: if anything, there is an even larger change of mindset required from managers who need to evolve from a command-and-control approach to being hands-on, involved in the project and caring about value and broad outcomes. Not only that, but they need to learn these new behaviours while actively managing and nurturing the users and developers as described above.

Of course, if you’re trying to develop an agile team, you also need to look out for and try to improve these behaviours in yourself as well. The biggest challenges facing managers are:

• Hands-off management: agile teams require active management participation, not just championing. You can’t just set objectives and let the team work towards it: agile requires constant feedback from all sides and adjustment. Management needs to be involved, caring and nurturing, especially if you are trying to create an agile team
• Unwilling to delegate: on the other hand, agile teams can’t cope with managers who insist on taking every decision themselves. Agile requires not just accountability but responsibility to be devolved, so you need to make team members accountable for delivery and give them control of the resources they need
• Focus on budget and metrics: we all know that budgets and metrics are important, but in an agile team it’s vital that you take a broad view of objectives. Also, for an agile team to be successful, you need to set clear priorities and deadlines; acknowledge tradeoffs and be willing to get right into it and find what really matters
• Mind games: In traditional environments, some managers find that rewarding internal competition encourages teams to work harder and deliver. That works when separate teams are following different workflows, but in agile you’re trying to get everyone working collaboratively and openly: give teams an incentive to be ruthlessly honest rather than ruthlessly competitive
• Promoting the wrong people: Returning to the advice on users and developers, when you’re building an agile team you need both your team and project to be championed by people who genuinely want to learn new methodologies and domains.

4)  Consultants

If your project involves third party consultants, you need to ensure they fit in your new agile environment as well. You always need to watch out for cultural differences but again try to get their buy-in to the way you’re trying to work and nurture them to feel like part of the team.

• Emphasis on code volume: this is a normal behaviour that has been learned from most projects the consultants have undertaken; not only do most customers focus on this but it also makes an easily measured metric. You, with your agile project, are a more advanced customer who is more focused on building the right thing, so create a supportive, nurturing environment that will encourage them to embrace your new way of working
• Unwilling to listen: agile projects require constant communication and frequent feedback, so you can’t afford to have consultants who won’t listen. It’s harder to handle this with consultants than your own people, so watch out for these behaviours when choosing them in the first place
• Too compliant: many consultants are only too happy to do more for their customers, and while this is good, it’s not ideal for an agile team. Because agile requires realism and close adherence to what’s been agreed, you need your consultants to be able to say “no”, to deliver bad news quickly and help find solutions, and to make realistic commitments. Create an environment where you reward the behaviours you want and nurture the consultants towards them; again, management needs to be hands-on and proactive.

Although we hear that agile projects are for the technology elite because of their highly collaborative nature and constant need for feedback; I believe that these behaviours can be learned and developed. It needs a great deal of patience and emotional intelligence from management, and a willingness to learn new behaviours from your users, developers and consultants, but it can be done.

By @DavidAkka