“Discovery” is the most important step in building great software

There is a peculiar “agile” paradox in the enterprise software industry. Organizations want to adopt agile methodologies. They think that agility will allow them to make premature market release commitments to their upper management (using magic arts). They think they will be able to assign fixed work-hours on demand, and yet also maintain unwavering release dates.

These organizations often consult agile specialists in order to gain the power of these “magic arts.” Many of these specialists profit from irresponsible agile consulting, and sell solutions that largely ignore a key step: delivery. 

This really bothers me. 

Even when these methodologies are sudden and disruptive, the promise that agility offers outweighs the risks in the minds of decision makers. Large corporations and consulting firms are convinced to adopt complex, heavy frameworks that are difficult to get off the ground, and this type of agility ends up being unproductive, costly and complex. 

Given the situations that I have seen and experienced for more than a decade, I want to take a moment to talk about some of the stereotypes surrounding agility that infect the enterprise software industry. Then, I want to explain two aspects of agility that deserve more emphasis. 

The Agile Hipster

Agile hipsters, with their stickered laptops, with their tattoos and trimmed beards, have hurt this industry. 

Let me qualify: I don’t have anything against being fashionable and outside the cultural mainstream. I like hipsters, and I count many among my friends (I reiterate, I’m not qualifying their character; I’m making an allegory based on their profile :) ). 

What I do have a problem with is people who proffer and sell that modern, superficial perfume that represents the most attractive parts of the agile process and ignores the fundamental details that make the difference between success and failure. It never delivers.

What’s the perfume? Here’s what it ends up involving:

• Putting up boards, buying Post-Its. It’s talking about Kanban, SAFE, SCRUM, LEAN, Scrumban and countless other frameworks.

• Organizations then impose these frameworks on Product Owners, who only control their own small domains. These product owners have no autonomy to adopt or reject these decisions, and do not have a clear picture of how the business operates.

• Project offices then get implemented, and the completion speed of their user story points, their risk control boards, and executable tasks lists all need to be promoted and visible. There becomes a major emphasis to put them all in presentations, as if doing so will make the product run on its own.

• All efforts and requirements are estimated between the project manager and the client, leaving out those who actually know what it takes to execute.

• Here’s a typical situation: I'm clear about what I want, but I don't know how to do it. So, I bring in an expert advisor who tells others what I want through either an RFP or RFI. This same advisor tells me (pretty much) how long it's going to take. It’s typical that this consultant has never run a software company, nor has been a software product owner. They simply claim to have done many projects in the same sector.

Harry Potter syndrome

Teams that implement software development services try to win business by achieving the necessary project requirements set before them. This involves complex phases, many compromises, and making predictions as if they’re rubbing a crystal ball to see the future. They sometimes act as if they have a “Z” on their foreheads and can implement projects by reciting “Expecto Patronum in VueJS!”

 

Although this scenario is one of the reasons why the agile manifesto was created, it doesn’t change the fact that software developers are still often asked to evaluate and estimate with very little information. 

For my part, I prefer to simply say no. I ask my sales teams to be careful and direct. They need to tell the customer with complete honesty that we are not fortune tellers. The alternative to honesty is driven by greed, and winning for the sake of winning. It starts our customer relationship off with an immediate gap between expectations and reality. 

Before proposing solutions, technology, or estimations, it’s important to evaluate. It’s important to understand. This takes a lot of information that needs to materialize beforehand. 

We are not magicians. We are engineers, and we don’t do magic, we do software.

I would like to suggest a better approach.

Titanic tasks and delivery dates are good

Allow me to explain. I have seen many different levels and types of agile projects. I've been a frontline protagonist in selling 100% agile, global projects, and I've worked hand in hand with many other colleagues in promoting agile projects in Latin America. I also have very dear friends, who had a project they thought has always been agile, when in fact the project took two or more years to be that way. 

I have seen the benefits of agility for clients, given that they can “close the budget key” whenever they want. I have also learned to sell turnkey projects, given that a potential client understands their underlying differences and requirements after careful evaluation. 

In all cases, to have a project without a delivery date—or deadline in agile hipster language ;) —is just not possible. The lack of a delivery date is detrimental, and it reduces the necessary pressure we all need in order to function and aim toward our common objectives. 

This last year I had the pleasure of starting a couple of agile projects in Latin America beginning from their initial phases. In both cases, no one mandated our deadlines. 

Having no deadlines lowered our teams’ motivation and we started doing projects, not products. If our main motivation was to make life easier for millions of people, but we couldn’t even make our own lives easier because we didn’t have a roadmap to deliver value, something was bound to go wrong. 

Making business software necessarily involves dealing with many actors, silos, and complexities. It’s normal. Agile projects without deadlines to create well-aligned, joint pressure between the supplier and the customer in order to deliver can end up costing a lot, while producing little value. 

There’s a simple phrase to describe this: it’s expensive. 

Not having alignment and unity of vision often results in the superficial model I mentioned in the beginning. 

Do whatever it takes to discover every detail

So for all of the above, regardless of your approach to the problem, you need to develop a process of really discovering and understanding the scope of a project, or “size of the animal” as we often say at Modyo.

The scope of this process goes well beyond characterizing visual experience and user flows. It requires you to understand the qualities and limitations of key systems within the organization, to involve the commercial interests, to gain political capital through profitable sessions that increase interest and evangelize the actors involved. 

A good discovery process requires you to help people understand what should be done, and explains software code using general terms and language that business owners can understand. 

Your discovery process needs to enhance the best aspects of your chosen product before you start designing, because doing so will help you understand everything from legacy architectures to existing commercial biases. And you need to understand all of this, because the delivery date is always there.

Up to the very end of your discovery process, you need to keep determining whether or not you can implement what was asked of you at the start. 

I believe that at Modyo, we have managed to do something very interesting. As a product company, our ability to configure services and integrate our platform with existing systems requires us to have a rigorous discovery process of the highest caliber. We have met and exceeded customer business objectives precisely because of the lessons learned in breaching the gap between expectation and reality through this discovery process. The results are products that enhance the digital experience, and make life easier for millions of people.

As a closer, I would like to say that this topic is, of course, extensive and requires more conversation and consideration. A benefit of this article is that it starts our conversation together, and puts me in a position to be open and listen to your comments.