Agile working is being adopted by more and more organisations. But what does Agile working bring to customer insight teams?
The term "Agile Working" is being used within more and more businesses. Although loosely defined, it generally refers to a more flexible and pacey way of working. but what does this mean for data, analytics and insight teams who need to work this way?
Those businesses who have invested in formal training will likely be following one of the five most popular methodologies. Although sounding very professional, in reality, the application of Agile to non-IT teams is still in its infancy.
The top five Agile development methodologies are generally agreed to be:
- Extreme programming (XP)
- Lean development
For more details on the technical pros and cons of each method, a useful overview has been published by Xpandit.
Agile working methodologies were originally developed for use when delivering IT projects. They were a response to slow, bureaucratic projects that all too often failed to deliver, using the traditional ‘waterfall‘ methodology. With 8 out of 10 IT projects failing to deliver, one can see the need for change.
Agile working in practice
As with most innovations, they have a mixed track record. Agile software development has certainly delivered some significant improvements. The pace of delivery & visibility to business users have improved as a result. However, some large complex projects still benefit from greater consideration & planning when following traditional PRINCE-type methods.
My interest in this topic is the impact Agile working is having on customer insight, analytics and data science teams. I’m finding many of my clients are working hard to adapt their way of working to these new methods.
Part of their challenge is that adaptation of these IT development methods to business processes is still a ‘work in progress‘. Despite the confidence and eloquence of a growing number of Agile Coaches and Scrum Masters, best practice for business teams is still not proven.
Data and analytics leaders can feel under pressure to learn a whole raft of new terms and practices. To name only a few these include:
- Visible backlog of prioritised work.
- Tickets for units of work needed.
- Public boards to track progress.
- Sprint meetings with bidding to deliver units of work.
- Standup meetings to discuss progress.
- Post-Sprint reviews to learn from what worked and what didn’t.
Beyond those shifting sands, the other problem I have recognised is that succeeding with agile working requires a culture change, not just processes. Those teams who succeed have mastered how to collaborate better. In this series, I will share some themes I have seen amongst those teams who achieve this.
Agile working in hearts and minds
The first theme I noticed is that a culture that embeds four principles. Each is a new way of working compared to the traditional behaviour seen by data or analytics teams seeking to “cover their bum” when working with business. Together they represent a winning over of hearts and minds to the benefits of a more collaborative way of working as a business.
Principle 1: Individuals & interactions
The first principle is a valuing of individuals and interactions, over processes and tools. Rather than hiding behind formal steps or documents, agile working means human interaction. That is the person who is delivering a particular unit of work talking directly to the internal customer who needs it. Together this encourages personal accountability & early transparency.
Such conversations are aligned with the dialogue encouraged in our post on Socratic Questioning. Talking early & often can avoid misconceptions or wasted work. Compared to many traditional projects it can be a revelation just knowing who to talk to. However, analysts may need to be encouraged to be this visible and supported if things go wrong before you will see sustained progress.
Principle 2: Working (but imperfect) output
The second principle is to prioritise delivering working (but imperfect) output sooner rather than later. This is counter to the traditional approach of using QA check and documentation to ensure output is ‘up to scratch’ before others can see it.
I’ve posted previously on the numerous benefits when analysts embrace imperfection. This is one of those examples. As long as both the business user and the analyst recognise that the output is expected to be imperfect, it helps to see it sooner. Early feedback can help address misunderstandings & bring to life priorities. It can be surprising how much more effective this is than relying on documentation to clarify requirements.
One word of warning, this is not a panacea. Quality and diligence still matter. I have seen cases of analysts delivering slap-dash work under the guise of this principle. If this happens leaders need to recognise their responsibility to give ‘in the moment feedback‘.
Principle 3: Collaborate with your customers
Here I mean both real (end) customers as well as internal stakeholders. Principle three is all about collaborating to co-create what is needed. All too often in the past, project leaders have resorted to formal contracts to protect them from unreasonable or ever-changing customer expectations.
This principle turns that conflict on its head. What if both your customers and your insight team felt equally invested in your project? I’ve shared a series on how to run an insight generation workshop. It can be a powerful exercise to invite your customers into your business to innovate with you.
Principle 4: Respond to change when (not if) it happens
In a similar vein, it would be hilarious (if it were not so tragic) how surprised project managers are when things change. Name me the last project you worked on when nothing changed from the original plan? You see my point.
In response to that reality, this principle encourages breaking away from a rigid plan. Expecting change and having an agreed (more flexible) way of embracing change. Utilising the more regular communication with stakeholders, about smaller units of work, to empower better responses. The ethos should be to agree on changes quickly, so as to be able to see the impact & minimise cost or time wasted.
This isn’t a panacea either and this time business users can exploit this flexibility if left unchallenged. That is one reason why agile working also requires strong leadership & empowerment of all team members. Any business that still expects analysts to be ‘order takers’ from leaders wanting evidence is not ready for agile working.
This article adapted from an original piece on Customer Insight Leader.
About Paul Laughlin
The Laughlin Consultancy helps companies generate sustainable value from their customer insight, for example by growing their bottom line, improving customer retention and demonstrating to their regulator that they treat customers fairly.
Paul Laughlin, managing director, added over £10m to the bottom line of blue chip companies each year, by removing common barriers to realising that value.
This is achieved by enabling businesses to maximise the value they can drive, from using data, analytics & research, to intelligently interact with their customers. It also means ensuring customer insight teams, especially their leaders, have the knowledge and skills they need to sustain this improvement.
Every business that we help is different and so what’s needed can vary. For that reason, the best place to start is normally for us to have a conversation, about what you are trying to achieve and your current situation. Only when we understand that, will we be in a position to suggest possible actions to maximise your returns.