Legacy Code , New Scrum Team and Low Velocity

Why do you think velocity is low?

Are the team framing and meeting Sprint Goals to deliver value, and providing finished increments that are immediately usable?

Hi Ian,

Low velocity because Team is taking too long time for getting the development tasks completed. Also we are not able to pick / prioritize much items from the backlog. 

Hi Sachin, 

You mentioned:

Low velocity because Team is taking too long time for getting the development tasks completed. Also we are not able to pick / prioritize much items from the backlog. 

I think there some possibilites to consider but first we need more information. This question can help to understand the actuall situation:

• Do you ask your team WHY they need so much time with task to complete?
• Are team spending enough time with product backlog refinement?
• Are team using good practice for example (limiting work in progress, pair programming) ?

The team may also want to utilise a SME of that product either from inside your company or from outside it. 

They may also want to include knowledge PBIs into the sprint so that they can investigate how the product works, etc.

High velocity does not necessarily mean that high quality is being delivered.  As Ian has already mentioned, are they meeting their sprint goals and delivering the required value? 

The velocity of the Sprint doesn't matter. Is the team setting appropriate Sprint Goals? Are they achieving those Sprint Goals? Is the team producing at least one usable Increment every Sprint? Is it usable not only with respect to functionality but also quality? These are better ways to assess if the team is delivering and how well they are delivering.

With respect to the old platform and legacy software, is the team identifying these problems and expressing their impact in a way that stakeholders outside of the team can understand? If the work is more than something that can be "just done" alongside the normal work, this can make the problems more visible and allows the team to talk about them as dependencies. If time isn't spent resolving certain problems, then that will impact the delivery speed and quality of other changes. The Product Owner should be in a position to be able to make the decisions about these tradeoffs.

If the team is working on something new to them, why would you expect them to be able to do it fast?  Learning takes time.  They are trying to learn how a legacy system was built without the benefit of having any of the people involved in that effort being present. For every piece of work that they attempt, they have to learn how the existing code is written in order to understand how to introduce new code without serious impact to the product. 

Stop worrying about how fast they are working and focus on whether they are constantly delivering additional value. Over time they will improve on their speed as they learn more about the code base that they are being asked to maintain. 

I'm going to provide an example outside of software.  Consider that you have 2 carpenters.  They are both highly skilled and each one has done carpentry for 15 years.  Someone asks them both to build a boat.  One of them has built 20 boats in the past but the other has never built any.  Would you expect them to build the boats at the same speed? 

I have a similar question on using Scrum (even though there is a good coherence) for product developed using legacy technology; the team faced challenge in completing work (mix of new development, enhancements, defect fixes) within two weeks due to following reasons

• Code is procedural, long, poorly organized, difficult to read; therefore time taken to understand existing code before enhancing / reusing it was little difficult to consider during estimation / sprint planning 
• Code is written in a single file, that makes Swarming difficult
• Functional test coverage is low; large amount of testing (including regression) is manual
• Team is reluctant to make stories smaller due to high transaction cost, especially for regression testing

I have thought of following options and would like to learn more from experience and expertise in this forum

1. Increase sprint duration to 3 or 4 weeks for these teams OR use ScrumBan / Kanban instead of Scrum (this would at least save teams from justifying / trying to reduce spillovers) for these teams
2. Complete some analysis as part of refinement activity / use spikes, to reduce uncertainty in estimates / sprint planning
3. Slice stories such that they are more incremental in nature than iterative, so as to reduce risk of regression issues
4. Invest in increasing functional automation coverage*
5. Modernize application using latest technologies*

* - these would require significant investment and time

Please share your views / experience that can be useful in such a context

Out of the options you have suggested, which do you think would actually resolve the problems Scrum has exposed? Which would merely provide workarounds that cover the issues up?

IMHO options 4, 5 would provide strategic long term solution though implementing these require larger investment and time. Option 1, 2 & 3 are more of workarounds / tactical solutions. 

1. Increase sprint duration to 3 or 4 weeks for these teams OR use ScrumBan / Kanban instead of Scrum (this would at least save teams from justifying / trying to reduce spillovers) for these teams
2. Complete some analysis as part of refinement activity / use spikes, to reduce uncertainty in estimates / sprint planning
3. Slice stories such that they are more incremental in nature than iterative, so as to reduce risk of regression issues
4. Invest in increasing functional automation coverage*
5. Modernize application using latest technologies*

My take...

1. No and yes. I would not change the length of the Sprint, but you can add Kanban to your Scrum, if you are ready to do so.

2. Analysis is not refinement. You can do analysis and spikes to help refinement and planning.

3. Difficult, but necessary: find the right size of your Product Backlog Items. So, yes, do think about this. But ... maybe they are the right size now?

4. Yes. Always invest in automated testing. Because the computer can test 100 pieces of functionality while a human is doing one.

5. Beware of "Ooh, Shiny"! But yes, modernize the application. You'll find it easier to work on, it will be fun. But it may also slow down development of new features.