scrum team

Agile Marketing: Lightweight or a fuller approach?

Agile Marketing: Lightweight or a fuller approach? 780 441 nMerge

I have read many blogs, op-eds and articles on what Agile marketing is and/or should be. Most of which ties marketing operations to the Agile Manifesto and the 12 Agile Principles, positions marketing at the level of scrum basics or attempts to generate a new manifesto specific to marketing. This is a great start however I contest that Agile marketing as practice is much deeper and has more challenges than building a scrum team and just doing it… iteratively and learning as you go. So with this in mind let me cover off some Agile background to set context. The italicised section is an edited excerpt from an academic research proposal Ken Santoso and I submitted in 2015. What we discovered in the literature review phase of the proposal is that Agile as a practice and it’s relationship to User Experience (UX) design in particular, is under researched, is practitioner led through interpretivist case studies and experimentation and has opposing approaches to satisfying customer needs. What is of interest to the marketer is there are lightweight approaches and fuller approaches and the context for selection of the approach is very important. The following diagram illustrates different Agile methods and their approach.

Agile Umbrella
Source: https://www.mindmeister.com/443624561/scrum-study-guide-mind-map

My point will be that the fuller approach is more suited to Agile Marketing. This is because the whole ecosystem is developed for executive marketers through to executional teams to be Agile (irrespective of whether it is insourced or outsourced.) I position that scrum and it’s light weight counterparts (although part of the mix) are too light weight in isolation. My real point of contention is that the whole marketing team (including the C-Level) should become Agile. This will require more than just practical change but more importantly cultural change within marketing and the executive.

We might get a little deep here so if you are familiar with the territory please jump to ‘So what now?’ OK so now let’s jump into some detail.

What is Agile?

Agile has its roots in Rapid Application Development (RAD) introduced in the early nineties to try a different approach to common waterfall methodologies of software development. The objective was to challenge the paradigm of measuring success based on the percentage of work completed as opposed to the delivery of business value. The assertion was that measuring percentage of work completed in waterfall projects meant that projects had a higher risk of being over budget, delivered late or the wrong solution (DSDM 2014).

Agile software development emphasizes putting the customers needs at the centre of the project with a focus on involvement and satisfying the customer (Jurca, Hellman & Maurer 2014). The development process drives on time delivery, never compromising quality, developing iteratively and deploying incrementally by focusing on the business need (DSDM 2014). Agile is people orientated not process heavy (Constantine 2002). It focuses on empowering teams to make decisions rather than follow hierarchical decision approval processes (DSDM 2014). Table 1 demonstrates the Manifesto for Agile Development.

Table 1: Manifesto for Agile Software Development

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

Source: Beck et al. (2001) – http://www.agilealliance.org/the-alliance/the-agile-manifesto/

Working in short ‘time-boxed’ cycles, Agile teams attempt to minimize waste by doing only what is needed. They don’t waste time over analysing and designing up front ‘needless’ things. The Agile requirements and design process is otherwise known as ‘enough design up-front’ with a focus on getting started and building upon requirements iteratively (Constantine 2002). This is achieved by starting small and elaborating requirements as the team and the customer learn (Constantine 2002, DSDM 2014)…  

…There are many types of Agile with Agile Data, Disciplined Agile Delivery (DAD), Scrum, Extreme Programming (XP) and Dynamic System Development Method (DSDM) being common methods of practice (Ambler 2012). At a high-level, generic Agile software development can be represented by figure 4 where the process of iteration in time-boxed sprints can occur.

Figure 4: Generic Agile Development Process

Agile Lifecycle

Source: Scott Ambler http://www.agilemodeling.com/essays/agileUsability.htm

The process of applying Agile methods can also be segmented along the lines of ‘light weight’ and ‘fuller’ groupings to differentiate a team approach to development and a project management approach to process management. These differences are demonstrated by comparing Scrum (light weight) to DSDM (fuller) in figures 5 and 6. The DSDM project management method allows for the solution development team (figure 6) to follow scrum methods with the Scrum sprint process overlaying DSDM time-boxes as part of the evolving solution (DSDM 2014).

Figure 5: Agile Scrum Development – light-weight

scrum

Source: Federoff and Courage (2009) – http://link.springer.com/chapter/10.1007/978-3-642-02556-3_27

Figure 6: Agile DSDM Project Management – ‘fuller approach’

Agile DSDM Products – https://www.dsdm.org/content/products

So what now?

OK, so now we have the high-level basics and history worked out but what is happening now? Well, to make it a little more complicated; everyone is coming up with their own forms of Agile! Prince2 has just released its own version of Agile as part of the wider Prince2 construct. Our partner BrandMaker has it’s own version of Agile called Smart Launch. Most enterprise Systems Integration companies also have their own form of Agile delivery. What is happening is all these organisations are pulling best practice and learning’s into their own iterative delivery methodologies. So what should you do as marketers if the future of marketing is Agile?

Well first we must understand why you would implement Agile. Romek Jansen of MRMLogiq and BrandMaker outlines 18 statistics that underpin 5 compelling reasons to get started in Agile Marketing. These statistics illustrate positive gains in speed, responsiveness to change, productivity and higher profitability. Whilst I do not agree with everything (particularly the focus on scrum without consideration for the wider Agile context) in Jim Ewel’s blog 2022: The Future of Marketing is Agile, he raises some interesting rationales for Agile adoption including: Momentum-Based, not Campaign-Based, Marketers Become Scientists, Marketers Become Technologists and Customer Experiences, Not Products. When coupled with the context of rapidly increasing volume, variety and velocity of data an Agile scientific, iterative and incremental approach is needed for marketers to keep up with the rapid pace of change occurring around them. But where would you start? Let’s cover this off, yes you could approach Agile marketing at the team level and build a scrum team to ‘deliver something’ in an Agile way however that team doesn’t operate in a vacuum. How might the rest of the tiers of organisation fit in? How would planning occur to set the activities, channels and budget? How would an understanding of the customer be derived? How would benefits and disbenefits be developed? How would the program and projects be defined and delivered? How might the documentation be ‘iteratively’ developed to set the agenda and record lessons learnt? As an aside: yes, contrary to what some may have heard about Agile, documentation is important but not at the expense of delivering business value, delivering on time or compromising quality. And finally how might all participants’ roles and objectives be defined and measured? This is where a fuller approach becomes a lot more relevant. This is also where the devil lies in the detail and a fuller Agile approach can be intimidating, particularly around how the triple constraints of time, cost and scope (i.e. features, requirements etc) need to be reframed.

For example, in the traditional approach of planning and definition of requirements the features are fixed. If the team is struggling to deliver to the plan invariably the time and costs may over-run. Sounds like something we have all experienced right? A fuller Agile approach defines the triple constraints differently though. In a fuller Agile approach the triple constraints are flipped and time and costs are fixed and the requirements/features are variable. See example below.

Traditional versus Agile DSDM Approach to Triple Constraints

Traditional versus Agile DSDM Approach to Triple Constraints – https://www.dsdm.org/content/philosophy-and-fundamentals

The planning and requirements process is also iterative underpinned by ‘enough design up front.’ In the initial instance planning documentation is iteratively developed and the team delivers ‘epics’ that can be further iteratively developed into ‘user stories.’ Finally at conclusion, some features may not even be delivered at all. However time, cost and quality are delivered as per agreed expectations. What this approach says to me is that the journey is more important than the destination. This is tacit acknowledgement that through collaborative effort and continual learning in the face of continual (external and internal) change we can produce more effective results rather than slavishly plugging away at a future designed in the past when we all know, no one can see into the future!

This is a critical concept for everyone to get his or her head around. It means that the whole process of developing certainty for people in the decision making process requires a cultural and systemic change to allocating budgets, defining outcomes and measuring success. Basically what this means is what is agreed to in the planning, requirements gathering and solutioning phases as deliverables might not necessarily be delivered. It might look a little different but it is what the customer needs. This takes a little getting used to, particularly for executives who want certainty of outcomes up front so they can measure their expectations on success. In order for the whole marketing ecosystem to be Agile, executive marketers will need to accept initial uncertainty through acknowledgement that Agility will empower their marketing team to respond to change, deliver value and ongoing certainty through the demonstration of control.

Leave a Reply

Your email address will not be published.