Getting Agile really working outside of IT requires culture change

/in /by

The term Agile Working is being used within more & more businesses. Although loosely defined, it generally refers to a more flexible and pacey way of working. In this post, I share what this means for business teams who need to work this way.

Those businesses who have invested in formal training will likely be following one of the 5 most popular methodologies. Although sounding very professional, in reality, the application of Agile to non-IT teams is still in its infancy.

The top 5 Agile development methodologies are generally agreed to be:

  1. Scrum
  2. Kanban
  3. Extreme Programming (XP)
  4. Lean Development
  5. Crystal

For more details on the technical pros & 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 customer focussed 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 & eloquence of a growing number of Agile Coaches & Scrum Masters, best practice for business teams is still not proven.

Business 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 & what didn’t

Beyond those shifting sands, the other problem I have recognized 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 & 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 & 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 stakeholder & the person doing the work 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 teams 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 team felt equally invested in your project? I’ve published 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

The last principle relates to the reality that thing change. As William Buist wrote when responding to the challenge of GDPR, external change is a reality for businesses. One they should expect.

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 skilled employees to be ‘order takers’ from leaders wanting evidence is not ready for agile working.

Are you Agile working this way?

I hope those thoughts help any leader who is transitioning to agile working. Have you seen these principles apply in your business? Do you have any other insights into how to get the best out of agile working? Please comment below with any advice you have to share.

If you want more detail about how this applies in the data analyst community, please click here. If you’d like to learn about an Agile methodology for large & complex projects, please click here. I wish you well on your agile endeavours, as we are all still learning how to make this work well outside IT.

 

Paul Laughlin
Latest posts by Paul Laughlin (see all)
You might also like
Watson Commerce B2B Tweetchat – 13 February, 6pm UK time
Marketing and CRM without Analytics are Nothing
Introducing AMPLIFY for Account Managers to create greater value through Trust based relationships.
LOOKING INTO 2017 – Consistency
Is it possible to systematically develop trust to a mutual competitive advantage in B2B?
The Partner Relationship Survey starts with understanding B2B Trust