In Agile Consulting, my work comes in many shapes and sizes. In this consultant role, I work on the skills and standards needed for my clients to be proficient in their line of work. On this particular occasion, my Agile Consulting work was with a client (we’ll call this client Acme Marketing and Technology) who delivers technology and marketing services in a Scrum/Agile-like manner. Acme had an unhappy client. Their client (we’ll call the client Joe) was experiencing cost overruns and was confused as to why the projected range was being exceeded. The customer was upset. That’s where I came in; to help Acme and Joe better understand the two common issues which directly drive up cost overruns.
Agile Consulting Issue #1: Discovery Of Technical Debt
The first issue was the discovery of technical debt in legacy technologies (Read here for more explanation of Technical Debt)1 which was making the new features difficult to implement.
Quick Aside: The problem with technical debt is that it often goes undetected until it builds up into a big problem. Existing technical debt needs to be detected early so that we can actively manage it and mitigate its negative influence. By the time the unmanaged technical debt is detected, you suddenly have a large problem on your hands that opens up like a giant sinkhole.
In this particular case, Joe had a previous builder of the website that had left behind a large amount of unmanaged technical debt and the client had failed to detect it. Compounding the discovery of technical debt was Acme’s failure to fully apprise Joe of the technical debt once they discovered it and the subsequent impact to workflow.
Quick Aside: Dealing with Technical Debt in-house or through contractors is often a game of discovery and in either case, it must be aggressively managed. Yes, dealing with it can become very expensive with a gloomy end to your technology project endeavor. It is the number one killer of technology & marketing solutions when left unmanaged.
Typical concerns for clients I find in Agile Consulting are that they don’t know if the contractor is giving them a straight story and the difficulty they experience in getting a second opinion. The details of Technical Debt are confusing and not easily understood. However, clients expect short sound bite translations that convey massive amounts of information in a few words. Without a strong background in related technologies and system development, there is no such translation that easily works, except for the words ‘Technical Debt.’ And even with that background, it is hard to fully understand what someone else is encountering. Technical Debt is a hard problem.
Agile Consulting Issue #2: Delay In Decision-Making
The second issue that Acme was encountering was a delay in decision-making from Joe. Once work had started, delays in making decisions resulted in increased costs. Having someone available to make responsive decisions on what to spend money on is essential to keep work flowing smoothly. In legal terms, we hear things like, “time is of the essence” to note that there are significant costs involved for not responding quickly. Joe’s decision-making was not responsive enough to enable Acme to manage its work.
Unfortunately, responsive decision-making was hard for Joe to do by himself because he didn’t have the technology and marketing expertise to fully understand the choices. Typically, understanding complex technology stacks2 requires significant discussions with the technical team. This had not been happening.
Joe’s frustration led him to seek a fixed-price bid from Acme in order to control costs. Acme doesn’t do fixed-price bids, for two very good reasons:
- Acme’s clients often need to make tough decisions that require complicated discussions with the Acme team. These discussions (inherently) have unknown cost, and
- Fixed-Price bids often lead to Technical Debt.
Once Acme explained their reasoning, Joe was appreciative, and actually relieved he wasn’t in a fixed-price bid.
Quick Aside: Here’s why fixed-price bids often lead to Technical Debt. In a fixed-price bid, the contractor takes on the risk of a project which often results in optimizing delivery at the expense of quality (aka accumulated Technical Debt). In other words, there is a force in fixed-price thinking that encourages people to optimize for rapid delivery, often cutting corners on quality to do so. Given today’s abundance of complex technology stacks, this is a failed approach and always has been. Fixed-price thinking only works for trivial problems and, even then, encourages the development of sub-optimal solutions. Sub-optimal solutions in technology have impacts on “Total Cost of Ownership”.
Risk #1 and Risk #2
There are two common risks that we encounter when managing complex technology and marketing work products.
Risk 1: Predictability of making changes to existing work products becomes challenged due to unmanaged increases in technical debt.
Risk 2: The person who implemented a particular solution has done so in a proprietary manner that makes it difficult for someone else to change.
If you combine Risks 1 and 2 with poor transparency, you have a technology stack that quickly reaches its end of life before it has made a significant ROI. As a result, detection and subsequent mitigation occur too long after the fact, driving the Total Cost of Ownership up in an unsustainable manner. If both risks are realized then the organization’s ability to be responsive to opportunity is severely impaired, and the organization is left without the technical knowledge to make changes and with a hidden technical mess.
3 Steps To Combat Risk
In Agile Consulting, we recommend combatting these risks with 3 mitigating steps which lead to a lower Total Cost of Ownership.
- Use a robust Standard of Care (SoC)3, based on work type, to improve predictability of work in small increments.
- Encourage Well-Formed Team™ (WFT)4 behaviors so that an organic amount of cross learning, training, and peer review which happens ensures quality is maintained and technical debt is contained.
- Keep Feedback Rhythms short to:
- Confirm a SoC is being used
- Stay on Purpose, and
- Keep responsive in decision making;
All of which allows us to adjust quickly and manage expectations.
Acme took the necessary steps to combat risks by working visibly, engaging in WFT behaviors and insisting on a SoC. Joe is now happy. Moving forward, these steps propelled Acme to deliver Technology & Marketing solutions that help their clients “Drive Results” across all aspects of their business.
Is your organization falling prey to their own tale of 2 Issues and 2 Risks?
Our Agile Consultants can help.
Gain groundbreaking Agile insight to make Scrum work better for your Team
That’s what our newest white paper, Scrum 3.0 is all about.
Pre-order Scrum 3.0 now to receive your copy when it’s available.
As Always, Stay Agile.
Notes, and Sources
1 For an expanded conversation of Technical Debt. see 3Back’s blog, So What is Technical Debt in Scrum, Anyways?
2 Technology Stack: The set of underlying software, that provides the rich interactive behavior a user experiences when they use a website or application.
3 The term Standard of Care is the use of prudence, caution, processes, and procedures that professionals use when doing their work. The SoC used depends on the type of work; each type of work intrinsically has its own SoC. A SoC captures re-useful information common to different types of work and is often captured in a formal manner. SoC is the repeatable aspects of work that allow us to detect and manage change; it serves as a baseline or reference point. Failure to meet the SoC is negligence, and being negligent makes you accountable for any damages that result. For greater discussion in Standard of Care, reference 3Back’s white paper, Done.
4 A detailed explanation of Well-Formed Team behaviors may be found in 3Back’s white paper, The Well-Formed Team™.