Ok, the title is a bit of a lie, but I had to get your attention somehow. (With attention spans what they are today, you need all the cheap tricks you can get to keep ’em reading.) Scaling agile isn’t easy and there aren’t really 7 steps, but there are a few techniques, mindsets and practices that can certainly help. Here are some of the no-brainers I’ve used on large-scale agile programmes. They’re guaranteed to work. No seriously. Or your money back. Actually, scratch that  – I’m keeping the dosh.

1.  Get business involved

Sounds easy, doesn’t it? You would think that business would be champing at the bit to be involved when there is a lot of money on the table, but from my experience,  this is always one of the most difficult parts of the process. Business and IT are traditionally not the best bedfellows. They don’t seem to ‘get’ each other. Business just wants their ideas implemented and can’t understand why IT has so many problems with this. IT understands the tools and the limitations and doesn’t understand why business would want their ideas implemented in such illogical ways. Mostly the breakdown is in communication between the parties. Usually there’s a very lengthy and boring scope document  bandied around somewhere the purports to state the exact solution as envisaged by the business. The document is the law. According to the business, it’s very clear what they want. Easy, they think. We’ve spelled it all out for you. Yeah right, thinks IT, as they read it and try to figure out why the business is telling them how to implement the solution. It doesn’t make sense, they rally.

Make sure you get them to work together. In the same room. At the same time. All the time. I know – it’s ridiculously basic,  but it’s often the most basic things we overlook.

A second issue that you may face with business and which is almost the polar opposite the previous point, is that often in large organizations there are so many business people with their fingers in the program pie that you just can’t get consensus on any decision and work can stop for days and weeks on end while much deliberation and pontification occurs. Traditionally the way to resolve this in agile is that there is only one Product Owner per team who makes the decision so the team can keep working at optimum pace. However, you may need to compromise on this and instead set up a small team of people that can represent the interests of the various business units or divisions deeper into the organisation. Just ensure that they all get along and are able to speak with one voice.

2. Get the right people

Getting the right people is more than just finding people with specific technical skills. Yes, of course, that is important, but it’s only one part of the story.  Probably more important for teamwork is finding people that are compatible. A useful exercise  you can do is to make an inventory of the Belbin Team Roles by getting your teams to do the behavioural test. A Team Role is defined as “a tendency to behave, contribute and interrelate with others in a particular way.” It can help you understand the mix of personalities in your teams, what sort of strengths and weaknesses are present as well as how the dynamics will play out.

It’s not often though that you have the luxury of choosing the perfect blend of people. More often than not you need to work with the team that you already have. Use as much EQ as possible (either yours or someone else’s if it’s not your strength) to mix the right people together. Then let them work themselves out as much as possible. Try to avoid swapping people out between teams too quickly or too often. People need time to adapt to each other and often issues between team members will work themselves out if they’re given the right support and facilitation.

3. Autonomy, Mastery & Purpose

Dan Pink wrote in his book “Drive” that autonomy, mastery and purpose are what really drive us, not the traditional carrot & stick. We want to be given the trust to work things through by ourselves, not to be dictated to by people so far removed from the work that they don’t even see how bad their decisions and orders are. We also want to get better at what we do, to master our trade and figure out better ways to do things. Self-improvement is the key to surviving in an ever-changing world. Lastly, but probably the most important of the three, we all need to feel that there’s a purpose to what we do, especially the work that takes up most of our time. If it isn’t meaningful, then what’s the point?

Don’t make decisions for your teams. You may feel compelled to, but it really isn’t doing anyone any favours. If the team makes a decision, they’re likely to be invested in the decision.  Provide many opportunities for learning, either informally or informally. Brown Bag sessions, workshops & hackathons can be very stimulating. Don’t forget the free food, though.   

Focusing on these 3 internal drivers will ultimately have a better effect than focusing on external outcomes, such as velocity, target dates, etc.

4. Provide servant leadership

The term servant leadership is all the rage now, and for good reason. If people are intrinsically motivated, and autonomy, mastery and purpose are so important, then the job of a leader is to provide the right platform and ongoing support to allow this. Autonomy cannot exist in a command and control environment. Trust your team to make the right decisions but always be there to provide them with the necessary support and input. If you’re coming from a strong Command & Control environment, this kind of leadership can be very difficult, especially when times are tough and deadlines are looming. Old patterns are easy to slip into.  But a good leader inspires the teams and when teams are inspired and have a purpose, good things shall come to pass.

5. Bake in continuous improvement

The 12^th agile principle speaks of continuous improvement by way of reflection. This is a very important principle and practise to instil early on as it helps the teams become self-reliant and less reliant on external training and input. The easiest way to start this process is through regular retrospectives for the team and one-on-one feedback sessions for individual growth and improvement. Make sure, though, that these sessions are action-oriented and that the teams hold themselves accountable for the actions coming from these sessions. Too often these sessions can be great for venting but don’t lead to significant change because proper plans are not put in place.

6. Nurture  your own culture

It’s really great to watch inspiring videos of companies following agile practises and doing really cool stuff, but ultimately you’re probably not a Scandinavian music streaming service and your culture may need to be quite different. Remember that there isn’t a “one size fits all” when it comes to company culture. Your organisation is made up of unique people and they will want to have their own unique culture that makes sense to them. That’s not to say that you can’t pilfer the best ideas from other companies, but just remember the square peg round hole thing.    

7. Provide on the ground support

You’re probably thinking, “like, duh!”, but it’s amazing what companies think they can get away with when it comes to large-scale change! Most people underestimate the sheer amount of engagement that’s needed to make a successful change. You’re going to need coaches embedded in each feature team as well as people working across the programme to support the coaches and work with the executives on strategy and programme and organisational design.  Remember that your coaching team should also complement each other well to play on each other’s strengths. The Belbin Team Role Inventory can work here too!

Conclusion

I know that it’s a bit of a simplification to say that you can follow these 7 steps or principles and succeed at scaling agile. The truth is that every organisation is different and has its own unique challenges and so a generic model or set of steps won’t always work. But these points are some of the basics that seem to make the biggest impact. Try them out and let me know what you think.