Just a heads up – everything here is purely my perspective, just a random dude on the internet sharing some thoughts.

‍

Frustration phase

I've worked for quite a few companies during my career, both directly for a client or for a consultancy offering services to a company. Regardless of the situation, one thing I found to be common: developers were often implementing the wrong thing. It wasn't what the client envisioned. As soon as that feature reached Production and the actual end user used it, something was off. This got worse the bigger the team. At some point there were so many bugs being raised that the dev team was spending most of its time fixing last sprint's bugs, rather than implementing new features.

Something had to be done.

Project Context

• Multi-million dollar project
• Client uses consultancy to deliver the software
• Client doesn't want to pay top dollar for the implementation services
• Consultancy sometimes uses offshore developers
• Team is scattered across several time zones
• Very tight project deadlines
• Multiple project streams running in parallel, converging in the same core products.
• "Agile" methodologies, but with very strict boundaries and ceremonies
• Stakeholders always too busy to help, give feedback or look at prototypes, but very eager to see results

Experimentation phase

At first we thought we could simply improve the code quality. We added some code analysis tools, bumped up the minimum code coverage threshold and waited a bit to see the results. There were marginally fewer bugs overall, but the time required to fix them increased ever so slightly.

Right, so let's try and reduce the feedback loop. How? Re-engineer the automated pipelines to run faster so we get quicker and more frequent deployments. The result - a slight reduction in bugs reaching Production. However, the DevOps team was now overwhelmed coordinating all deployments, investigating failures and maintaining the pipelines.

Still, loads of bugs are seeping through to Production. Let's increase the UAT time! Easy, modify the calendar a bit and we have double the time. However, the people required to do the UAT (the end users) aren't really available for that long, so in reality we've just lost a few days of dev time.

Seems like everything we tried couldn't significantly (let's say by 50%) reduce the number of bugs. Time for an in depth root cause analysis.

Investigation phase

I set out to find the actual cause of these bugs. I did a multi-week investigation, talking to several teams, going through each job role and trying to see the world from their perspective. In isolation, each member was mostly doing their job properly, or blaming another team. Couldn't find any red flags based off what they were telling me.

So I started looking at the actual artifacts they were producing - meetings, notes, documentation, code, conversations. I was surprised by how little information I could find related to a particular feature. How did the developers know what to build? The User Stories were very light, and the devs weren't communicating with the Business Analysts or the Stakeholders? They didn't even know who they should speak to when asking for clarifications. Their go-to person was their Team Lead, who was always too busy to help them. And when the lead found some precious time, they just expressed their opinion on what should be created, instead of checking with Stakeholders. There was no time for collaboration or taking a step back to analyze the situation from holistic perspective.

After putting all the pieces together, the whole process looked something like this:

The place where productivity goes to die

Then it dawned on me - companies are expecting software to be delivered similar to a factory. Each step depends on the previous, but without any loops. All teams carefully separated in silos. Each member is an expert in its own small field and doesn't need to know what's happening around them.

The are several problems with the factory approach:

1. You need an excellent factory pipeline, planned in every detail. And you then need a system to monitor and react to the pipeline progress. And then, if there is a problem with one area of the pipeline, everything stops, a workaround is found, corners are cut, quality is compromised.
2. The same factory rules need to be enforced on everybody. If one member plays out of sync, the whole process falls apart. Or if the factory pipeline changes, everybody needs to be immediately made aware. Conversely, new joiners need to understand their role very well and follow it precisely.
3. Garbage in, garbage out. The quality of the final product depends on the raw materials passed into the pipeline.

Solution

This issue of misalignment between what the customer wanted and what we ended up delivering could be solved by a truly Agile process. In this ideal world, team members would collaborate seamlessly, with frequent touchpoints and feedback loops to ensure alignment throughout the development process. Teams would maybe work from the same office, and would be empowered to talk to anybody to ask for clarifications. The stakeholders would have a look at the feature at regular intervals throughout its development, offering feedback along the way. Developers would confidently refactor code and deploy frequently, balancing speed with the quality needed to catch mistakes early. The artifact that ends up in Production would be highly familiar to the end user, because they saw it and used it many times while it was being developed.

Unfortunately, in the real world of some projects that use offshore development, that simply isn't possible. It would require a change in mentality that is so far from what management is currently used to, they wouldn't dare try.

So if you can't fight them, join them, right?

Well, yes, but bring a tool along to help you. This is where Ogg comes in. It acknowledges the challenges that an offshore setup poses and tries to work around them by focusing on the quality and detail of the User Stories. With Ogg, the factory approach still works because:

1. You can have an excellent factory pipeline - you just configure it in Ogg's easy to use Project Settings template, seamlessly integrated into your project management software (e.g. Jira or Azure DevOps).
2. The same factory rules enforced on everybody - Ogg will enforce the Definition Of Ready configured in step 1.
3. Garbage in, clarity out - You start out with a poor User Story, but with the help of the Ogg Agents you will quickly iterate towards a high quality, detailed, gap-free User Story.

To experience how Ogg enhances collaboration and improves the quality of user stories, sign up for a free trial at intriq.io and see the difference firsthand.