Rob, as some readers may recall from the first post, is a made-up character, representing a typical senior business executive, responsible at a high level for the agile initiative, among many other things. Perhaps the CEO (although probably not a CEO at the Jack Welch level at GE.)
In this post, we talk about Quality and Technical Debt.
****
Dear Rob,
It is interesting that you want to focus on quality first. This is actually a very good thing.
In Agile, we start to do professional testing in the very first Sprint. This is much earlier than in Waterfall, as you know. Many reasons for this; among them, we can measure progress by the amount of completed, 'fully' tested code.
In Scrum, we have what we call a Definition of Done for the team. It defines, for the typical 'story' they are working on, how 'done' the story will get to. Like the meat metaphor: rare, medium rare, medium, medium-well, and well done.
Fully done, done, done means the product (and the newly finished stories) is/are in production and being used by the customer with no problems. Most teams have too many impediments to get to done, done, done in one Sprint (1-4 weeks). At first.
The Definition of Done should also make clear, especially for the Product Owner, what is not being done in the Sprint. For example, often the team can't do a full, full regression test in a fully integrated environment. Often (full) performance testing can't be done. Etc.
As Ken Schwaber suggests, this 'undone' work needs to be added to the Product Backlog somewhere.
Two reasons we don't like anything but 'done, done, done' product increments. (They are related reasons.)
1. The bad news is getting better with age. Meaning, of course, worse. For example, all the undiscovered bugs are quickly becoming harder and harder to fix.
2. The 90% problem is growing.
The 90% problem is, for example, very common in software development. A manager goes to a team and asks them how complete they are. They say 90%. And then he (usually a he) asks, 'how much longer to be 100% done?' And they say, 'oh, it took us about 9 months to get to here....ummm, that will be another 9 months.' Yogi Berra summarized this problem by saying: "It ain't over until it's over."
So, any time the Product Owner sees things in the Definition of Done that are not getting done in the Sprint, he should worry about the 90% problem and discuss them.
Technical Debt
What does this mean? Well, there is no one simple definition of technical debt. I say it is anything in or around the system that makes it harder to change.
Examples include: duplicative functions or modules in the code, spaghetti code, lack of automated tests, zero or poor documentation (in the code, perhaps), code written by George (when George has left the firm), the bug list, any upgrade (eg, to the database or the language or some middleware) that we have put off, etc, etc, etc.
Every system that is 6 months old has some technical debt. And it is starting to be obvious that it is hurting us. Older systems have more technical debt.
If your product is older than 2 years, I can just about guarantee that technical debt is a (very) serious problem in your shop. And that real velocity is (very) low.
In simple terms, technical debt decreases the velocity of Scrum teams.
We (seemingly purposefully) grow technical debt by saying "we have to deliver features now; let's put that stuff off until later." And then we do that. That 'that stuff' is identifying bugs, upgrading the XYZ, fixing bugs, etc.
Every manager must start understanding technical debt, and fight to get the team to dig out of technical debt. If you want any business agility. Meaning: We can adapt and change with the market and customers faster than our competition.
Impediments
As we discuss these matters, you will find that your shop (and every shop) will discover impediments. It is tempting to say: This is Scrum's fault! In fact, Scrum is only making the problems around quality and technical debt more visible. To blame Scrum is only to blame the messenger.
So, don't be surprised that the group identified a bunch of impediments. And that they cost money to fix. And that you will get real business results (better quality, eventually lower cost, etc.) from that.
How do we dig out of Technical Debt?
How do we improve the Definition of Done over time?
Mainly by removing or reducing (certain kinds of) impediments.
Quality Metrics
One way of minimizing and maybe reducing technical debt is to focus on quality.
Now, quality is itself a complex subject, and its full and complete nature depends on the specific product and your customers.
But in simplistic terms, one might say it is the lack of technical debt. Or one might say that it means the customer gets a perfectly fitting product (to her problem), with no added 'features' (eg, bugs), no extra delays, no extra effort.
As relatively low-level indicators of quality in Scrum, we can measure:
* no bugs escaped the Sprint this week. Meaning: For all the stories we say we completed in the Sprint, we did a professional (automated) testing effort (eg, unit and functional, at least), and any bugs identified were fixed and retested in the Sprint.
* X number of new automated tests were built this week (maybe one number at the unit level and another at the functional level)
* Y number of automated tests are passing in the regression tests this week.
* Our Definition of Done is relatively strong, meaning that, in areas 1-5, when a story is done, it means that no technical debt was built in those areas (at least). Or at least we made a serious effort to minimize the new technical debt being built.
* The list of (pre)existing bugs is prioritized, and shrunk by Z items or A% this week.
* We have prioritized the work around an increase of code coverage by the automated tests, and it increased B percentage points in the past week. (And these were meaningful, useful tests, not just baloney tests to make the coverage metrics look better.)
* We saw that in the last release, field issues decreased by C%, comparing first month to first month.
* Our velocity has increased X percent. This is in part due to less technical debt and in part due to less effort per unit of work...due to: better configuration management, better continuous integration, better testing tools, and faster testing servers. (* If you don't understand some of these terms, and how they are inter-linked, we should talk. You need to understand them a bit, since they are key to each (Scrum) team's success.)
Measuring quality is complicated, and my comments above are over-simplified. But, if the business and technology folks both know you care about quality, that will help a lot. A reasonable, and fairly frequent, discussion around quality metrics can help focus their attention on that. Be careful about getting too focused on one aspect of quality, one metric. The keys are (a) higher quality for the customer, as the customer defines quality, and (b) lower technical debt.
Regards,
Joe
***
Again, please give me feedback. Did this all make sense? Or did some of it sound too geeky?
It is actually not all that geeky, but if there are some geeky terms that we need to explain, I think almost surely you need to learn them a bit. Not become an expert in them, just understand them enough to guide the product development group.
Also, please give feedback on what you want to discuss next.
In this post, we talk about Quality and Technical Debt.
****
Dear Rob,
It is interesting that you want to focus on quality first. This is actually a very good thing.
In Agile, we start to do professional testing in the very first Sprint. This is much earlier than in Waterfall, as you know. Many reasons for this; among them, we can measure progress by the amount of completed, 'fully' tested code.
In Scrum, we have what we call a Definition of Done for the team. It defines, for the typical 'story' they are working on, how 'done' the story will get to. Like the meat metaphor: rare, medium rare, medium, medium-well, and well done.
Fully done, done, done means the product (and the newly finished stories) is/are in production and being used by the customer with no problems. Most teams have too many impediments to get to done, done, done in one Sprint (1-4 weeks). At first.
The Definition of Done should also make clear, especially for the Product Owner, what is not being done in the Sprint. For example, often the team can't do a full, full regression test in a fully integrated environment. Often (full) performance testing can't be done. Etc.
As Ken Schwaber suggests, this 'undone' work needs to be added to the Product Backlog somewhere.
Two reasons we don't like anything but 'done, done, done' product increments. (They are related reasons.)
1. The bad news is getting better with age. Meaning, of course, worse. For example, all the undiscovered bugs are quickly becoming harder and harder to fix.
2. The 90% problem is growing.
The 90% problem is, for example, very common in software development. A manager goes to a team and asks them how complete they are. They say 90%. And then he (usually a he) asks, 'how much longer to be 100% done?' And they say, 'oh, it took us about 9 months to get to here....ummm, that will be another 9 months.' Yogi Berra summarized this problem by saying: "It ain't over until it's over."
So, any time the Product Owner sees things in the Definition of Done that are not getting done in the Sprint, he should worry about the 90% problem and discuss them.
Technical Debt
What does this mean? Well, there is no one simple definition of technical debt. I say it is anything in or around the system that makes it harder to change.
Examples include: duplicative functions or modules in the code, spaghetti code, lack of automated tests, zero or poor documentation (in the code, perhaps), code written by George (when George has left the firm), the bug list, any upgrade (eg, to the database or the language or some middleware) that we have put off, etc, etc, etc.
Every system that is 6 months old has some technical debt. And it is starting to be obvious that it is hurting us. Older systems have more technical debt.
If your product is older than 2 years, I can just about guarantee that technical debt is a (very) serious problem in your shop. And that real velocity is (very) low.
In simple terms, technical debt decreases the velocity of Scrum teams.
We (seemingly purposefully) grow technical debt by saying "we have to deliver features now; let's put that stuff off until later." And then we do that. That 'that stuff' is identifying bugs, upgrading the XYZ, fixing bugs, etc.
Every manager must start understanding technical debt, and fight to get the team to dig out of technical debt. If you want any business agility. Meaning: We can adapt and change with the market and customers faster than our competition.
Impediments
As we discuss these matters, you will find that your shop (and every shop) will discover impediments. It is tempting to say: This is Scrum's fault! In fact, Scrum is only making the problems around quality and technical debt more visible. To blame Scrum is only to blame the messenger.
So, don't be surprised that the group identified a bunch of impediments. And that they cost money to fix. And that you will get real business results (better quality, eventually lower cost, etc.) from that.
How do we dig out of Technical Debt?
How do we improve the Definition of Done over time?
Mainly by removing or reducing (certain kinds of) impediments.
Quality Metrics
One way of minimizing and maybe reducing technical debt is to focus on quality.
Now, quality is itself a complex subject, and its full and complete nature depends on the specific product and your customers.
But in simplistic terms, one might say it is the lack of technical debt. Or one might say that it means the customer gets a perfectly fitting product (to her problem), with no added 'features' (eg, bugs), no extra delays, no extra effort.
As relatively low-level indicators of quality in Scrum, we can measure:
* no bugs escaped the Sprint this week. Meaning: For all the stories we say we completed in the Sprint, we did a professional (automated) testing effort (eg, unit and functional, at least), and any bugs identified were fixed and retested in the Sprint.
* X number of new automated tests were built this week (maybe one number at the unit level and another at the functional level)
* Y number of automated tests are passing in the regression tests this week.
* Our Definition of Done is relatively strong, meaning that, in areas 1-5, when a story is done, it means that no technical debt was built in those areas (at least). Or at least we made a serious effort to minimize the new technical debt being built.
* The list of (pre)existing bugs is prioritized, and shrunk by Z items or A% this week.
* We have prioritized the work around an increase of code coverage by the automated tests, and it increased B percentage points in the past week. (And these were meaningful, useful tests, not just baloney tests to make the coverage metrics look better.)
* We saw that in the last release, field issues decreased by C%, comparing first month to first month.
* Our velocity has increased X percent. This is in part due to less technical debt and in part due to less effort per unit of work...due to: better configuration management, better continuous integration, better testing tools, and faster testing servers. (* If you don't understand some of these terms, and how they are inter-linked, we should talk. You need to understand them a bit, since they are key to each (Scrum) team's success.)
Measuring quality is complicated, and my comments above are over-simplified. But, if the business and technology folks both know you care about quality, that will help a lot. A reasonable, and fairly frequent, discussion around quality metrics can help focus their attention on that. Be careful about getting too focused on one aspect of quality, one metric. The keys are (a) higher quality for the customer, as the customer defines quality, and (b) lower technical debt.
Regards,
Joe
***
Again, please give me feedback. Did this all make sense? Or did some of it sound too geeky?
It is actually not all that geeky, but if there are some geeky terms that we need to explain, I think almost surely you need to learn them a bit. Not become an expert in them, just understand them enough to guide the product development group.
Also, please give feedback on what you want to discuss next.
No comments:
Post a Comment