Posts
- How many hotfix iteration have you been doing on average before the major release?
You know, there is a special context of that conversation about our project and team, which still continuing without me on board. It was hard to admit that we used to have no hotfix iterations at all. To be precise, assume that hotfix is iteration when no functionality created, but rather fixed, visually improved or removed in order to keep software consistent and to not expose unfinished parts. In reality hotfixes became so usual recently that I didn't pay much attention that I had never done it.
After rushing weekend I can confess: People, indeed I didn't have ANY hotfix iteration. In fact, I can see no argument why any project or team should have such iterations.
Aren't you able to predict that some certain parts won't be completed before?
Many will appeal to the hectic they suffer in the project and justify lack of strategic thinking. Still irrespective to what model did you choose agile or waterfall there are people whose primary responsibility is to make forecasts. So absence of any prediction can not be tolerated. Regarding our project I still have two arguments:
1. There is a difference between biasing within one iteration and biasing over iterations: I can imagine why team committed to 23 tasks was managed to finish only 20. That's something that forms team performance (or in Agile terms - velocity).
But how can you (team, manager and product owner) do 3 iteration in line and then you need 2 more?
2. We are talking about projects within one team and one product owner. New product implements functionality of the old one. Product owners and developers are mostly left unchanged. Users left the same. Even requirements can be reused. Only things were changed are technologies (I guess that's positive upgrade) and process (...)
Spit and polish in Software
To my former NTSR project something called spit and polish has been introduced. Spit and polish is an iteration task which includes resolution of minor troubles and fixes.
Examples would be like incorrect rendering in webforms or some minor problems like only USD is supported (in control that suppose to have EUR and JPY).
IMHO, this is our project's KNOW-HOW and arguably the most stupid practice I've seen in IT. Pragmatically I would say there are 2 negative things about spit and polish:
1) everything can be claimed as spit and polish.
2) no one cares about time spent on that.
The latter requires certain explanations: In fact developers are do not putting much efforts to register hours for tasks pretended to be spit and polish. And what they definitely not do is to describe what exactly has been done within spit and polish (because - saving time on that is primary reason why do we have spit and polish).
But even if developers would be enough motivated to register time spent on that there is anyway deeper trouble ... From management perspective this time can be treated as nothing but direct loss: you can neither predict nor decompose this time. And that means that you can't do anything about it at all.
The root causes of this is going through human factor and dissolving somewhere in the deepest aspect of human psychology. Being forced to deliver faster, people tend to shrink their responsibilities. Manager who suggested to deliver the functionality first and then the quality does not care about quality at all. I remember remarkable interview with Bjarne Stroustrup where he was saying
In reality, that's impossible. People reward developers who deliver software that is cheap, buggy, and first.
I guess there is no hope that at some point the gene of the irresponsibility will be extinct. God has special providence for its adherents ...
