Now with McKenna Consultants being born and bred in Yorkshire, it takes something special to give credit to someone the other side of the Pennines. But credit where credit is due, Sir Alex Ferguson is one of, if not THE, greatest football manager the game has ever seen.
You’re probably thinking where this blog post is going and “what has Sir Alex Ferguson got to do with Agile?”. Well, this week the October Edition of the Harvard Business Review has revealed his blueprint to success.
In this blog post we examine the key elements of his blueprint and think about how this can help us improve as a software development company.
1. Start with the foundation
“From the moment I got to Manchester United, I thought of only one thing: building a football club. I wanted to build right from the bottom… Winning a game is only a short-term gain – you can lose the next game. Building a club brings stability and consistency.”
Sir Alex wanted to be there for the long run. He understood that to create a strong, reliable club, or in our case software development team, he had to start at the bottom and get the little things right. We can relate directly to this in software when adopting Agile and trying to build a successful team. Successful software development teams are built upon a strong process, good team culture and in an environment where they are supported.
If you build your software team on shaky foundations, then you are destined to fail.
2. Dare to rebuild your team
“I believe that the cycle of a successful team lasts maybe four years, and then some change is needed. So we tried to visualise the team three or four years ahead and make decisions accordingly.”
Change is good. Even Sir Alex knew this. Great software development teams embrace change and promote change. When implementing Agile into a software development team, you are going to meet with resistance. People are not going to want to embrace that change. You need to train and encourage these people, and in some cases you need to re-build your team. In larger software companies, where are there multiple software development teams all working on different projects, why not shake them up on a sprint by sprint basis and move one person from each team?
3. Set high standards – and hold everyone to them
“Everything we did was about maintaining the standards we had set as a football club – this applied to all my team building, my team preparation, motivational talks, and tactical talks. I had to lift players’ expectations. They should never give in.”
Sir Alex Ferguson was all about driving quality. You should be too. The only thing that I feel is missing from the Agile Manifesto is that there is not enough emphasis on quality. The whole software development team should be geared around thinking about how to produce the best quality software. The biggest factor in software projects going over budget and missing deadlines is by doing things twice. Get it right the first time to highest possible standard. Now I understand that quality can mean something different to anyone. It could mean zero bug reports, no “lag” between screens, 100% unit test code coverage or all designs to “shiny”. Whatever your teams perception and understanding of quality is, put them in your definition of done and make sure that they are stuck to.
4. Never, ever cede control
“If the coach has no control, he will not last.”
Now I am going to be honest, I am clutching at straws when relating this one to Agile. However, we can draw some conclusions. Never, ever, let a software project run out of control. Yes embrace change. Yes allow the customer to change their mind, but do not let the project run away from you. A good Product Owner should be able to work with a designated Product Owner from the customer to prioritise changes and groom the backlog where they see fit. The last thing any software project needs is the whole team speaking to different members of the customer’s team making changes and building features in a “gung-ho” fashion.
5. Match the message to the moment
“No one likes to be criticised. Most respond to encouragement. For any human being – there is nothing better than hearing ‘Well done’. Those are the two best words ever invented. At the same time you need to point out mistakes when players don’t meet expectations.”
In Agile software development, communication is key. There are plenty of opportunities to hold “team talks” such as the daily scrum and/or sprint retrospectives. In a daily scrum, ask the team three questions:
- What have you do since the last scrum?
- What are you planning on doing next?
- Have you got any impediments?
In the sprint retrospectives, think about other issues with questions like:
- What has worked really well this sprint?
- What could we do to improve the productivity of the team by 1% next sprint?
Just remember to not go for the Sir Alex Ferguson hair dryer approach mind.
6. Prepare to win
“Winning is in my nature. There is no other option for me… All my teams had perseverance – they never gave in. It’s a fantastic characteristic to have.”
We are not in a football match, a tournament or a race, but we are competing against other companies, products and services out there in the market. As a team we have to win. This should be engrained in the teams culture. What constitutes a “win” to a software development team can vary from team to team. It could be hitting a deadline, coming in under budget, winning an award or achieve a gazillion downloads. Set targets are aim for them. Try to hit your sprint velocity each sprint and understand why you haven’t if you don’t. Learn from it. Produce a piece of software that you are proud of. Find out what winning means to you and your team and go out there and kick ass!
7. Rely on the power of observation
“Observation is the final part of my management structure. One afternoon at Aberdeen I had a conversation with my assistant manager and another coach who pointed out I could benefit from not always having to lead the training. At first I said no but deep down I knew he was right. So I delegated training. It was the best thing I ever did.”
What is the point in carrying on with doing something if time and again it doesn’t work? Agile encourages observation, visibility and the identification of problems. The daily scrum and sprint retrospectives, as mentioned earlier, are an ideal moment to raise your observations to the team. If you’re in a team using Kanban, limit the size of the started column, if it is full of user stories, then everyone can see that there is a problem. Draw a stuck column, again let the team see if there is a bottleneck occurring.
Problems do not magically go away, nor can they be swept under the carpet – they will come back to bite you! In Agile, problems are an opportunity to make changes to continually improve the productivity of the team.
8. Never stop adapting
“When I started, there were no agents, and although games were televised, the media did not elevate players to the level of film stars and constantly look for new stories about them. Stadiums have improved, pitches are in perfect condition now, and sports science has a strong influence on how we prepare for the season.
Owners from Russia, the Middle East, and other regions have poured a lot of money into the game and are putting pressure on managers. And players have led more – sheltered – lives, so they are much more fragile than players were 25 years ago.”
And now for Sir Alex’s final point – Never stop adapting. This is, in my opinion, the most significant thing about the whole Agile process. Change is good. Embrace change, encourage collaboration and communication, look for new ways to do things, inspect and adapt, ask yourself “how could I have done this better?”. The Agile process is filled with frameworks and structures to help the team continually adapt. Use the daily scrums and sprint retrospectives to help you grow as a team. New technologies are appearing all of the time, changing the development landscape of an almost weekly basis. Why not implement the same rate of change and improvement to your software development process too?
So there you have it. Sir Alex Ferguson, Agile Software Development Guru! Who knew?!