Contact Us
+91 820 810 7030
01 Jan 2019
The ART of Offshore Software Development – Business Intent Driven Development Model (BIDD)
Written by Preetam Tiwari
The gap between offshore software development delivery and business expectations
The biggest concern I have heard overseas clients raise on the outsourced or offshore software development model is that they don’t get what they really want. On top of this they have to spend a lot of unnecessary time, money, and efforts in first proving that there is a gap in what’s been asked for and what was delivered, and then fixing the issues to take the delivery closer to business expectations.
In my twenty years of career in delivering offshore software development, I have observed some common delivery challenge trends. The gap between client expectations and delivery is one of the prime challenges. Interestingly some teams do well and some don’t. Even a change in a team structure can impact the gap between expectations and delivery. Isn’t this puzzling? I collected some data around team experience, expertise levels, performance metrics, team and compositions. And then compared these attributes with gaps in delivery versus client expectations.
Software Development: The Art-form
My root cause analysis of this issue narrowed down the cause- ‘Software engineer’s inability to read the business intent hidden in the documented feature requirement’. Engineers are primarily trained in the science, technologies, and method of software building. They are also groomed on mathematics and logical aptitude to look at the technical challenges but one big aspect they miss in their training is ‘The ART of software development’. This seems to be the missing piece of the puzzle.
Software development cannot be treated like a legal compliance process wherein developers just ensure that every word mentioned in the requirement documentation has been addressed in the implemented functionality. Even with all the latest standards of requirements documentation right from using UML to User stories, it isn’t feasible to capture every element of requirement in a documented form. The ‘Intent’ to build the software solution is often ignored as it cannot be documented in as many words in the requirements document.
ART is more subjective in nature. It expresses knowledge in the form of subjective representation. It is concerned with aesthetics. It is seen as creative, intuitive, expressive, and emotional.
The very purpose of every solution is to address a Business need. It could be a business pain area, business optimization need, or business expansion plan. The development team is expected to read these ‘between the line requirements’ to address the business problem. They are expected to think intuitively to get into the end user’s shoes and look at the problem and build aesthetics, usability which will ensure an enhanced user experience. This is over and above the expected functionality which has been documented.
To some engineers, it comes naturally and hence we see this perfect marriage of expectations and delivery in few teams. It is a more person-dependent success. Can it be imbibed in the development executive framework?
The Model
I tried an experiment. I developed and followed a ‘Business intent driven development (BIDD)’ model. I just introduced a couple of more basic steps to the SDLC as below-
Business intent driven development (BIDD)
The framework ensures that the intent of requirements is discussed and agreed upon first, and then the team walks through the requirements document to understand how the business intent will be achieved using the feature recommended. Understanding the persona of the end-user is also a critical step. The persona is considered in the UX implementation plan of functionality. The intent and user persona are documented and are a critical part of acceptance test criteria. This BIDD process plug-in was successfully tried in both Waterfall and Agile approaches.
Here are some observations of the team performance which adopted the BIDD approach for offshore software development-
- The team did consistently well in meeting Business expectations throughout the 3 months cycle.
- It helped in building a One Team culture between the Business and Development team. The Development team could come up with valid Business suggestions.
- Achieving the Business goal got the highest priority against the implementation of the documented requirements. At times the development team recommended some interesting Out-of-the-box approaches to address the business issue.
‘Understanding the intent rather than going by the action’ was a simple change in the approach that we followed and the results were impressive. It is indeed a common-sense approach. Human psychology cannot be ignored even in the virtual world. After all ‘Software is built by humans for humans to use’