After a few months, a new Scrum team's velocity should ____________.

Extraordinary claims require extraordinary evidence - Carl Sagan

As a Scrum Master or as Coach, I am sure you must have encountered a proverbial question:

"After a few months, a new Scrum team's velocity should ____________."

Does answer be “increase” or “remain constant” or something else?

Let’s explore the various aspects of this statement.

In a simplistic world, a team using the Scrum framework over a time period, its velocity keeps on increasing. There are claims that there is 400% to 1650% increase in productivity of the team in 10 sprints (https://www.agilealliance.org/wp-content/uploads/2016/01/ScrumMetricsAgile2012.pdf  and https://www.forbes.com/sites/stevedenning/2012/03/01/the-power-of-scrum/#321fffc27730). Does this increase continue forever or a plateau reaches after a while?

 

 

Both of these scenarios have some underlying assumptions:

1.       The team’s composition remains stable over an extended period of time.

2.       The type of work team is doing remain similar over an extended period of time.

3.       The basis of estimation remains same over an extended period of time. A story estimated for three story points during the 1st month of the life cycle of the team is again estimated as three-story points during the 15th month of the life cycle.

There is one more assumption, with time team’s maturity increases. In practice, time and maturity are positively correlated but correlation factor is context specific. For accuracy purpose let’s keep X-axis of graphs as “maturity”.

Team’s maturity is multi-dimensional:

• Embracing Agile and Scrum values backed by an implementation of processes, practices, and procedures embedded within the Agile principles
• Ever increasing automation of repetitive technical tasks
• Adoption of contemporary engineering practices
• Emphasis on shift left approach

After taking account of the dimensions of the team’s maturity, a downward pressure on estimation becomes obvious.  This downward pressure arises due to familiarity with application, better understanding of business functions, and continuous learning of social structure within organization. A story estimated as five-story points may become three-pointer and then two-pointer after a while. This phenomenon reduces the slope of the line as the productivity of the team is increasing.

In this graph, velocity reaches a plateau after a while  due to continual downward pressure on estimation.

The team not only doing continuous improvements also making occasional innovations which result in quantum jumps in productivity, so in the velocity. This introduces steps like depiction in the graph.

With time, the effect of continuous improvements and innovations wear off due to slack in human nature and dynamic environment. This adds a downward pressure on the velocity graph; a plateau starts forming until a quantum jump due to innovation or significant accumulation of continuous improvement counter the downward pressure.

Over the time period, due to disruption in environment one or both of the assumptions (stable team, a similar type of work) break down. This resets the graph.

Evolution of DevOps

Scenario 1: I have a check to deposit. I go to the bank, ask a teller to deposit the check in my account. He takes my check and makes few entries in his register. In the evening he will transmit the details of the check to some centralized location which will verify that person who has signed the check has sufficient funds his account or not and also verify the signature. If everything is fine, the amount will be transferred to my account. This whole process may take a couple of days.

Scenario 2: I have a check to deposit. I go to the bank, ask a teller to deposit the check in my account. He takes my check and verifies the check details an online system which he has access. If everything is fine (availability of funds and signature match), the fund will be transferred to my account in a couple of minutes.

Scenario 3: I have a check to deposit. I open bank's app on my smartphone, take the picture of the check, make few entries and in few minutes funds are in my account.

The above three paragraphs show how banking has evolved. from the consumer's point of view. In the first scenario, the system was manual and the consumer has to make a trip to bank and fund transfer used to take a couple of days. In the second scenario, the system is the same consumer has to make a trip to the bank but teller has access to automation which stripped away the delay. In the last scenario, the consumer has access to a self-service portal which has removed the intermediary (bank teller) and makes consumer responsible.

Let's come to the IT. Earlier we were working in the era of brick and mortar era of the bank where the developers' have to visit Operations and request for deployment. With automation, Operations job becomes easier (assuming complexity of the infrastructure remain same) and faster, still developers need the intermediary (operations team). Now we are entering the new era where the distinction between Dev and Ops is blurring because of self-service and increasing automation not only at App level but at Infrastructure level as well.