You’re not a weak developer if you don’t always show off your technical excellence

If you’re a customer – hey, please stand in a queue. Your requirements are not as important, at least not like integrating our code baseline with this 3rd party service with unexpected behavior and undocumented API.

It seems to be a common issue many developers have. 

So, let’s change our angle of view to the perspective of the Customer.

When we find ourselves becoming selfish developers…

In this ideally symbiotic life where both parties benefit, the Customer would like to wake up with a good feeling about how much we care about them, ideally by regularly delivering them “presents,” regardless of their size.

Imagine being in a dark room with no clue when even a small light will shed perspective on what’s happening. If there’s no light for an extended period, you could feel sad, fear, or even anger. That’s how our customer feels when they don’t hear from us.

So, translated into developer language: on daily meetings, you might catch sight of some piece of code actually working in the integration environment (IO). It already has the potential to bring value to the customers but you also notice that it’s been there for days or weeks. 

If you dig deeper, you can usually find that there’s always more work to be done to achieve “perfect” functionality. This is often followed by comments like “there’s not much left to do, it’s working.”

I could look like a weak developer

To illustrate, let’s use an example.

We’re developing a Proof of Concept (PoC) for the new API, aimed at streamlining the usage of our web services and reducing the number of clicks required for use cases on the customer portal. We’ve already discussed the idea with the customer, and they are eagerly awaiting the first implementation – not with the intention of integrating it into production immediately, but rather to see how it performs. In this case, time should be short, at the expense of quality.

Now, here’s the catch: as a developer, I’ve identified some scenarios where the Use Case isn’t functioning as intended. While these issues aren’t critical for the PoC, it bothers me to leave them unresolved – it reflects poorly on my abilities as a developer.

And, that’s why I’m not so much oriented to customer, but to the code itself. Delivering excellent code into a “big monster” code baseline is a real challenge.

Now we see it, technical excellence is more satisfying than delivering customer value.

Value Stream is the key

When we realize the time for the master part will come sooner or later ( and also satisfaction with it), let’s add some discipline on the development side to give more prompt and frequent deliveries. 

Why? 

Because our customer hold hands on the steering wheel of our product and will tell us when to change the course and shift the gear. And that would not be possible if he does not see the road.

That’s where the Value Stream is coming to the surface: a set of actions that take place to add value to a customer from the initial request through realization of value by the customer. 

In developer’s dialogue, let’s maximize the response to customer requests and minimize the time needed to develop and deploy it. And remember, at the expense of scope or even quality if affordable.    

Wait, we’re slow?!

We realized that in our development department, we had an issue with Epic flow, which is directly related to Customer Value Streaming.

It appears that the Epics themselves required too much time to develop. As shown in the picture below, at the beginning of the year, we needed around 7 Sprints on average to develop a small feature, which is approximately 2 months.

If we factor in the time needed for definition, breakdown, and subsequent testing, and also take into account that the development pipeline is consistently full, requiring latent time to begin an Epic, this could easily extend to several months.

Consequently, this keeps customers in the dark.

It’s time to shorten the development time!

We identified what we would like to improve. Additionally, the development cycle time served as a simple KPI to indicate whether we were moving in the right direction.

Now, we needed to change our way of working to shorten the development time.

Through discussion and analysis, we discovered two main reasons:

• Epic requirements were either overflowing or unclear, which was the main obstacle to delivering frequently and in smaller increments. Therefore, we introduced discipline to challenge Epic size and split it into several smaller ones whenever possible. Additionally, we ensured that requirements were clarified before the development process began.
• The development team had too many work-in-progress (WIP) items. We found ourselves in a situation where one developer handled several Epics instead of having a few developers assigned to each Epic. This situation typically arises when an Epic is deemed “almost done,” and one person is left to finish it. However, the Epic often reveals additional work, trapping the developer in a solitary task. Therefore, acknowledging that work is only “Done” when it is actually “Delivered” helped refocus the entire team on completing the Epic. The team committed to finishing each Epic.

By the end, everyone was content

With time, as you can see from the picture, the situation got better. Not suddenly since the development pipeline was crossed over, but gradually. Of course, it was not only the KPI change that made us happy.

Actually, the changed behavior gave us a new perspective that was not seen before: the work (enclosed in Epic) that was the subject of the proposal for Development by the PM in the middle of September was developed and delivered to the production by the end of October. In a month!

So, Mr. Customer, what do you want to be in production next month?