Tag: project management

Scope Like Goldilocks

How to control scope and navigate the spectrum of engineering excellence versus business needs

Image for post

Photo by Toa Heftiba Şinca from Pexels

There is no single right answer to any non-trivial problem in software engineering. So, if multiple correct solutions exist, how do you decide which is best? It’s difficult to determine which is best because “best” is highly subjective and deeply personal — your opinion is formed from your individual collection of experiences, strengths & weaknesses, and values on related aspects like simplicity, maintainability, & scalability.

It’s these internal values that make all of this so tricky. Imagine a spectrum with engineering excellence at one end and business needs at the other. Both elements are required for a project to be successful, and operating at either extreme can be detrimental to the other. As an example, making too many quick-twitch fixes to address urgent business needs can have significant long-term impact on the quality of the code base or system maintainability; conversely, focusing too deeply on engineering excellence can lead to over-investment in areas or competitive disadvantages from being slow to market.

Image for post

Understanding this spectrum — and having awareness of where you and your colleagues lie on it — can help your team to be more pragmatic.

Awareness of this spectrum alone isn’t going to do you any favors in resolving conflict from perceived disconnects between you and co-workers, though. I’ve found myself in design/requirements stalemates many times, and I’ve used the spectrum as a way to visualize my frustration.

“You see, I live over here on one end of the spectrum,” I’d say, “and my colleague operates here, at the other end. We can’t agree on scope, and we aren’t getting started or making any progress as a result.”

The problem with the visualization as a tool for conflict resolution is those pesky personal values. Neither of us thinks we’re advocating for a solution that would be in the unhealthy extremes of the spectrum. The person in the engineering excellence camp just believes that business value is generated by following all the best engineering principles and creating scalable, high-performing, resilient applications whereas business needs nation wants quick delivery and maximum responsiveness to meet the ever-changing needs of its customers.

So, how do you find compromise when the source of conflict is so visceral?

Let’s see if we can steal a page from the Goldilocks playbook. She’s got a knack for identifying the undesirable ends of a spectrum before settling into a satisfying sweet spot. If you and your team or colleague(s) can’t agree on the scope of a solution, can you agree on what it shouldn’t be?

What’s a reasonable solution that everybody agrees is over-engineered, and what’s the fastest, but perhaps short-sighted, thing you could do? What’s the effort required for each approach, and what are the risks or consequences?

Just to be clear, I’m not suggesting to simply compare different proposals by plotting them on the spectrum— that probably won’t get you anywhere. Instead, work collaboratively to come up with bad solutions that lean too far in both directions. Find agreement by identifying undesirable characteristics of these options in the unhealthy parts of the spectrum.

Still not able to find compromise? It’s probably time to bring in a 3rd party, preferably a stakeholder. Show them your spectrum and explain the tradeoffs that exist at the opposite ends, then present the “real” options that are on the table and allow the stakeholder to decide.

The whole activity is an exercise in pragmatism. How can two parties with equal but conflicting opinions find common ground? The key is to calibrate and remove as much subjectivity as you can. By acknowledging the necessity of both aspects — engineering excellence and needs of the business — and agreeing on the “bounds” of the spectrum, you create a framework for identifying the region for compromise. That’s your sweet spot. That’s likely where your “best” solution should be.

Originally published at The Startup on September 21, 2020.

Extra McNugget Sauce, Scope Control, and Expectations Management

One of the biggest challenges that my team faces when working with customers on a software development project is controlling scope. These projects begin with a contract followed by a formal requirements document that must be signed by the customer prior to beginning development work. We’re realistic about this process; we don’t expect that every requirement will be correctly identified upfront, and we’re willing to work with the customer throughout the development process to ensure that their needs are met.

Occasionally, we’ll find ourselves working with customers that keep pushing scope, little by little, until the project has been stretched so far beyond the original requirements that we’re not sure how we got there. Kudos to that customer for getting some serious bang for their buck, but at some point we, the development team, need to draw the line. The problem in a lot of these scenarios is that we’ve given and given and given with little or no resistance. We’ve set the expectation that if they ask for something, we’ll give it to them. We can find ourselves with a customer that’s unhappy about being cut off despite delivering a lot more than was originally bargained for.

This scenario has two major flaws. There’s obviously the issue of scope control, but expectations management for the customer is equally problematic.

I like to use a McNugget sauce analogy here. If you go to McDonald’s five times and get an extra sauce with your McNuggets for free, you’re happy. But then, on the sixth visit, maybe you get charged for the extra sauce because it’s the restaurant’s policy. This would upset a lot of people. “This is an outrage! I come here every Tuesday, and every time I get an extra sauce. I have never been charged for it before.” Rather than being happy about getting the extra sauce for free the first five times, they’re upset about not getting it for free the sixth time. However, if the McDonald’s employee were to let you know, “Hey, we’re supposed to charge for extra sauce, but I’ll let you have it for free this time,” then you’re less likely to feel like you’re being unjustly charged when you’re eventually asked to pay.

The same philosophy can be applied to our software development projects. When the customer makes that first seemingly innocuous, out-of-scope request, let them know that you’re doing them a little favor. “This request is out of scope, but I can see where it would be valuable. I’ll discuss this with the team to see if we can fit it in.” If you decide to do it, be sure to let them know that you’re making an exception this time. Finally, document that you gave them some “extra sauce” so that when/if you need to push back on a request, you can show them everything they’ve already gotten for “free.”

Getting back to the McNugget sauce analogy, some folks would still probably be upset about being made to pay even when they’ve been notified that they should be charged for the sauce they’re getting for free. “I know it’s not supposed to be free, but this is the first time I’ve ever been asked to pay. Get me the manager!” In response to that, I’d say an equally valid takeaway from this article is, “Do not give away [too much|any] extra sauce for free.”

Make the Invisible More Visible

A co-worker sent me a link to an article from the Embedded Linux Conference (ELC) where the author spoke with Robert Rose of SpaceX about lessons learned, primarily related to software development. The article references an essay titled Make the Invisible More Visible, from the book 97 Things Every Programmer Should Know. I really like some of the points the essay makes about the danger of invisibility in the development process. I particularly like these two points:

  • If you’re 90% done and endlessly stuck trying to debug your way through the last 10% then you’re not 90% done
  • Lack of visible progress is synonymous with lack of progress

These two statements really go hand in hand. In my experience, developers will often say they’re 80 or 90 percent done when they feel like they’re close to done (or that they should be close to done). In many cases, “90% done” is an arbitrary measure of progress, manufactured to give the illusion that things are on track. Typically in these situations, we’re looking at projects with loosely-defined requirements and insufficient planning. The developer was given a task and hit the ground coding without thinking about the big picture.

Without understanding what’s left, developers can’t be held accountable. When I ask a developer whose been working on a project for two weeks how far along they are, it seems pretty good when they report 80 percent. When I come back a week later and ask for another update, maybe they’re at 90 percent. “Progress has slowed down,” I think to myself, “but at least we should be done next week.” Next week comes along, and now we’re up to 95 percent. This is a perfect illustration of the points above.

In this scenario, the developer reported being at 80% when clearly they weren’t. There was no visibility to what they had accomplished or had yet to accomplish, so the measure was based on feelings—which proved to be completely inaccurate. But how can this be avoided? Here’s my advice: know what you’re coding before you start coding. I’m not talking about classes and methods, though; I’m talking about features and requirements. If you follow agile methodologies, you should be familiar with the concept of user stories. Before you start working on a project, take the time to understand and document the stories required to complete the project. This brings visibility to the project as well as giving you a calculation-based measure of completion percentage. There’s no question about what’s been accomplished and what’s left. As long as you keep completing stories, consistent progress is all but guaranteed.

But what if it’s just a lot of stuff that comes up during testing? If you’re writing good stories with solid completion criteria, you shouldn’t be finding a lot during testing. Additionally, you should be creating automated unit tests to verify what you’re doing and what you’ve done. The automated tests ensure that functionality added early in the development process isn’t affected by functionality added later.

Other features keep popping up; how do I manage those? This depends on the source of the new features. If it’s something that you missed, you just need to be aware of this and improve over time. With practice, you’ll get better and learn what types of things you commonly miss. Peer review can really help with this, too. Sit down with a buddy and walk them through what you’ve got, or work together to come up with the requirements from the beginning. With two of you, you’ll be less likely to miss something. If the source is external—like bosses and customers—your best bet is open, honest communication. This is textbook scope creep, so let them know what the impact of their request will be. “Sure, we can do that, but it’s going to take us an extra two weeks.” If it’s not in the budget, you have to push back or barter. “I’m sorry, but that’s out of scope, and we don’t have the capacity to add that requirement” or, “We can only implement that functionality if we leave out these other two things.”