When building a new data and analytics agile delivery team, it takes a while to achieve what is referred to as full velocity.

Velocity is a metric used to measure the work done.

At the end of each delivery iteration, the agile data team adds up effort estimates associated with user stories that were completed. This total is their velocity.

Since it is the metric that allows an agile data team to accurately estimate what they can commit to delivering in the next iteration, the entire planning process relies on velocity. Each user story in the iteration is sized using Poker Points, and then the sprint is filled with User or Developer Stories until the total number of points matches the velocity of the previous iteration.

It will typically take a new agile data team three to six iterations to reach full velocity.  By full velocity, I mean the average number of points the team can sustainability and successfully deliver in three weeks of effort.  Agile data teams will typically start out with a low velocity until they discover the most efficient way to work together and meet their full potential – aka full velocity. (It is important to note that the velocity of different agile data teams is always different and you should never compare across different teams.)

Once the agile data team has discovered its full velocity, they can also compute (or revise) an estimate of how long all the work will take to complete based on the estimates associated with the remaining Information Product Backlog. This is generally an accurate prediction.

Adding a new team member makes you slower

An issue often arises when there is a fixed or desired deadline and the estimated date of completion is after the desired date of completion.  Stakeholders often find this unacceptable.

If you have a well-formed agile data team that is at their true maximum velocity, you only have three choices:

  1. Accept the estimated date of completion;
  2. Reduce what you are asking the team to deliver;
  3. Stand up an additional agile data delivery squad.

Unfortunately, these workable solutions are not always implemented. There is a big risk that someone will come up with the idea of adding one or more new members to the current team. If the team does not have good T-Skills, or you are pipelining, you will often see the suggestion that you double some of the legacy roles.  For example, adding another BA and Tester to make it “go faster”.

The issue here is that adding new members to the agile data team will make the whole team go slower and deliver less, at least in the short term.  This is because:

  1. The existing agile data team members will need to train new members up in the way the team works, reducing what they can deliver themselves;
  2. New members often mean new opinions. The way the team works may get renegotiated or time is taken to explain why it was agreed to do it a certain way;
  3. The team will take time to assimilate the new skills mix and make the team effective;
  4. Often there are not enough tasks for two members with similar skills, so one member will be idle for a portion of the iteration.

The danger of old delivery behaviour

While formal Waterfall approaches such as Prince 2 or PMP do not formally state to randomly add on more team members, this is certainly a relic of such approaches. It is definitely the behaviour of people who have no experience in agile. Their theory being that if the agile team is not delivering fast enough, the answer is that everyone must be busy and more people need to be added. This is done without an understanding of the root cause for the lack of velocity.

I have actually seen examples where people have been arbitrarily added to an agile data team, without the team actually being told the new members were turning up. Also without the project manager who was adding the people actually attending the retrospectives to ensure it was not a problem with the agile data process.

I remember a situation when the Project Manager and Scrum Master announced they were adding another “BA”.  I asked the experienced agile team members if they actually needed more members, and they all agreed it was actually the last thing they needed.

They told me they needed clarity on what was to be delivered each sprint and for the Scrum Master, Business Analyst and Project Manager to stop randomly removing deliverables from the Sprint when the deliverable seemed “hard”.

To be clear, these deliverables were “descoped” during the sprint, not at the sprint backlog session before the sprint commenced. The Project Manager and the Scrum Master removed them, not the agile data team.  They were not removed because the agile team said they had mis-estimated and couldn’t deliver them during the sprint, but because they looked hard to certain members when the real effort was discovered.

At that time, the agile data team was many sprints down and had formed and stormed as a team. But the desired delivery velocity was not there, and there was a fixed deadline to decommission a legacy system. It was very clear that at the current velocity the data and content would not be replaced in time for the fixed deadline.

A number of issues were obvious with the agile patterns that were being used.

For whatever reason, the Scrum Master had yet to introduce story pointing for the Sprint.  In addition, a pipeline approach was implemented which meant there was a BA and a SME “documenting” requirements in the first sprint, the data skilled members developing the data in the second, and the content and testing skilled members doing their tasks in the third sprint.

The agile data members that highlighted any issues to be worked on in subsequent sprints during retrospectives were flagged to the “leadership team” as causing issues. The fact that a “leadership team” even existed when there was only one single agile data delivery squad, was a warning in and of itself.

The BA and the SME were reverse engineering the requirements from code and content that had been delivered over decades, rather than engaging with the key users to understand what they needed today.

A “business advisor” outside of the agile data Team (i.e. not the Product Owner) was making the call on what data and content needed to be delivered to enable the old system to be decommissioned. Another “advisor” from the visualisation software company had never worked in an agile environment before, was remote to the agile data Team, and was providing part-time “expertise” on the agile approach that should be used.

At the start of the time-period the agile data team had to replace the data and content, the organisation had undertaken a massive reorganisation that changed every employee’s role.  This caused massive disruption when trying to get access to the key users or when the Product Owner needed to engage with Stakeholders to help get key decisions made.

There were a large number of agile pattern problems to solve before even thinking about adding new members to increase velocity.

Shane Gibson

Chief Product Officer,