Increasing numbers of businesses are on the path to becoming ‘Agile’, and yet they often find it hard to envision how Agile principles will translate in the day-to-day running of an optimisation team, particularly if they are in the process of building this team anew.
Who should be involved in an Agile optimisation team? What core principles should be applied? Can this actually work for businesses using an external optimisation service provider?
Chickens and pigs
You’ll often hear Agile Coaches semi-jokingly referring to their team members as chickens and pigs (whose work outcome is – take a guess… Ham and eggs!). In this context, chickens refer to team members who are merely ‘involved’ in the realisation of a project (such as Project Managers and Business Stakeholders), as opposed to pigs who are truly ‘committed’ and without whose contribution the project could not be achieved (Developers). The unequal levels of ‘self-sacrifice’ required of these two profiles in order to produce results, illustrate the various layers of stakeholders engaged in Agile project management.
Ham and eggs aside, insofar as your Agile optimisation team members are concerned, you should aim to have a mix of Developers and Product Owners whose respective contributions will be to develop and verify tests for the former, and to ensure that these same tests get delivered in a timely fashion and with the expected level of quality for the latter.
On the Developer side, you should therefore have developers capable of comfortably carrying out front-end changes using CSS and JavaScript and testing their validity. On the Product Owner side, you can have people coming from a variety of roles, from product management to data analysis by way of marketing. Finally if you have the luxury of having someone in your business acting as an Agile Coach or Scrum Master, you might want to get them involved at least in the early stages of your Agile conversion. They will help instil the right habits and mind-sets into your team.
It’s a Sprint, not a race
There are lots of different interpretations of what applying Agile actually means depending on who you’re talking to. The Agile Manifesto and Eight Principles of DSDM (Dynamic Systems Development Method) will give any Agile newcomer a solid framework to start from. Getting in the habit of recording ideas in a backlog of desired features, as well as organising your work cycle in 2-week ‘Sprints’, will get you in the habit of delivering incrementally rather than undertaking huge projects that might never come to fruition (or do so once it’s too late).
Whilst you should always aim to achieve agreed goals by the end of a Sprint, what’s most important is to never sacrifice on quality. It’s better to deliver a feature which is minimal but works well rather than doing a rush job so that said feature ticks all the boxes in your initial requirement list at all costs. This example is a good illustration of the concept of MVP (Minimal Viable Product) which is so important in the Agile world where dynamicity is key.
However, let’s avoid making a common mistake here: dynamicity doesn’t mean lack of commitment. Agile is not here to provide excuses for not delivering. It just recognises that (bad) surprises might get uncovered along the way; hence priorities might have to change. Ideally this risk should be minimised by ensuring that all backlog ideas that find their way into a Sprint cycle have been ‘shaped’ prior to being accepted into the Sprint, i.e. that their technical feasibility has been assessed and team members have agreed that they had everything they thought they needed in order to deliver this item at the end of the Sprint.
Last but not least, Agile relies on team members communicating with each other constantly and as directly as possible. Daily stand-up meetings where team members recap what they did the previous day, what they’ll be doing on that day and whether they are facing potential impediments are common practice. As are Retro meetings where team members debrief what went well and what could be improved from the last Sprint cycle. Finally, Sprint Planning meetings will give the team an opportunity to agree on what the next Sprint’s goals should be and how to prioritise them.
The operative word is ‘team’
If you plan to use (or are already using) an external optimisation service provider, you might wonder about the angle to adopt with regards to their relationship with your in-house Agile optimisation team. Drawing from personal experience, I think the best way to ensure success is to make your provider an integral part of your Agile team.
You will have to put aside traditional client/service provider vertical hierarchy (“I am the client and therefore you shall do as I ask without question”) and adopt a horizontal collaboration model where everyone’s opinion is valued and valid. This means your service provider will also have to make a commitment to your new Agile model at their end, but the rewards should be increased productivity and a richer professional relationship for everyone involved.
