The challenges and risks of being an Agile BI Manager

As a BI Manager who decides to empower their team by introducing an AgileBI approach, there is a massive amount of risk in that simple action.

They are empowering their team to work in a very different way, and often in a way that is the polar opposite of the way the organisation typically operates. This step into the unknown introduces a lot of challenges and risks.  Some of these are:

Visible Failure

The team will be standing up in one area every day for daily stand up which makes the entire AgileBI approach very visible.  The team will be excited (or not) about the new AgileBI approach and will be very vocal telling their colleagues and friends how they find the experience.  Demo day will make it very visible to the rest of the organisation what the team have delivered (or not).

When the team fail on a sprint (and they will) the failure will be visible.

In a lot of organisations, Managers are encouraged to hide any failures. Often their goal is to aim for the next promotion, not the next great delivery, or leading a great team.  In these organisations to enable your team’s failures to be visible is a big risk.

However, when the team succeed, and they will, this success will also be very visible across the organisation.

Lack of Control

BI Managers are used to managing the team, it is what in theory they are paid to do (I have a very strong opinion that they are paid to lead but that is an aside).  In the world of AgileBI, the team are self-managing.  So the BI Manager will no longer control what the team do, when they do it, or how they do it. To relinquish this sense of control is a significant step for them to take.

There is a risk of the BI Manager losing visibility of what the team are doing or how they are feeling about the massive change in the way they work.

The BI Manager, of course, attends the demo day so will see the teams success (or failure).   They could also attend the daily stand-ups, backlog grooming and retrospectives, but I suggest they don’t, at least not for a while.  To have the BI manager at these planning sessions will result in the team talking to the Manager rather than to themselves, it is what they are conditioned to do.   Or even worse, the BI Manager will start providing solutions and making decisions for the team, again it’s what they have been conditioned to do. This active guidance will curtail or, at least, delay the ability for the team to form into a self-managing team.

I suggest the BI Manager catches up with the sprint team members individually and on a regular basis at the beginning of the move to an AgileBI approach to see how they are going, to cover the need to make sure the individuals are feeling safe and to work through any concerns.

Lack of Visibility

If demo days are the only way the BI Manager finds out when there has been a failure, their ability to mitigate the political risk across the organisation of these failures is restricted.

The Product Owner, assisted by the Scrum Master, should be providing the BI Manager with constant updates on how the team are going and any potential areas that may fail so that the BI Manager can minimise the potential political impact within the organisation.

The BI Manager should be provided with the vision statement, sprint delivery scorecard and velocity reports.  This content should be continuously provided to them during the sprint as well as at the end.

No Need for a BI Manager

If the team are self-managing, then there often arises a perception there is no need for a BI Manager.  That’s a bit harsh for the BI Manager who took the risk of enabling the team to work in a new way.  It’s also not true.

Unless the organisation is working in an Agile way across the entire organisation, and, in fact, has embraced Holacracy as their organisational structure there will still be many things that only a BI Manager can do.

For example, undertaking the Personal Development Plan (PDP) and HR review processes.  Compiling, submitting and fighting for the team budget.  Attending Senior Leadership off-site retreats to understand the organisational strategy.  Ensuring team members have the correct t-skills, and recruiting new members when required.

One of the great things about the self-managing team is that the BI Manager will have a lot more time to manage up and get the resources the team needs to be successful.

Flight Risk

Although Agile is the new black for BI delivery, it is still the minority approach compared to the traditional waterfall projects.  Once the team have been upskilled in the new approach and have had many successful sprint deliveries under their belt, they will have a unique set of skills that will make them more attractive to the job marketplace.

This introduces a risk that after this up-skilling, members of the team will leave to work for other organisations.

I have found that once an individual becomes a member of a high performing team, they tend not to leave that team unless there is a very strong reason to make them leave, such as a decision to move cities, etc.  For teams not using an AgileBI approach, there is a larger level of dissatisfaction due to non-delivery and a higher rate of staff turnover.

Ad-Hoc not Agile

There is a risk that other parts of the organisations will say they are “being Agile” but, in fact, are only “doing Agile”, or worse doing “Ad-Hoc”. Or that they tried Agile, in the form of only doing daily stand-ups and it failed to deliver.   This could colour the perception of the BI Manager as they embark on this Agile approach “again”.

There is also a risk that the new team will have some weak members the rest of the team have to carry consistently, reducing their ability to deliver, but the team is unable to have them removed from the team.

There is a risk that the team will be forced to deliver based on milestones in a project plan, created and managed by people outside the AgileBI team.

These are all classic signs of being Ad-Hoc or “doing” Agile.  The Agile disciplines and self-organising team approach provides many techniques to identify when this is happening and rectify it.  The BI Manager needs to ensure these are followed, to ensure the teams success.

External PMO

More often than not the organisation will have a Project Management Office (PMO), where the bastions of the Waterfall approach reside and manage the myriad of projects, programmes and portfolios across the organisation.

There is a risk that the AgileBI team will be forced to create a milestone based project plan before they have enough detail to create an accurate plan and then they will be forced to follow this plan as the gospel of what to do and when to do it.

This is one of the biggest areas of value a BI Manager can add to enable their team to be successful (apart from embarking on the AgileBI approach itself).

When the AgileBI team are forced into reporting to an external PMO process, the AgileBI team can apply a milestone based lens on what they know, what they are are likely to deliver and use this lens to produce a project plan with milestones.  It won’t be a waterfall project plan, with big guesses upfront for requirements and design, etc.  It won’t be a gospel of what they will do and when that can’t be changed.  But it will provide a list of delivery milestones and when they are likely to be achieved.  The BI Manager can then front this document to the PMO, keeping them happy from a project reporting point of view, but also isolating the AgileBI team from this process and its inherent distractions.

Funding

Funding is another area that needs to be managed by the BI Manager. A lot of organisations fund their BI capability via a never ending set of capital projects and initiatives.

The ideal situation is for the AgileBI team to be fully funded as a permanently resourced team. As a result, their focus is solely on what value they should deliver next, not where the funding is coming from for them to do the work.  But in a project funding oriented organisation this is not always possible.

In these organisations, the BI Manager should spend time with the PMO and the stakeholders to forward book the project funding so that the team can be continuously funded and therefore consistently deliver.

A portion of this funding should be held back to enable technical debt sprints to be undertaken when required.  Without this approach technical debt sprints will not be possible, as no project would fund this rework.

The funding estimates provided to the PMO should also be based on a waterfall style effort estimate, not estimates based on the AgileBI teams full velocity.  This would give the BI manager a buffer of funding required to cover any loss in velocity due to changing team availability that often results due to delays in receiving project signoff, business case approval, etc.

These two funding buffers would also cover any gaps between projects where required, not to mention the overhead time required to manage and report within the project funding framework.

The goal for the BI Manager should also be to get the organisation to move from this project funding to a fully funded AgileBI team model as the team proves their capability and value by delivering value consistently.  As the BI Manager wears the pain of managing this project funding process, it also often provides a high level of motivation for them to make this change happen.

Big Ups

I have outlined some fairly scary challenges and risks that the BI Manager can experience when taking their team on the AgileBI journey.

I have the utmost respect for the people I have worked with who have invoked this journey knowing these risks are ahead.