by, Business Analysis (BAPL).

I’ve somehow managed to eke out a career staggering through the murky world between data science and business analysis. My 25 years of gainful employment (other than a brief but glorious stint as a directory enquiries call centre operator in my early twenties) has involved data analysis of some description but I’m yet to write a single line of SQL code. I don’t possess either the Wizard Robes of Genius of the data scientist or the Designer Suit of Knowledge that good Business Analysts wear, but I get by.

I consider myself very blessed to have worked across multiple sectors and disciplines – having progressed from media sentiment and sports sponsorship analysis through FMCG market research, creating financial and operational business intelligence systems, redesigning government digital service offerings using human-centred design methods. Currently I am working with clients to help them realise the value of quality data and integrated insights which has exposed me to a plethora of management styles, tools and methods, all of which have shaped my own personal work philosophy and approach.

About 4 years ago now I was asked to attend agile training in preparation for joining a team of digital developers as a Data SME working on State Government digital service offerings. My instant reaction was one of panic. 25 years of data analysis is a pretty sedentary career path which has left me with all the physical agility of a wombat but, once I was assured that there would be no assault courses or climbing walls to negotiate, I went along for the ride and what a ride it has turned out to be.   Pretty much my entire career for the last 4 years has involved working on agile-managed data projects, or as a Data SME as part of an agile software delivery team. As a result, the spectrum of maturity and success of agile delivery has varied spectacularly but every day brings a new insight or learning – hopefully some of what follows will benefit you or your organisations’ own path through agile delivery.

Look before you leap – agile isn’t for every organisation, agile isn’t for every project

“Look before you leap for as you sow, ye are like to reap” – Samuel Butler

The mistake a lot of organisations or individuals make is to approach agile as Agile – the Capitalized Methodology. Agile isn’t a methodology and treating it as such confuses process with philosophy and culture. Make sure you have a clear understanding of agile principles (the Agile Manifesto is the best place to start) and that you pay close attention to understanding the implications of adopting agile principles for your organisation or project and whether or not they fit with your culture and strategic intent. It should also be remembered that agile is an umbrella term for a multitude of different project management styles and approaches (Scrum, Lean, Kanban etc.) and that understanding the nuances of these approaches is critical to choosing the approach that best suits your needs.

It’s important to remember that agile was originally created as a software development delivery approach – nothing less, nothing more. While it has successfully crossed the chasm to other types of business change it will not be a catch-all fix to all business problems. In short, do your research before committing to something that will take a lot of effort to unravel if it fails.

People make agile work – agile doesn’t make people work

“He who masters the power formed by a group of people working together has within his grasp one of the greatest powers known to man.” – Idowu Koyenikan

I was in a meeting once where our program director went around the room asking us if we preferred the agile or waterfall project approach. When she asked one of my colleagues, a much valued, highly respected and somewhat grumpy team member responded “I don’t care – I just like getting s@%t done”. While it seemed a flippant and mildly offensive response it also resonated deeply with me – and is exactly the right way to approach agile.

Adopting agile principles requires step change and in many cases a leap of faith and making sure you have the right people filling the right roles on an agile team is absolutely critical to a project’s success. Agile will NOT magically fix a toxic team culture or boost the productivity of demotivated resources, quite the opposite in fact. Adopting agile principles can sometimes feel like the grieving process in that people exposed to agile for the first time often move through the stages of denial, anger, bargaining and depression before finally accepting and adopting agile principles – different people and groups will embrace the change at different pace and it’s important that this is factored in when considering adopting agile principles.

Understand the difference between “being” and “doing” Agile

“Glory lies in the attempt to reach one’s goal and not in reaching it” – Mahatma Ghandi

Agile is a mindset, an attitude. If the company you work for focuses on doing agile rather than being agile then there’s a pretty good chance that they’re on the wrong path. Being agile is about embracing the philosophy and applying the principles of agile to your business, the doing is simply a by-product of this. Many organisations fall into the traps of:

• Following a mandated “one-size-fits-all” standardised agile model across all teams and projects. There is no standard approach to agile, it’s very nature is dynamic through constant adaptation and improvement.
• Paying more attention to the ceremonies and adherence to the agile “process” rather than the end goal, which is incremental delivery. Run a mile from any organisation which tries to build agile parameters into your individual KPIs!

Agile isn’t a contest or a race

“Try not to become a man of success but a man of value.” – Albert Einstein

One of the primary agile benefits for me is the focus on planning, sizing and prioritizing increments of work and the tools like story pointing and velocity measurement are critical to how agile works.

But they are also a double-edged sword.

By assigning point values as a measure of level of effort required to complete a task you are able to estimate the level of effort required to complete tasks in relation to each other, but it should be remembered that they are neither a delivery promise or a goal. Story points and estimation have no intrinsic meaning beyond providing an informal understanding of project complexity and effort and a specific team’s capability to deliver. Comparing velocities between teams or individuals in teams is both worthless and unnecessary – success is value delivered, not accuracy of estimation or compliance to a plan. Beware the project that has the mysterious ability to meet their velocity targets without actually delivering value (trust me, I’ve worked on a few of these).

Agile is Iterative, so iterate your approach to adopting agile

“To improve is to change, so to be perfect is to change often” – Winston Churchill

One of the guiding principles of agile is to incrementally respond to change as opposed to following a rigid plan so don’t be afraid to use this as a mantra for adopting agile principles. Organisations who try to implement agile too quickly and rigidly run a high risk of agile implementation failure. They often overlook the fact that adopting agile is a massive cultural change that should not be made overnight. Agile can also lead to a significant investment in terms of training and/or recruiting resources and the talent management strategy is too often considered an afterthought in adopting agile principles.

Careful consideration should be made to scaling agile adoption in terms of organisational readiness, resource constraints and leadership bandwidth. The larger and more complex the business, the longer it will take to scale successfully.

Beware the agile zealots

“The mind can make a heaven out of hell or a hell out of heaven.” – John Milton

For some reason people can become somewhat zealous in their approach to agile and insist on strict interpretation of agile principles, which in itself directly contradicts the core principles of the Agile Manifesto. The whole point of agile is to deliver value to customers faster, but this is not mandated by any prescriptive process.

Employing agile coaches is a great way to train your team and a good agile coach who considers your business needs and tailors their coaching accordingly is gold. A bad agile coach who insists on following a rigid agile methodology and preaches the gospel of “Agile Process and Methodology” can be very damaging when it comes to building maturity in an inexperienced agile team.

So should you choose to adopt agile principles for your project or organisation? I can’t answer that for you, but what I can tell you is this:

The dictionary defines agile as:

1) being able to move quickly and easily

Or

2) Relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans

If you approach agile in the spirit of the first definition, I believe your chances of success are much higher.