This is the first part of a three blog posts serie in which I will detail three tips to help managers and team leads understand why and how they should start practicing these tips as soon as possible.
A successful software project is a project that can really solve the proposed business problems, spending costs and time according to the plans. Although, I’ve seen real projects going through situations where these critical items were ridiculously out of line:
- The project budget is over but we are still in the middle of the execution;
- After fixing lots of bugs the project was finally delivered with two months delay;
- With this amount of change requests it is impossible to keep the schedule;
- Project was delivered within agreed time and cost, but now we have to adjust several items which were not according to the original requirements (or the requirements changed…)
On the other hand, architectural and cultural improvements were growing in tech community. DevOps is now accelerating and improving project deliveries! Unfortunately, DevOps projects are showing that:
DevOps practice leads to faster software delivery, but it doesn’t raise the chances of accurate delivery of applications that meets the business requirements.
So, what can be improved in order to increase the chances of producing software quicker and with fewer deviations from customer needs?
Each application exists to solve a real problem.
And our objective is help people having better lives by using technology!
Each application exists to solve a real problem. And every business demand has one (or more) specialists, which we will refer to as business (biz) experts. This team or person is the one who masters every detail of (or even execute) work processes and tasks to achieve a determined goal for the organization.
When requested a new application or feature, the teams needs to build a bridge to support the transport and translation of the knowledge from the business experts to the engineers who will code (Dev) and deliver (Ops) this software.
In traditional project delivery practices, one of the biggest flaws occurs right at this beginning: closed meetings arise between a few business analysts from the technology team and the business experts. Based on these meetings, analysts start producing documents which describe the functional and non-functional requirements, business processes, and rules. This phase can last months, and in worst cases, – true story – a whole year.
Next, the software architects and developers come into scene: they try to absorb and communicate all the condensed business knowledge and requirements by reading and discussing all of these documents. Based on this discussion, software design is born.
Software design will define in a higher level the application architecture, languages used, tools and frameworks, code integration and delivery cycle, the required services, integration strategy used between them and other related items.
When the design is ready, developers will start coding and choosing code design regularly. Finally, during the development phase, the Ops team will additionally start working on the required infrastructure to deliver resources needed to run this service.
Follow the process above if you want higher project time, scope or cost.
This is a good recipe for failure.
Now, let’s get back to the DevOps story: Some declare to have achieved a successful software delivery strategy which allows, let’s say, 1.400 deploys of a particular application during a day. DevOps is helping this team escape from becoming the roadblock of the organizational digital transformation plans. Still, the question remains:
“Do applications, which correctly addresses business needs, really require a new version release on a per minute basis?”
Go Beyond DevOps
First Tip: Include software architects and developers in upfront business meetings early in the definition phase
Business experts and the technology experts are used to communicate through terms and line of thoughts common for themselves and compatible with their work scope. The first suggestion is to shape a communication strategy to use a common language, a ubiquitous language, in which the terms and meanings are described in a clear manner to any person involved in this specific scope, or who will be utilizing the application itself.
During meetings, while using this ubiquitous language, the application will start to take form into the software designers heads. The output of this flow, the models which will guide development, are created.
When this design process is used, this common language should be under constant evolution as new information is discovered. This common language approach should be used everywhere: documents, diagrams, databases, and code. This is why it is called the Ubiquitous Language. The same term means the same exact thing in every related asset of an specific domain, be a document or a code. And everyone involved in this domain understands this term clearly.
By getting the proper personas together you will notice these behaviors and advantages:
- The entire team will save hours of meetings as they will be shorter and targeted
- The Ubiquitous Language will be modeled, understood, used and improved in a quick manner, and consequently will also improve the quality of work
- The model – representation of the presented problem – will be created not only to represent business needs but also to guide software design and implementation
- Quality of the information obtained will enable a more refined application and code design, to be used for each delivery, without requiring as many meetings as if the personas were not involved in discussions
- Incremental deliveries, very popular in agile methodologies, are not only conceivable but are also more precise
- Will inject knowledge and proficiency to the team in the execution of agile practices, like sprint planning sessions, in which the problems being addressed and the respective proposed solutions can be discussed in a deeper more meaningful way. This defines and delivers a better solution when compared to other practices
- The feedback now flows in both directions: from business to tech team and back from developers to the business team. This bi-directional manner of communication creates a way for issues to be identified and fixed in a more efficient manner and time to resolution is shortened.
- The point of view of the engineers may even provide ideas that contributes to the evolution of the business requirement without the need of executing a full delivery cicly to validate concepts.
When this is all put together, your chances of succeeding on these deliveries will increase. In order to discover more on how to implement this approach at all levels, the recommendation is that all the team gets familiarized with Domain Driven Design (DDD) concepts and practices.
Hope you enjoyed the first tip. Creating effective communication practices between both Dev(Ops) and Biz teams and expand this to project implementation, is a practice every leader or manager should start nurturing in order to obtain more accurate and better project deliveries. This is based on BizDevOps and Domain Driven Design concepts.
I the next post releases I bring two more tips which will definitely guide you and your team to deliver successful software projects.
Keep Kalm 
I fully agree with your point of view. My only consideration is the difficulty of finding architects who can speak the language of the users without being carried away by the technological language.
LikeLike