The challenge of being an agile data leader

As a data leader who decides to empower a team by introducing an agile data way of working (WoW) , there is a massive set of challenges in that simple action.

You are empowering a team to work in a very different way, and often in a way that is the polar opposite of the way you’r organisation typically operates. This step into the unknown introduces a lot of challenges.

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 agile data way of working very visible. The team will be excited (or not) about the new agile way of working 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 during a delivery cycle (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

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). Under an agile data way of working, the team are self-managing. So you will no longer control what the team do, when they do it, or how they do it. You are no longer responsible for the work to be done. To relinquish this sense of control is a significant step for you to take.

There is a challenge that you will lose detailed visibility of what the team are doing or how they are feeling about the massive change in the way they work.  As an agile data leader you have ways to keep across the work being done, and more importantly you still have the responsibility of providing pastoral care for your team.

As the agile data leader, you of course attend the demo day so will see the teams success (or failure). You can also attend the daily stand-ups, backlog grooming and retrospectives, but I suggest you don’t, at least not for a while. To have the teams “manager” at these planning sessions will result in the team talking to you rather than to themselves, it is what they are conditioned to do. Or even worse, the you will start providing solutions and making decisions for the team, again it’s what you 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 agile data leader catches up with the team members individually and on a regular basis at the beginning of the move to agile data way of working to see how they are going, to cover the need to make sure the individuals are feeling safe and to work through any concerns.  Pastoral care of your team should be one of your primary focus (especially as hands on managing the work to be done is no longer your responsibility)

Lack of Visibility

If demo days are the only way you as the agile data leader can find out when there has been a failure, your ability to mitigate the political risk across the organisation of these failures is restricted.

The Product Owner, assisted by the Scrum Coach or Agile Coach, should be providing the agile data leader with constant updates on how the team are going and any potential areas that may fail so that the you can minimise the potential political impact within the organisation.

The agile data leader should also have easy access to the vision statement, iteration delivery scorecard and velocity reports. This content should be continuously provided to them during the iteration as well as at the end.

No Need for a Data Leader

If the team are self-managing, then the perception there is no need for an agile leader may arise. That’s a bit harsh for the person 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 the agile data leader 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 agile data leader will have a lot more time to manage up and get the resources the team needs to be successful (Just make sure your role doesn’t get relegated to only doing the dross administration work that a non agile organisation seems to demand)

Flight Risk

Although agile is the new black for data and analytics delivery, it is still the minority approach compared to the traditional waterfall projects, in the data and analytics domain. Once the team have been up-skilled 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 agile data way of working , 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 being “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 agile data leader as they embark on this agile approach “again”.

There is 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 agile data team.

These are all classic signs of being Ad-Hoc or “doing” agile. The agile data way of working provides many practises and patterns to identify when this is happening and rectify it. The agile data leader needs to ensure these are followed, to ensure the teams success.

External PMO

More often than not larger organisations 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 agile data 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 an agile data leader can add to enable their team to be successful (apart from embarking on the agile data way of working itself).

When the agile data team are forced into reporting to an external PMO process, the 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 agile data leader can then front this document to the PMO, keeping them happy from a project reporting point of view, but also isolating the agile data team from this process and its inherent distractions.

Funding

Funding is another area that needs to be managed by the agile data leader. A lot of organisations fund their data and analytics capability via a never ending set of projects and initiatives.

The ideal situation is for the agile data 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 agile data leader 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 rework to be undertaken when required. Without this approach technical debt rework will not be possible, as no project would fund the rework.

The funding estimates provided to the PMO should also be based on a waterfall style effort estimate, not estimates based on the agile data teams full velocity. This would give the agile data leader 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 sign-off, 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 agile data leader should also be to get the organisation to move from this project funding to a fully funded agile data team model as the team proves their capability and value by delivering value consistently. As the Data Leader 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 data leaders can experience when taking their team on the agile data journey.

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