This post is in continuation of the earlier post on the availability of new PMI-ACP Exam Prep book:
Book for PMI-ACP Exam Prep: I Want To Be An ACP, 2nd Edition
The excerpt is from Chapter – 7: Problem Detection and Resolution. This is one of my favorite topics. In my sessions as well I focus many times on these areas because your ability to solve problems will enable you to be a better agile practitioner. The excerpt here talks about Technical Debt and Cost of Change.
*********
In Agile, a strong focus is on minimizing the technical debt – a form of debt which accumulates if unattended, will have a high cost impact, when you try to change the system. Let’s take a real-world example. Many poor countries are poor because they took a lot of debt from outside bodies in their initial formation stages to build their countries, after being impoverished by colonial rule. Subsequently, due to bad fiscal management, poor governance and many times due to very high corruption, the debt kept on accumulating. In fact, most of the yearly revenue generated by these countries goes into paying off the debts, which is euphemistically called “debt-servicing”.
Real-world projects are similar. When you make a quick fix to meet a deadline or increase your delivery speed by cutting down the quality, avoid any form of documentation while coding, they lead to technical debt. And as is the nature of the debt – it never goes off, if you don’t work hard on it. Rather, it accumulates. When the debt reaches a very high level, you just can’t pay it off – because by that time cost of making those changes with respect to coding or documentation is going to be prohibitively high. Like our previous example with respect to countries, here, software systems or products developed with high technical debts are called “legacy systems” – easier words in place of saying “unchangeable system”!
In this domain, we see about cost of change, technical debts, impediments/impediment backlog, risk management; metrics to detect the problems such as lead time, cycle time, escaped defects and analyzing the variances and trends. We will also see how to solve the problems that arise, the methodical steps to solve and various problem-solving techniques.
So, what does this domain do? In simplified terms:
“Identify, prioritize and resolve problems, impediments and risks; Resolve and communicate status of them, have process improvement to prevent recurrence.”
As per PMI’s Exam Content Outline, “Problem Detection and Resolution” domain has no sub-domains, but has 5 related tasks.
This domain, effectively, is about detecting the problems, visualizing the problems and resolving the problems.
Note: Going forward, I’ll be using the word “problem” as an umbrella one – for issues, threats, risks, impediments etc. Whenever needed specifically, I’ll be using the individual terms such as risks or impediments.
...
...
7.2 Creating a Safe Environment
The 5th principle in Agile manifesto says this:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
You not only take motivated individuals in your project, but also give them the needed environment and support to succeed. Without a proper environment and associated safety, you just can’t expect the underlying/hidden issues or impediments to come up. This is why the first task in this domain is noted in the ECO as such.
“Task – 1: Create an open and safe environment by encouraging conversation and experimentation, in order to surface problems and impediments that are slowing the team down or preventing its ability to deliver value.”
As an Agile coach or manager, it is your job to provide the safe environment. Remember as a coach you also act as someone who guarantees safety? We have seen that earlier in Chapter – 5: Team Performance. A safe environment enables experimentation, failures and risk-taking ability.
7.3 Detecting and Visualizing Problems
Problems have to be detected early. The later they are detected, the harder they get to fix and more importantly, the costlier it becomes to fix. There is a term, which notes this phenomenon – cost of change.
7.3.1 Cost of Change
Take the case of traditional development in the waterfall model, which happens sequentially – from requirement analysis to deployment/operations.
If a mistake has been made during analysis and it gets detected, then it is cheaper to fix. However, if the same mistake happens during the deployment or operation stage, then it becomes costlier (may be 100X costlier) to be fixed. This is shown in the below diagram [3].
Simply put, cost of change is the cost involved to make changes possible in a system. As the time progresses, the cost of change also increases – exponentially.
The agile approach minimizes this exponential increase in cost of change. Here, we try to keep the cost of change as low as possible regardless of the point in the project’s life. The key idea here is this: a small change in requirement should result in a small change in implementation and hence cost. But, how does one do that?
- Iterative approach: where we take a certain amount of work items (product backlog items) to be delivered in a small timebox. The work items are delivered just in time (JIT) fashion, without having high inventory of documentation or artifacts as in sequential waterfall development.
- Detecting problems and deficiencies early. And resolving them early too. In other words, keeping the technical debt – debt related to unclean code, low quality code, deficiencies in document - as low as possible.
In Agile development, the cost of change is kept low. The inflection point – when the curve starts to go up exponentially – happens early in sequential/traditional development. This is due to high upfront planning and a lot of documentation and hence high cost of change [3]. However, the curve is more flattened in agile as compared to the sequential because of JIT approach and keeping technical debt low. This is shown below.
7.3.2 Technical Debt
Like debt, which if not worked upon and allowed to keep on accumulating, can create serious financial problems, technical debt if not removed, makes it very hard to work with code. However, technical debt is not related only to code; other factors such as quality of code, development environment etc. can also come into play.
Dan Rawthrone and Doug Shimp have defined technical debt in their book “Exploring Scrum: The Fundamentals”, which is noted below [21].
“Technical Debt consists of deficiencies in the code, technical documentation, development environments, 3rd-party tools, and development practices, which makes the code hard for the Team to change.”
Extreme Programming (XP) has been focused on producing clean code – code that the team can change easily. Technical debt is the one that prohibits keeping the code clean. Also, as noted above in the definition, other than code, there are deficiencies which can also create technical debt.
Now, removal of technical debt is important as it helps in keeping the cost of change or flattening the cost of change, as seen in the earlier section of this chapter.
If you plot the cost change with technical debt, the graph will come as follows.
As the graph says, with low technical debt, the cost change remains pretty much flat over a period of time [3].
7.3.2.1 Types of Technical Debt
There are 4 types of technical debt according to Dan Rawthrone and Doug Shimp [21]. They are:
- Lack of Tests: If the code isn’t tested, it will be very hard to change later. The developers working on the code later on to make the changes, will have very low confidence as the code has not been earlier tested. In fact, lack of tests is the biggest reason for technical debt!
- Bad Design: Bad design happens when the code is structured in a poor way.
- Lack of Technical Documentation: Note that it is mentioned to be a lack of technical documentation – not that you need to have exhaustive technical documentation. When a piece of code is written or changed, a certain amount of technical documentation needs to be there for the developers to understand.
- Poor Readability: This is primarily a piece of code which is difficult to read, popularly known as spaghetti code.
7.3.2.2 Preventing Technical Debt
There are ways to prevent technical debt. As the well-known saying goes: prevention is always better than cure. The ways can be:
...
...
*********
This chapter further explains on Risk Management in Agile environment covering: Risk Definition, Sources of Risk in Agile, Risk Management Workflow, Risk Probability and Impact Scales, Risk Map (Risk Grid), Risk Census, Risk Burndown Graph etc. Subsequently it addresses areas such as Impediments and Impediments Backlog, Metrics and Measurements, Cycle Time and Lead Time, Visualizing Problems with CFD, Escaped Defects etc.
Finally, it ends with "Resolving Problems", and "Problem Situations and Solutions", where many situational areas are covered and each one has been explained with possible solutions in addressing these problems. For example a problem can be: "too much complexity in product architecture leading to difficulty in estimation" with possible solutions such as "take a tracer bullet approach".
Book Available for ACP Exam Prep:
No comments:
Post a Comment
Sign- or Log-in and put your name while asking queries in comments. Any comment is welcome - comments, review or criticism. But off-topic, abusive, defamatory comments will be moderated or may be removed.