Solving overengineering and DEMO readiness problems with PS+

Target audience:   
- Read if you need to deliver something super-fast for DEMO (Say you're a startup making a prototype or thriving to reach a milestone to secure the next investment round);  
- Read if you find too many code-refactoring-related tasks in your boards while your business features release falls behind;  
- Read if you want to increase the quality of cooperation with the customer for who you develop software;  
- Read if you want to help your engineering team with setting priorities on the technical planning level;  
- Read if you feel that your engineering team does unnecessary things, but you don't know how to check it;  
- Read if you're curious.

I learned what overengineering is much earlier before I came to the software development business over a decade ago. In short, it is when engineers come up with technical solutions that are much more complex than necessary for the task at hand. This is another extreme of under-engineering (or underspecifying) when the given technical solution is insufficient.

The roots of overengineering can come in many forms. It can be the desire to please someone or the desire to impress. It can be a lack of competence or a lack of priorities. The very fact of the high competence of your team per se doesn't guarantee that you won't face this issue. Since one of the generic requirements for pretty much any software product is “to be scalable”, a huge ton of overengineering is being covered under this reason. Whether the team admits it or not, that's a different story.

Among ten software projects, you barely see one or two teams discussing overengineering and doing retrospectives to understand “where the code could be written less”. Depending on project circumstances, the team's mindset shifts between “working product at any cost” and “we don't have time; let's cut off the scope”.

When I first tapped into the world of software development, I was researching all available project management literature to understand the main project risks. To this day, regardless of which book you'll read or which course you'll enroll in, lecturers will often talk the same.  
They talk about time management, Kanban board setup (Columns quantity, workflow), WIP limits (limiting the maximum of cards in the “In Progress” column per team member), daily standups, team coordination, etc. What they don't talk about (neither then nor now) is how the manager can get involved in the technical talks of the project team.

From the standard perspective, managers (I omit whether we talk about project or product managers here) should work with what they have. If the PRD was decomposed to X amount of stories, and those stories were broken into a few dozen tasks, so be it. Help your team to deliver those on time and within budget, and you win.

At first, it might seem that the manager doesn't have much to do with overengineering. And this seems obvious as the manager is usually not technically savvy enough to participate in in-depth technical discussions with engineers. On the other hand, this is exactly the type of discussion where overengineering appears.

As our disclaimer at the beginning of the article says, we talk about software development service companies here. This means that the project team should deliver X project within Y time and Z budget. Any such project has a number of stakeholders that often request DEMOs. And successful DEMOs are super important for the service company's business.

Successful DEMO allows the company to shine in the eyes of the customer, earn trust, build fruitful relationships, and show the customer the choice they've made was the right one. Within the scope of a single, one-year-long project, you might have somewhat from 4 to 12 DEMOs, depending on the initial agreements. Each DEMO is a highly-sensitive ritual, where the stakeholder often wants you not to screw up even more than you do. They want to know that you're on the same page with them and there were no misunderstandings.

In other words, DEMO is a perfect way to show your competence and understanding of your customer's business. Obviously, we can endlessly continue this list of “Why a good demo is good”, so let's stop here and think about what overengineering has to do with DEMOs?

The problem with DEMOs is that the engineering team and the customer see them differently. Within two development sprints, the engineering team can develop several endpoints, fully documented APIs, data handlers, and a lot of heavy-technical solutions. Still, the customer won't care about it if “I clicked on ”Submit", and nothing happened." The customer thinks of the software in terms of business workflows, similar to “user workflows” or “user journeys” in modern terminology.

I've seen this problem many times, and after each DEMO where the stakeholders had mixed feelings, I had to go back to our engineering team that was waiting for me with visible excitement. They were excited because “We've implemented X and Y and solved Z issue in a few weeks!” And now I had to explain to them, "Okay guys, the solution you've come up with was good, but…”

Every experienced manager knows how unpleasant such dialogue is. Often such dialogues end up with some engineer saying, “You told us to implement this, and we did. This was the problem with your priorities. What did we do wrong?” And that engineer is often right. The team didn't do anything wrong. They have implemented what was expected by the management. The only problem is that they didn't pay attention to some tiny details that were “nothing” in the eye of an engineer but “everything” for the stakeholder's business. And instead of focusing on what's needed for the business, they overengineered some part of the solution. But how could they do otherwise?

We faced the same issue with one of our customers at the beginning of 2022 at The Software Development Company. We had an A+ team of senior engineers who could develop extremely interesting solutions to not less interesting, sophisticated problems. Still, some of our DEMOs were poor, and one customer was episodically unhappy. As we were optimization-driven, and we've been polishing our processes 24/7, day and night, we've decided to find the roots of the problem.

When talking to engineers, everything was great and “almost ready”. When we looked at the JIRA burndown charts and task statuses pie chart, everything was “almost ready”. So how come our reality so differs from the reality of our customers?

The problem was in “readiness” term understanding. The customers didn't care about the code-base readiness of the project. They didn't care about the number of completed tickets. They wanted to do “Click, double click, data input, enter, voila!"

Obviously, this was not a huge invention in our reality, as we thought of this many times before. So we talked to our engineers and showed them the customer's perspective in a few sentences that could be considered the essence of the PRD we had. The sentences looked like “The Admin can create and edit pages A, B, and C. The Admin can schedule a notification for user groups X, Y, and Z.” One of the engineers looked at this and said with contempt, “If you literally want us to have just this, I can make it work in a day!”

“And what were you doing the rest of 89 days?” I asked. “We had to solve scalability issues on the database and network level; we had to…” etc. There was a long speech about how many things must be done to satisfy engineers. After some tricky questions in this discussion, we agreed that 10-15% of the engineering was unnecessary. Later, the number was brought to 30%. Thirty percent of coding could be avoided if we could better help the team understand business priorities!

Of course, eventually, we'll deliver everything as per the contract. The only thing will be that in the eye of the customer, it will look like a miracle (They screwed up 4 DEMOs in a row, and now look at them - everything works. Where is the catch?). Obviously, such an approach won't help us maintain a healthy and friendly (if possible) relationship with the customer.

It so happened that I was participating in one internal DEMO of the project soon after this meeting. At some point, one of our talented QAs, Luiza, shared her screen to show the list of features implemented on the project and the ones not. The document consisted of somewhat ten sentences written in a google spreadsheet and contained the core functionality from the PRD, which was a few thousand sentences long. Some sentences were full yellow, meaning - done, whereas others were colored partially. That was when I realized how useful such a thing might be for QAs and the engineering and management team.

With the management team (project managers, product managers, chief engineers, and QA chief engineer), we agreed to create a Google spreadsheet for every running project and call it a “DEMO Readiness". In that spreadsheet, the responsible product managers had to squeeze huge PRDs so we could have a maximum of a dozen sentences written in a business manner to reflect customers' expectations.

So if the PRD contained a few major paragraphs of details of some “ABC” feature of the product in the “Demo Readiness” document, we might use a single sentence saying, “The Admin should be able to edit X, Y, and Z pages”.

Then, we agreed with the QA team so they could go through the spreadsheet and mark the functionality ready in bold.

Then we wrote a script in a spreadsheet that calculates the number of characters and excluded special symbols, spaces, etc. And then, we enhanced the script to count the percent of bold text VS overall and give us a percent (We used App Script by Google. Our code for the bold-counting app is here (Disclaimer: This was written by a project manager. Not an engineer):

After that, we generated a chart and embedded it into our PRDs next to JIRA tickets completion:

And the last thing was to introduce this to the engineering team, our tech. leads on projects, and asks them to make an ideological shift in their priorities when they conduct technical planning. From now on, we agreed that instead of trying to increase the quality of “Done” on the left chart (Jira Tickets), we'd focus on increasing the number of “Done” on the right (DEMO Readiness).

This means that anytime when the engineering team member feels that they have done something unnecessary, they can just check the DEMO Readiness spreadsheet and think whether what they plan to do will help them mark some part of the sentence in bold.

The image above clearly illustrates the problem we had. While we were sure we were on the right track and the project was almost ready (81.8% in JIRA), the customer felt that nothing had changed (65.1% done from the customer's perspective).

After applying this concept of DEMO Readiness, in a short matter of time, we were able to make this shift:

What was “not interesting enough” and “plane” in the eye of the engineering team generated an extreme amount of value for the customer and ourselves.

It's already been one year since we used this, and the PoC of this weird approach is successful. We use the Demo Readiness spreadsheet to compose our agenda for planning our DEMO flows. We use DEMO Readiness Chart to gain insights into the project development dynamics. And we even integrate it into our company Admin Panel - the sacred place we've built to keep an eye on the statuses of our projects:

Still, the idea is pretty weird. We literally measure the project status by counting bold symbols VS overall symbols in a spreadsheet. But the fact is that such an ideological shift allowed us to ensure our customer happiness. Still, we do our engineering and overengineering, but we do it only when we are sure that the customer's business needs are met, and we have spare time.

Oh, and regarding the PS+ thing. Initially, when we wanted to come up with the name of this approach, we called it “Project Status Plus”, meaning that this approach allows you to track the status of your project and gives you a ton of other insights as well.