Some while back, I was invited to a meeting with two people who worked within that area called “Human Resources”. To be fair to the individuals concerned, neither of them ever referred to people as “resources”, and indeed both of them showed an uncommon desire to learn about what really worked in companies and projects. However, the conversation started as many Agile conversations with HR often do.

“We understand that the IT department is transforming to Agile. What training courses would you recommend?”

Apparently this is the way that many methodologies and practices – including Waterfall, Prince 2, and most lately Scrum – have been taught. I’ve only found one company who managed to successfully transform to a Lean / Agile way of working from a few Scrum courses run by Martine Devos, and they did it because their culture was so well set up for it. No other company that I know of has made a transformation to Lean or Agile without significant external help. Dan North has previously compared companies who can’t deliver software, and are wary of external help, to patients too shy to tell the doctor about their constipation. It’s a shame that we can’t simply say, “Don’t worry; take two of these pills and eat some prunes.” Agile isn’t something which can be taught in a couple of days. Really.

Still, they can make a good start. I outlined the things that I found worthwhile in an Agile training course. I provided some hints and tips for making the learning from those courses stick and ensuring that development is ongoing. I also provided a caveat that I’ve come to regard as almost a tradition. If you ask me to teach the people in your company Lean or Agile, I’ll also give them some basic skills to spread that movement and develop their skills further. I’ve not yet seen Lean or Agile survive without some champions on the ground, and one coach can’t do enough on her own. Furthermore, the basic skills I teach to spread the movement are related to life coaching. I will be training staff with the ability to look objectively at their projects, chunk their observations up to their personal values, decide on their goals, and match their lives to their goals accordingly. It helps them to leverage their passion; to make people care as much about their work environments as they do about watching the footy with their mates, coming home to their loved ones, or tucking their babies in at night. When you’re giving up forty hours a week to a profession, the opportunity to develop passion around that profession is addictive, and rightly so.

Often the people I pick to help make the change are those who are most dissatisfied with the status quo, and who want the change to happen. Even if I don’t help these individuals to help themselves, they usually find ways anyway – a little bit slower, perhaps; but just the knowledge that change is possible, and valued, seems to cause them to go out and seek new ways of doing things. Having a coach on the ground and an explicit mandate for change accelerates their desire to do something different and their acquisition of practices that will show them how. They tend to value principles over practices; they don’t really care which Agile toolbox we use, but they do value self-empowerment, transparency, honesty, care for one’s work and pride in the result, delivering real value, getting feedback and learning while they do it. They’re often the quiet ones, working tirelessly behind the scenes to make sure that a project succeeds; or the loud ones, vocal in their objection to existing practices which don’t help them to deliver. They’re usually the ones you want to keep, too, especially if the Agile transformation is going to succeed.

If you happen to be the kind of company who allows its goals to conflict with those of its staff, Agile training could be quite dangerous. If you want training in Agile, you are going to have to support your staff in adopting it. The skills they obtain will be hugely valuable within the industry. There aren’t enough people with these skills to satisfy industry demand. I browsed a couple of UK job sites over the recession and the Agile role demand dipped for about 3 months, 6 at the most. I hear that skilled professionals in the US haven’t been out of a job for long, either. Whatever gratitude your staff feel at being given the training will be weighed against your support of their new, tantalising, fun way of working; an assertiveness or curiosity which perhaps weren’t there before; and a disinclination to play victim to project management decisions when a different way of thinking could see them in control of their lives.

In other words, if you train your staff in Agile, you’re also training them to see through some of the aspects of business which don’t always make sense. These might include bonuses, yearly reviews, corporate standards, unreasonable deadlines, blame cultures, overtime cultures, unnecessary projects, unnecessary features, unnecessary management, unwieldy timesheet systems, holiday restrictions, cost-cutting on tools, cost-cutting on infrastructure, cost-cutting on coffee (never do this), awkward seating arrangements, lack of meeting facilities, dodgy third-party software, alienated offshore teams, command-and-control management, unconfident management, bullying… the list goes on. Of course no company can change overnight – but the only way to retain staff newly trained in Agile is to listen to their concerns and act on them.

Agile isn’t a mechanism for success, whatever you hear in the brochures. It’s a mechanism for making failure transparent so that you can adapt quickly, and it will show failure at many different levels. For companies who are genuinely interested in improving their ability to see difficulties emerging so they can respond, Agile is a godsend; otherwise, it’s a curse.

You can minimise the effects of Agile transformation by starting small – taking one team, and slowly growing the adoption – and this will give you time to respond. You will need to respond, or you’ll be fighting a tide of people leaving, and a growing number of companies wanting to hire new staff with Agile skills and passion. If you want to be ahead of the wave, keep the staff you’ve got. Talk to them. Find out what they most want from their jobs, once they’ve got a better idea of what’s available. Act on it. The average developer appears to have a frustration threshold of a few months, six at most, with testers and analysts not far behind.

You could, of course, resist transformation. Retain the old command-and-control structures, the change requests, the three-month documentation cycles. It takes longer to respond to change, and in many domains, change is happening faster and faster. Eventually someone will start to take over your portion of the market, differentiating themselves and responding to industry changes faster than you can. If a company wants to stay in business when technology, society and markets move so quickly, it is inevitable that teams will need to be empowered to respond to change themselves. Any such empowerment will bring the same transparency and the same problems that I’ve outlined here, whatever banner it comes under.

Failure is inevitable. It’s already happening. Companies who accept it can handle failure and adapt. Lean and Agile practices will make it visible more quickly and provide some mechanisms for turning it around. Traditional practices will keep it hidden until later. All you can do is prepare for failure and the problems that it will bring. Engage all the departments, including Human Resources. Be ready to change your metrics. Be ready to listen and get feedback.

Be ready to fail… because failing, and preparing for failure, is the only way to succeed.