Many (many) years ago, when I first started learning how to shepherd designers, developers and testers, my mentors taught me in the ways of Waterfall Project Management. It was the done thing. Design it, build it, test it, release it. We all know the inherent problems that Waterfall brought with it, especially within a Digital Agency environment so I won’t trawl through them here.
However, it’s important to mention that, frustratingly, there was a resistance from my superiors to change the process at that time – even though the evidence that it wasn’t working was compelling. In the end I pushed through some nuanced changes to my own projects to make them more customer-centric, but the support for that sort of change wasn’t great.
Jump forward a year or so and there was talk of a new kid on the Project Management block. The word Agile was being bandied about by a lot of my peers, and details about it started to appear more often in project management circles. The rest as they say is history, and the likes of Scrum, Kanban, and Lean methodologies have seen a huge rise in users over the likes of Prince2.
There are thousands of articles out there regarding the benefits of all of these flavours of Agile. The majority of them relate to software development. The challenge however is trying to harness the plus points of Agile within a marketing agency environment (as we are doing), an area that is very rarely talked about amongst the Agile community.
The ways and means of applying Agile techniques to marketing is for another article; my purpose here is more to warn against following the rigidity of their processes when they simply will not work for you, and more often than not that is when you want to utilise Agile principles, but not for software development.
The Business Analyst Times cited the movement from rigid Agile process to a more relaxed approach as the top project management trend for 2015*. This to me signifies a really positive change in attitude.
I have had experiences, even very recently, where deviations from a formal Agile process have been discussed and frowned upon by so-called “Agile Purists”. However the reality for a lot of us is that the likes of daily scrums, dedicated teams and fixed time boxes cannot be adhered too.
Moving forward, we need the Agile pioneers (among which we like to count ourselves) and trainers and owners of the current frameworks to embrace flexibility and support evolution of Agile for different types of users.
My view: let’s not be afraid to push the boundaries – and apply a tailored Agile approach that fixes our business problem, not try and shoehorn the problem to fit the Agile approach.