Changing the culture of a business is hard and often it is even harder to find the right culture and balance for that business. But the difficulty in making that change shouldn’t be the reason for not doing it, in fact getting the culture of the business right will pay dividends.
In the last few years agile has become the nouveau approach to business in the technology sector. Everyone seems to know about it, everyone is doing it and yet no one really talks about it in meetings or tenders. What is the reason for that? Well mostly it is because they aren’t actually doing it at all.
Most of the criticism of agile is that it isn’t practical to use it in an agency, that the agency world moves too fast to accommodate the idea of fixed term sprints and dedicated development resources for projects just doesn’t work. This may well be true but how do you know if you haven’t tried? From my experience a lot of agencies seem to instead fall back on the commonly used methodology SOYP – Seat Of Your Pants!
The problem with SOYP is that what arises is a culture of conflict. Project Managers are constantly fighting for resource, the sands are constantly moving and projects run as smoothly as an Egyptian whisky. There is no real team ethic in this situation, only project managers out for themselves and their projects. The only way around that is to escalate your issue and then senior management get involved, in which case the only resolution comes down to who has the most influence. That is neither healthy nor helpful because at the end of the day the people who suffer are the clients and those delivering the work.
So how do you get around this? Well the answer is that you have to actually live the culture of your methodology, not just pretend to use it. At Siteset we use Scrum as our methodology. It has taken time to adopt this to the level we want but, now that it is really bedding in, the change is marked and everything runs a lot more smoothly. But how have we done it?
The first thing is that we changed the culture of the whole business, not just the project delivery team. The first step was to get the whole company to realise that Agile Scrum is about visibility and team work. Being a smaller agency we were able to first start with a weekly all agency stand up, where we share the news from the teams, any concerns and things we are working towards.
Step two was to change the way we managed project delivery. Instead of trying to run based on resources dedicated to clients and projects being owned by a couple of individuals, we changed to the Scrum approach where the whole team works to deliver for all clients. The challenge here is for the project managers, who then have to balance the amount of work in any given sprint for any given client. This is not that far removed from normal planning in the grand scheme of things, but instead of planning on a project level our project managers are now looking at delivery from both a task and programme level.
This might sound like chaos worse than SOYP, but actually the reality is very different for a number of key reasons. Firstly the days of project managers being out for themselves is over. They have a programme level awareness of what is required at any given time and become more invested in the higher level detail. At any point they all know what work is on the books and how many clients are in the mix. The second benefit is from the resource point of view. We no longer have individuals who own a specific client build, we have teams who have joint responsibility. This shared ethos means that no one person is a bottle neck and, although we have specialists, they can all work on delivery. This makes us a much stronger team with less reliance on individuals to succeed.
The culture of the whole team being responsible, bought in and wanting to deliver the best possible product for any client raises morale, raises the quality control level and it also increases the drive to succeed. Everyone wants every client to get the best possible result and on time, because none of us want to stay late and, like the true musketeers that we now are, we will all have to stay late if anyone stays late.
One of the key ways in which we are able to adopt this culture is that we don’t box people in. We specifically employ design developers, that rare breed of people who can design and write the code as well. We also employ back end developers who can write front end code and project managers who can specify and write code as well. So many businesses have people who are capable of blurring the lines of their job roles, but the business doesn’t want to recognise that and instead keeps them in their role. This creates bottlenecks as you have to wait for them to be available to do a specific job. You can’t do that if you want to be agile. Instead we look at what needs to be delivered, we brief the team and then they go off and do it as a team. Often this means pair programming, front end developers scratching their heads having a go at backend code, backend developers and project managers fiddling with front end code to make sure their functional work doesn’t look like a dogs dinner and everyone testing everything.
When it comes to the business culture and adopting agile, you have to live it, and we seem to be showing that it is possible. We were even finalists at the Agile Awards in 2014. It is not just about pretending to do it and adopting element of the methodology whilst ignoring what is key to it – a multifunctional multi-skilled team. Instead it is about recognising that people can operate outside of a ‘box’ and can gain skills in all areas. There will always be specialists, but that doesn’t mean they always have to be the one doing the work. At the end of the day, the team ethic will ensure that the product is excellent, so let the team excel by working as a team, rather than as battery chickens that only really care about when they will next get to go outside.