Velocity

When helping a data and analytics team adopt a new AgileData Way of Working, it takes a while to achieve what is referred to as consistent velocity.

Velocity is a metric which is used to measure the amount of work done by a team.

The use of the term originated as part of the Scrum patterns.  The team adds up the story points (a guesstimate of effort) that were assigned to the user stories that were completed during the sprint. This total is their velocity. 

Velocity is also used to predict how much work a team can complete in future sprints.  During the sprint planning process teams assign the user stories or tasks with story points, based on a guesstimate of effort to complete that story or task.  As they accept work into the sprint backlog they keep a tally of the total points they have accepted.  When the story points equal the total velocity they typically deliver the sprint is treated as full.  The pattern is to use previous performance as an indicator of future performance.

In an AgileData context the AgileData team adds up the effort guesstimates that were associated with the Information Product data tasks or the Data Platform features that were completed during an iteration.  We can also calculate the velocity of the team if they are using a flow pattern, by adding upon the effort guesstimates over consistent time windows, for example over 20, 60 or 90 days.

AgileData teams can also use the velocity pattern as part of their planning process.  Each user story, data task or feature task in the iteration is sized using Poker Points, and then the sprint is filled with work until the total number of points matches the velocity of the previous iteration.

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

Once the 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 AgileData team that is at their true optimal velocity, you only have three choices:

• Accept the estimated date of completion;
• Reduce what you are asking the team to deliver;
• Stand up an additional AgileData delivery team.

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 traditional roles.  For example, adding another Business Analyst (BA) and Tester to make it “go faster”.

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

• The existing AgileData team members will need to train new members up in the way the team works, reducing what they can deliver themselves;
• 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;
• The team will take time to assimilate the new skills mix and make the team effective;
• 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 a fixed management behaviour

While fixed mindset approaches do not formally state to randomly add more team members, this is certainly a common behaviour of such approaches. It is definitely the behaviour of people who have little experience in a growth mindset and agile ways of working. Their theory being that if the 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.

We have seen examples where people have been arbitrarily added to a team, without the team being told the new members were turning up. Also without the people who are adding the additional team members attending the retrospectives to ensure additional team members were required and that it wasn’t a problem with the team’s Way of Working or something else that needed to be iterated.

I remember a situation when the Project Manager (this title is a warning sign in itself) and Scrum Coach announced they were adding another BA.  I asked the experienced AgileData team members if they actually needed more members, and they all agreed it was the last thing they needed.  They stated they needed clarity on what was to be delivered each sprint and for the Scrum Coach, Business Analyst and Project Manager to stop randomly removing deliverables from the sprint when the deliverable seemed “hard”.

The first problem was these deliverables were “descoped” during the sprint, not at the sprint backlog session before the sprint commenced.  This meant any work that was already done on these deliverables was wasted.  The second problem was the Project Manager and the Scrum Coach made the decision to remove them during the sprint, without discussing it with the team.  These decisions should be made by the AgileData team not by the supporting roles.

Often when starting to work on a deliverable an AgileData team will find that they had mis-estimated the level of effort required to deliver it.  This is common as the team are estimating early and with limited information as part of the sprint planning process and so are often wrong.  With an experienced team, this won’t phase them, they are used to dealing with the consequences of this problem.   

In this example they were not removed because the team said they had mis-estimated and couldn’t deliver them during the sprint, but because they looked “too hard” to the supporting roles when the real effort was discovered.

At that time, the AgileData team was many sprints down and had formed and stormed as a team, but the desired delivery velocity was not there.  There was a fixed deadline to decommission a legacy system and 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 to the team with their current Way of the Working. The Scrum Coach had yet to introduce story points for the sprint.  In addition, a pipeline approach was implemented which meant there was a BA and a Subject Matter Expert (SME) “documenting” requirements in the first sprint, the data skilled team members developing the data in the second sprint, and the content and testing skilled team members doing their data tasks in the third sprint.

The AgileData team members that highlighted any issues to be worked on in subsequent sprint retrospectives were flagged to the “management team” as causing issues. The fact that a “management team” even existed when there was only one single AgileData 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 consumers and stakeholders to understand what they needed today.

A “business advisor” outside of the AgileData team (not a 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 who had never worked in an agile environment before, and was remote to the co-located AgileData team (this was pre COVID), was providing part-time “expertise” on the agile approach that should be used.

To add to the chaos the organisation had undertaken a massive reorganisation that changed every employee’s role, just as the AgileData team had started their work to rebuild the dat a platform and replace all the legacy Information Products,.  This caused massive disruption when trying to get access to the key SME’s, consumers or when the Product Owner needed to engage with Stakeholders to help get key decisions made.

There were a large number of problems with their Ways of Working to solve first, before thinking about adding new members to increase velocity.