Adding members to the Agile Team makes you go slower

by | 3.3 - AgileBI Disciplines, AgileBI, Concepts, Done Done

As a Stakeholder or Product Owner I want I want to understand if constantly adding Agile Team members is a good idea So that I can have a valid conversation with my Product Owner and Scrum Master

Initially at least!

Velocity

When building a new AgileBI delivery team, it takes a while to achieve what is referred to as a full velocity.

Velocity is a metric used to measure the work done.  At the end of each delivery iteration, the AgileBI Team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.

Velocity is used in the planning process to help the AgileBI Team workout what they can commit to delivering in the next 3-week iteration.  They size each user story in the iteration using Poker Points and then “fill” the sprint with the user stories until the total number of points matches the velocity of the previous iteration.

It will take a new AgileBI Team 3 – 6 iterations to reach full velocity.  By full velocity, I mean the average number of points the team can sustainability and successfully, deliver in 3-weeks of effort.  AgileBI 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 AgileBI teams is always different and you should never compare across different teams.

Once the AgileBI Team has discovered its full velocity, the AgileBI team can also compute (or revise) an estimate of how long the project will take to complete, based on the estimates associated with remaining Information Product backlog and assuming that velocity over the remaining iterations will remain approximately the same. This is generally an accurate prediction.

Adding a new team member makes you slower

This often causes an issue when there is a fixed or desired deadline and the estimated date of completion is after the desired date of completion.  The Stakeholders often find this unacceptable.

If you have a well-formed AgileBI Team that is at their true maximum velocity then the only choices you have is to either accept the estimated date of completion, reduce what you are asking them to deliver or stand up an additional AgileBI Delivery Team.

Of course, standing up an additional team of 5 to 7 AgileBI Members is often a large cost, especially when it takes 9 to 18 weeks (3 to 6 iterations)  for them to achieve their full velocity.

So there is a big risk that somebody will come up with the idea of adding 1 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 is that adding new members to the AgileBI Team will make the whole team go slower and deliver less, at least in the short term.  This is because:

  1. The existing AgileBI Teams members will need to train new members up in the way the team works, and this reduces what they can deliver themselves.
  2. New members often mean new opinions and so the way the team works may get relitigated or time is taken to explain why it was agreed to do it that way.
  3. The team will take time to assimilate the new skills mix and make it 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

I would typically say that adding team members (often referred to as “resources”) was a Waterfall behaviour. But I’m not sure that the formal Waterfall approaches such as Prince 2 actually say that when you are not on track the answer is to randomly add more resources to solve the problem.

It is definitely the behaviour of people who have no experience in Agile. Their theory being that if the Agile Team are not delivering fast enough, then the answer is that everybody must be busy and to add more people to the team. This is often done without any understanding of the root cause for the lack of velocity.

I have actually seen examples where people have been arbitrarily added to an AgileBI 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 AgileBI process. 

In fact in one example 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, they said no it was the last thing they needed.

What they said they needed was clarity of 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. They were removed by the Project Manager and the Scrum Master, not by the AgileBI Team.  They were also removed not because the Agile Team said they had miss-estimated and couldn’t deliver them during the sprint, but just because they looked hard to certain members when the real effort was discovered.

At that time the Agile Team were 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 Approach that was 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 AgileBI Members that highlighted any issues that needed to be worked on in subsequent sprints during the retrospectives, were flagged to the “leadership team” that they were causing issues. The fact that there was even a “leadership team” when there was only one single AgileBI Delivery Team, was a warning in 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 AgileBI 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 BI software company who had never worked in an Agile environment before, and was remote to the AgileBI Team, and was providing part-time “expertise” on the Agile Approach that should be used.

At the start of the time-period the AgileBI 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 Process problems to solve before even thinking about adding new members to increase velocity.

AgileBI Discipline Articles

SFT – The art of Innovation – break it and then fix it

Innovation is a popular word these days in business. Good old Wikipedia defines it as "Innovation is the application of better solutions that meet new requirements, inarticulated needs, or existing market needs." But being innovative is not simple. And often the...

Day 1 – Overview, Vision, Scope and Accountability

So day one is down and it was a day of setting the vision and starting the definition of the scope (the Dev team were off sick, so it was only a 1/2 a day) The Process The day started with a quick whiteboard overview of the entire Agile Scrum Framework and this...

I’m getting flexible – a week of Agile ahead

I love learning new stuff! The six months I spent at Xero has probably been my most intensive learning experience I have had, and in retrospect it was due to the fact it was total immersion, completely focussed on delivery (having Rod Drury walking the floor behind...

Dynamic Data Driven Urls coming in SAS VA 6.3

Kathryn has just spent part of last week mentoring a SAS VA customer in Australia.  We love this type of work because we help out customers help themselves (rather than black boxing delivery and forcing them to pay us for every change) and because we always learn new...

SFT – Watch the end of the runway

Often in a project we focus on the wrong things. Lets look at a project with the goal of building a plane that will take off.  The challenge is that while we are building the plane it is slowly moving towards the end of the runway. Once we run out of runway the...

SFT – What is cloud computing?

Cloud computing is the latest buzz word and in true IT style, we have invented a raft of TLA's to explain what it is (and isn't) as well as a myriad of versions to confuse people even more. PaaS, IaaS, SaaS, DaaS, public cloud, private cloud, hybrid cloud, BIaaS, How...

SFT – Don’t complain, suggest something better

When you find something you don't like a natural reaction is to complain. The people you complain to will often listen politely, but they won't typically do anything about it. (Unless you have something they really want, that they will lose if they don't rectify what...

SFT – Its not the idea, its the execution

Your idea probably isn't unique. But then again you probably haven't found anybody that has done it the way you plan to do it. So don't spend your time asking people to sign NDA's or telling them half of the story. Just go execute on it. If you not sure, or need help,...

Deloitte Fast50 2013 – Infographic

So have you heard that the Deloitte Fast50 for 2013 has been announced and we came 22nd 😉 Check out our Badge Well one of the cool things about the Fast50 is that there are a myriad of different companies, doing different things and all at different stages of their...