In software development, Technical Stories are activities that don't provide direct business value. Their aim is "just" putting the code in a better state, improving the process, reducing the technical debt .
However tech story actually have indirectly a business value, though, because their effect is making the cost of the next features cheaper, more closer to their “intrinsic difficulty” (some other terms are used here, for example “essential complexity” or “essential complication”, opposed to "accidental complication").
Under these simple terms technical stories should have the maximum priority and there is no point of procrastinating them or giving them a low priority.
That means that there is no any “decision problem” here, because the answer is always “yes” (ok, almost always, see later).
Second claim: trying to involve someone that is supposed just to deal with R.O.I. (the Product Owner in Scrum), will probably end up in a not rational decision.
Let’s see (my) why.
1) They must have maximum priority
Suppose that the cost of the story is R.
If we leave the code base (or our process) as it is now, so we don't implement the Tech Story, then the cost of any other new story will be higher, say 20% higher.
The decision problem, with the goal of minimize the costs is like this:
If the cost of the remaining stories to finish the project (on a clean base code) will be T, then, if we work on that story, spending an extra R, the total cost to finish the project will be T + R.
If we don't work on the tech story then the rest of the stories will cost 20% more, i.e. the cost to complete the project will be T*1.2
So the solution to the decision (to minimize costs) will be: add the story only if T+R < T*1.2, i.e. R < T*0.2 .
Looks a very simple model, that just comes out from the definition of the tech story (something that reduces the cost of the work we are going to do later).
Probably we can't show those numbers for real, but it does not matter so much as long as we are talking about what may happen in the long run.
In fact, if we just assume that the extra cost without implementing tech story is positive (no matter how small it is), then the equation that must hold to decide doing the story is R < T*X.
Increasing T (basically the amount of work to be done to complete the project), the coefficient X of extra cost for not paying the technical debt, with a total T*X, is very high even for very small X (we just have to assume it is positive, of course).
So when we reason by this model, there is not any "yes or not". it should be always yes. We do the story, as soon as possible, for long term outcomes.
2) A guy that just cares about the outcome from the “business point of view” supposed to do a decision about (usually the Product Owner), will likely end up in making an irrational decision.
This statement comes out as a variant of the S. Petersburg Game that simply states: you want to pay very little on the short terms when the outcome is very big (virtually infinite) on the long term. Irrational but human.
We heard or read somewhere that the P.O. must be accountable for prioritizing the tech story, but an alarm should trigger in your head here.
I would say that under these term the P.O. must be just informed, not involved, accountable, or responsible. Moreover the sprint burndown should be related only to normal user stories, leaving out the tech stories. (possibly we may have separate tech story burn down, or a separate technical debt backlog, something like that).
(In some exceptional case we may take out the technical story for some reasonable short term outcomes, for example a "go-no go" deadline).
Now I want to go deeper about how to make sense about the value of user story in a way more related to conversations and system thinking.
We need to promote good conversations if we need to involve people. The old habits are radicated in the corporate culture. A model like the simple one I used probably is not enough to convince skeptical people.
There can be a kind of addiction to a bad process, because it can be easier keeping there the option of blaming: blaming the process, blaming the guy that worked before us, and so on…
So, teams got stuck in a bad process trap that introduces waste difficult to escape from. Everyone is, or appear too “time crunched”, being unable to effectively care about improvement. It’s hard to help taking a breath and fix the process, one piece at time. (Actually the A3 based improvement is for me a very great tool, and I’ve seen some concrete progress about, but this is another issue. Also useful hints to promote the change are described in “Driving Technical Change”).
Another useful way is trying to promote and facilitate conversations with the P.O. like this one described by Henrik Kniberg in “Scrum and Xp from theTrenches”:
Team: “We have some internal tech stuff that needs to be done.
We would like to budget 10% of our time for that, i.e. reduce focus factor from 75% to 65%. Is that OK?”
Product owner: “Hell no! We don’t have time!”
Team: “Well, look at the last sprint (all heads turn to the velocity scrawls on the whiteboard). Our estimated velocity was 80, and our actual velocity was 30, right?”
PO: “Exactly! So we don’t have time to do internal tech stuff! Need new features!”
Team: “Well, the reason why our velocity turned out to be so bad was because we spent so much time trying to put together consistent releases for testing”.
PO: “Yes, and?”
Team: “Well, our velocity will probably continue being that bad if we don’t do something about it.”
PO: “Yes, and?”
Team: “So we propose that we take approximately 10% off of this sprint to set up a continuous build server and other stuff that will take the pain off of integration. This will probably increase our sprint velocity by at least 20% for each subsequent sprint, forever!”
PO: “Oh really? Why didn’t we do this last sprint then?!”
Team: “Er... because you didn’t want us to...”
PO: “Oh, um, well fine, sounds like a good idea to do it now then!”
In this example technically the P.O. was stuck in a “quick fix trap”, the team clearly realized this, and just needed an effective conversation to convince the P.O. to approve an escape strategy. Makes sense.
Another interesting way related to conversation is via system thinking tools. We can involve people making “snapshots” of all their views in term of systems (Snappy Systems).
So let’s figure out the use of the tool in this situation:
Phase 1. List all systems about a Tech story:
The generated ideas can be like follows:
- a system to remove accidental complication
- a system to reduce the cost of adding new features later
- a system to keep the base code steady
- a system to keep the process health
- a system to reduce the probability of making the code unstable
- a system to apply continuous improvement
- a system to learn writing clean code
- a system to implement kaizen
- a system to reduce the possibility of ending up with conflicts and blame games
- a system to reduce the probability of having more bugs later
- a system to reduce the time needed to fix the bugs
- a system to reduce the global cost of development
- a system to reduce the global cost of maintenance
- a system to work at a sustainable pace
- a system to pay technical debt
Phase 2: list of the stakeholders:
- the development team
- the customer
- the company
- the version control system
- the Integrated Development Environment with refactoring tools
- the build script
- the continuous integration system
- the automated test suite
- the testers
- the CEO
- the market
- the Communities of Practices
Now the system from the perspective of some other stakeholder.
Happens that the stakeholder is the market
- a system to reduce hidden costs
- a system to have a long term efficient competition
- a system to reduce waste
- a system to make the customers happier
- a system to create a healthy market competition
- a system to reduce the “market of lemons” syndrome
- a system to promote the professionality
- a system to ensure that the company will be long living
It does not matter so much how true they are, it’s just about promoting a discussion and share insights.
Now, the Sinister Systems, most important for dealing with conflicting views:
- a system to violate the rule “if it works, don’t fix it”
- a system to excuse for not doing the things right at the first place
- a system to avoid commitments to [short term] business goals
- a system to do something that nobody outside of the team can understand
- a system to add learning activities at the expense of the company
- a system to deprecate how we have been working until yesterday
Enough for my "homework" in Model and System Thinking.
I like very much the “sinister system” approach, because it is like acknowledging what could still go wrong and why (a sort of "pre-mortem" analysis).
Ok that’s all, in my mind comes a lot of ideas about it, there is something for more posts and more experimentation. Hope this reading will help someone. Feedbacks are welcome.
No comments:
Post a Comment