Many teams who start following good engineering practices with SCRUM to be successful face this problem of velocity going low initially. Recently I saw a team which started on practicing, unit testing, refactoring old legacy code, pair programming etc on their project. The stakeholder were exited about the idea. All’s well situation. But then, a couple of sprints later what came out was that the stakeholders stared complaining about the velocity going down and were obviously not happy about it. A small down turn initially is still acceptable, but if you say, its going to take double the effort to write unit tests to complete user stories, then its a problem. The business is obviously not going to accept that.
But why did it happen in the first place??
I think there were certain aspects responsible for it. The situation was not all that bad as it looked. The velocity was not actually halved as it appeared. The reason that the velocity of the team appeared to have been halved was because all the tasks were not tracked as part of the sprint.
Example of this is that one of the team members, very good in re-factoring to good design suddenly started doing it full time. Not really working on any business story, but just re-factoring stuff. I am not saying that this is wrong. Ideally, you should be re-factoring the code that you are touching today, along side writing tests for that area or making sure the already written tests are passing. Although, a full time re-factoring might be required sometimes to make sure that you are able to deliver features faster later. But the point is that, whatever is the situation, the stakehoders should have an idea about it. The effort that its going to take and the return on that investment.
So, ideally, if you are going for some full time re-factoring task, TRACK IT as well. Add it as a item in the sprint backlog. And add its business value in terms of story points as well.
Because, if you do not do that, then you will never be able to explain your velocity trend.
Hope you all agree to that.
Loading ...
Nice One .. and Useful information …
Good post Sanjeev.
Even when you mention that refactoring has to be tracked and made clear to the customer about the ROI, refactoring is a difficult thing to sell to a stingy (which is often the case) client. He would still be concerned about the velocity of story points or moreover the velocity of the business value.
I am also a bit skeptical about the emphasis refactoring is getting.
.
I am not saying refactoring is bad. It is absolutely necessary, but I feel refactoring is being justified to cover up the lack of good design process.
Disagreements expected
Re-factoring does need to sold separately. Its a part of development. Its not a different thing at all. Like tests. Its an inherent part of the development process.
You need to mention it explicitly when you are working on some legacy code, because sometimes there is a lot to re factor. But in my experience, if you give your client a reason like “the code is going to be beautiful if we do this re-factoring”, its definitely going to be rejected.
As a client, my thinking is “WHY do I care.. if the business value can still be delivered without this re-factoring”. What I need is, my functionality to be working.
In my opinion and by experience we should sell it by pointing out specific reasons to it. For example, ask your self this question. What is the harm if you do not re-factor a particular piece of code right away. Normally, I try to re-factor something, if its hurting, not because its not looking “good”. What do I mean by “it’s hurting”.
And this is what you are supposed to make sure that your client also understands. The point where it hurts. So for example, in one of my projects, I told my product owner that, “these are the area’s which are creating a lot of difficulty in adding new feature and thus are taking a lot of time for us to implement features. Its becoming more error-prone as well and thus may result into a lot of bugs as well later.” And he bought it. well and good. We immediately (may not be immediate in your case, but at least you can create a placeholder for that re-factoring, to be included as an item in your coming sprint), created an item and included in the next sprint.
“I feel re-factoring is being justified to cover up the lack of good design process”… I disagree here.
This is when you get into a habit of saying, “I am coding it the wrong way because I do not have time now. And I’ll re-factor it later…”
That’s a wrong practice. Re-factoring, by principle should happen immediately on something that you are writing right now, and most importantly, it should go hand in hand, more and more often as you write code. Its should be multiple smaller sessions of re-factoring that should happen in the ode that you are writing now for a feature.
I strongly feel that if you pair program and follow TDD, you will not face the situation of re-factoring becoming a cover up for bad design at all.
About Refactoring, I fully agree refactoring is a must and as you mentioned it is to be done as soon as my code is “hurting”. And I certainly didnt meant that “I dont have time to refactor… later”.
But we are inducting refactoring as a mainstream process with all the tools that are available, I am just afraid that are we relying too much on refactoring “in multiple smaller sessions ” and hence tending not to worry about better design at a slightly bigger level.
Anyway this feeling might be because of my lack of experience with TDD.
Refactoring at a smaller level is not a difficult task and it is very normal (and often not even accounted for). But the main challenge is when a break-through feature comes as a requirement and that is when I feel the design matters which also decides how much refactoring is needed.
All I am trying to say is “seeing a bigger picture helps”
I think I need another post for discussion on re-factoring
This post was about tracking everything.. but I appreciate your responses
Maybe we can pair sometimes or can have a discussion ion re-factoring offline