This is the first in a series of articles on agile development. Here we focus on SCRUM and how it can be implemented in an agency environment, considering some of the potential issues and how to overcome them. Dividing teams and skill sets are key, together with client buy-in and sticking to a framework.
What is agile?
"Agile development" means different things to different people. For starters it depends on the type of software you are developing, the environment you work in and the team you have.
Agile-like practices can be traced back to as early as the 1950s however in terms of software development it found popularity in the early 2000s when the Agile Manifesto was published: http://agilemanifesto.org/
It provides an alternative to the traditional waterfall method where fixed scope projects are worked on in stages until the project comes together in completion at the end.
This is all very good and looks okay on paper, however in practice it has some pretty major downsides.
More often than not the project is released to the client at the end of each stage in a 'big bang' fashion resulting in a disconnect between what the client asked for and what has been produced.
Furthermore, internally it creates silos between teams and makes collaboration harder. On top of this learning outcomes can only truly happen at the end of the project, which often span many months between start and finish.
Agile development on the other hand focuses on the completion and shipping of features over much shorter time frames and works in a more iterative way.
The beauty of this approach is that within each iteration there is a chance to stop, learn, re-plan and ship a feature or set of features.
The key characteristics as described by the Agile manifesto are:
- Review and improve regularly through iterations
- Focus on delivering completed features each sprint
- Allow for customer collaboration
- Have the ability to respond to change
Should be fairly straightforward to implement within an agency right? At first glance, yes. But once you start to run these processes you will soon find some problems occur. Just to name a few:
- Work often gets changed mid-sprint
- There is a lack of Involvement of the client
- There is trouble dividing teams effectively
Here are some tips on how to go about addressing them.
Problem one: Work gets changed mid-sprint
Let's face it no matter how well organised and good at planning you are, trying to service multiple clients at once is difficult and agencies are hectic places.
Often a client will get in touch with an "urgent" requirement that you need to deliver or the boss will come in mid week and railroad the best laid plans. This is inevitable and can be accounted for with Agile but before we get to that a few notes on the unmovable goal posts of Agile.
In SCRUM, each team commits to a fixed amount of estimated work over the duration of a sprint. The goal is 100% completion and the team should always strive for this. Agile is about flexibility but remember, it is not a free for all. In fact the very success of a sprint pivots around one main concept: a fixed amount of work each sprint.
The key here is to get into the habit of adding new tasks to the team’s backlog (for future sprints), not shoehorning new work into the current sprint.
This comes by using a combination of discipline by the agency's internal stakeholders and client education (covered later on).
Once the client and team understand that everyone is more effective when following this simple rule then the team can really begin to gain traction.
While this is great in theory and should always be the preferred method, you have to be realistic and change happens. Therefore as a mechanism to account for this there is a simple method: if something is added to the sprint, something of a similar size must come out. This should be discussed with the team and any client expectations should be reset. This should be reserved for special circumstances.
Problem two: Client involvement
This is a simple point but often forgotten: the client must be involved. It’s all very well introducing a new way of working internally but ultimately the success of any agency requires the involvement of the client. In fact in this respect the client should be seen as an extension of the team. At very least they should be educated on the concepts of agile and why it is beneficial to them. They should feel like they are part of the process.
The great thing is that if the client has a say in what is worked on in each sprint and has been actively contributing to choices throughout it they will feel empowered, listened to and most importantly have collaborated on the work itself.
There is no big reveal at the end where the client inevitably turns around and points out “that’s not what we wanted”. It will also give the internal team an understanding of what the client is trying to achieve and break down any divides there.
In short it can only serve to build the relationship between client and team and avoid any common layers of separation between employees and clients. Most importantly it will make for a much better deliverable at the end of each cycle.
Problem three: Dividing into the right teams
Size of team
In order to deliver ‘thin’ slices of functionality it makes most sense to divide teams into small units. So for example if an agency is operating with a bench resource model where all staff are assigned to work on a daily, weekly, monthly basis this will mean a bit of a change up.
One of the main reasons for this is effectiveness of communication. Take the daily stand up for example. It is much more practical for example for 5 people to talk through a work stack that applies directly to them rather than 30 where only some information is relevant. So regardless of the size of the agency (unless you are very small - i.e one team) then you will need to split out into smaller units. Anything between 4 - 8 is about the right size.
This brings me to my next point, how to split the teams by skill set?
Going back to the traditional agency structure it is common to divide teams by discipline: e.g backend developers, frontend developers, designers etc.
While this might make sense in some respects it isn’t always the best approach for Agile. If you think back to the waterfall model you can see why this type of split is so common. The designers might decide how the UI will look and function, they pass it onto the backend developers who build the underlying system and customisations, it then gets passed onto the frontend team to skin.
The problem with this is it not only creates silos and a divide between teams through lack of direct collaboration and empathy for each others job but it also makes for disparate delivery of each project component which is obviously not good for overall continuity.
Therefore a very good way to split teams is by having representatives from each discipline within each team. This means that any given team is capable of delivering a complete feature which may include a prototype, custom built backend and fully functional frontend without any reliance on other teams within the business.
The kicker here is that now we have true interdisciplinary collaboration, an understanding of what each person is up against and this creates the space for teamwork and excellence.
While having mixed discipline smaller teams is great it does not come without trade offs.
Traditional agile teams typically work on one project. Within an agency inevitably there will be a need to service more than one within each team, at least at some point in time.
This comes down to basic agency logistics: Maybe some clients don’t have enough work to occupy a team for an entire sprint, maybe a project rolled over and now needs to be work on in parallel to a new one. If a project is big enough, sure one team may handle it but it is good to be set up to handle multiple clients within each team.
This can be handled with some good sprint planning and a solid understanding of deliverables needed at each iteration. Work can then be shared amongst the team, the hidden benefit here is that people get to know their team’s clients, build a loyalty to them and of course a deeper understanding of each project.
These are just a few challenges that may arise when implementing agile within an agency. The typical agile for software isn’t 100% applicable within this environment however with some tweaks it can be harnessed as a great way of working.
In a world of fixed price and fixed scope projects it is important to think not in absolutes but rather ‘how agile’ each agency process can or should be.
Even in 2018 some twenty years after the Agile Manifesto was written it is still a challenge to the traditional way of working in an agency and with that will come elements of resistance be it internally or from the client. Education is key.
Next time we will look at the agile sprint format in more detail and how it can run effectively within a digital agency.