How (not) to spoil a perfect MVP with poor service? A story…

Agile is hot. Agility needs to be a driver throughout the organization to enable the velocity at which the market wants to consume. In a lot of organizations agile has been used in development for many years, so there is a good understanding of how to ‘be/do agile’. These organizations also learned that the only way to yield the benefits for their customer base is to use an integrated approach towards agile, involving operations.

This ‘three-part’ blog identifies and offers an answer to a specific challenge. The first part was written from an ‘operations’ perspective. It was already published earlier and can be found here. The third and last part provides the how-to’s and some take-aways. In this second part, I look at the ‘development’ side of it, and wrapped it up as a story. Welcome to part two!

The beginning

How can you introduce that readiness to take an agile shift, if you are still profitable as an organization? To answer that question, we need to go back five years. Yes, there was pressure on revenue. Yes, there were trends indicating a potential decline in market share. However, it was considered ‘business as usual’, as the organization was doing good business because of a loyal customer base. This was confirmed by yet another year of double-digit growth. The ‘Magnet Factor’ remained, according to the board.

The Agile kick-off (short version)

There were multiple attempts to introduce agile in the organization:

1. The first attempt to go agile was driven by a few developers who liked what they had learned during a conference. Obviously, this didn’t get far, as it did not fit into ‘the way development worked’ in the organization. With the statement ‘We are not a start-up!’ it got dismissed by senior management.

Lesson learned: Don’t introduce a framework within the boundaries of a (development) team, if it requires a broader involvement.

2. A team of business analysts was responsible for the second attempt. A business unit was suffering, because they saw a decline in successful selling cycles, because of a ‘niche player’. They pushed the analysts to speed up the requirements into the products. Developers welcomed this, but the Software Development Lifecycle was not made for speed. Due to the organizational impact, it was decided to consider this an acceptable risk. Case closed.

Lesson learned: ‘Business as usual’ regulates the organizational willingness to change.

This was about to change when one of the biggest customers awarded a contract to a start-up. It was an insignificant player in the market, but one who was able to offer a functionality at a price way below what was considered ‘market conform’. Some research learned they were delivering ‘just that’. Obviously, they go low on price, and fast on delivery. Case closed. Magnet Factor was still intact…

3. That case reopened when the enterprise architects understood that the risk was anything but acceptable. To prepare all stakeholders, they started building momentum using different means to create the agile awareness. Face-to-face communications, presentations at team and business meetings, articles in the Magnet, the company magazine... This ‘buzz’ caught the attention of senior management, resulting in a fifteen-minute presentation slot on their quarterly Global Management Board Meeting.

Lesson learned: Involve the right stakeholders to get the message across.

Agile: the transformation

Looking back into the journey after five years, these fifteen minutes were the very beginning of the agile journey. During the five following years, the whole development organization gradually transformed. And boy, it was a bumpy ride. Transforming the legacy applications opened doors, which nobody knew existed. Amazing how IT has a tendency to stack-up capabilities to make new things, and stack-up some more to make them work afterwards. They surely had their share of dead corpses dropping out of closets while diving into the ‘application discovery tours’ as they used to call them.

The impact of the introduction of the agile framework on the developers was seriously underestimated. The agile approach required them to participate actively in the decision process, talk and give feedback, understand team dynamics, commit to their agreed delivery, present results during retrospectives... In hindsight, the first big planning looked more like an organizational war room session rather than a Program Increment Planning. There was experimentation, learning, failing, improving and occasionally a first time right attempt. Did I say it was a bumpy ride? Yes, but customers noticed a new vibe from the very beginning, as functionalities were provided much faster. As agile grew into the new ‘business as usual’, the voice of the customer only confirmed the journey was evolving in the right direction.

Today, the organization is considered a reference in the agile community. All aspects of agile driven development are incorporated. Even the corporate magazine is renamed. It is called the ‘Agile Magnet’, a recognition that agile is a cornerstone of ‘how we are’ as a development organization.

The agile teams can keep the promise of delivering, time and time again. Take the last sprint, they needed to redesign the screen of a business critical application for better ergonomics, but it all worked out like a charm. They even included the latest two-way authentication to be compliant with the new security standard. During the retrospective, business was excited. This was the game changer they were waiting for. Because of the integrated CI/CD pipe, it was only a formality to get the functionality available for the customer base.

Meanwhile in operations…

The agile success within development had triggered IT operations to organize their own ‘stand-up’ sessions. As any other day, the operations team got together for a short recap on what was on the agenda for that day, which were the open incidents and what operational activities were scheduled. Time to get started.

It soon became clear that something happened. Calls started to come in as soon as the service desk opened their virtual doors. Customers were complaining about the business critical application not being accessible. This triggered a priority one incident. After initial diagnosis based on the information available, first line decided they could not solve it. The incident got forwarded to second line. Must be network. No. Must be firewall. No. Must be server. No. Must be database… No. Tick tack, tick tack… precious time lost… SLA breached… More customers complaining…

By now, the incident was promoted to major incident, bringing it to the attention of management throughout the organization and the business. Only at that point, the application team responsible for the launch of the functionality flagged what they did. Their further involvement remediated the incident after which all customers were contacted to explain what had happened.

Definition of D..euh

So why this story? Is it something you recognize? Is your organizational agile movement also impacted by operations who lack the capability to keep up with the speed of delivery? Is there a disconnection between build and run? I call it ‘the definition of d..euh’? This comprises all situations of support in which the only response is ‘I have no clue of what is going on.’

How can you connect build and run in one ‘end-to-end’ flow? How can you make sure agile investments and their resulting MVPs integrate with the same agile mindset into operations, and ultimately with the customers who a looking for the promised value experience?

In my third blog, we transform the ‘definition of d..euh’ into the ‘definition of delight’, connecting the MVP (Minimal Viable Product) with the MVS (Maximum Viable Service), allowing that ‘always-on’ value experience. You can find it here.