The importance of transparency in the software development process extends beyond creating a product. It’s the quality of business relationships that really matters. The market-ready product, being the final stage of a business relation, is only a result. The reason behind its successful delivery by the vendor and the acceptance by the client is an honest partnership. How to make sure that transparency in software development really works?
Benefits of transparency in the development process
Before we answer that question (the answer is multi-threaded), let’s talk about the benefits coming from being honest. As FinTech software developers, we understand what our customers face. The market pressures they’re under. Customers’ expectations they want to meet. Compliance issues that have to be fulfilled. It’s a lot. The last thing the client wants is a challenge during the software development process. The smoother the process can be, the better for everyone. A challenge is good, though. By making you a part of the software development process, a vendor assures exactly that – smooth sailing.
One of the most important benefits of transparency is information flow. The more you know about the stage of development, the more you see daily, the fewer questions you have as a client. The project can kick off sooner, the cooperation between you and the development team is natural and friendly. Even more so, it’s practical.
No surprises. The client always knows how much he’s paying, for what, when the project is going to be delivered, who is working on it. No secrets, no hidden fees, no headaches.
Access to a bigger picture. Sometimes clients bring up a project, but after talking to developers, they want to change the scope. Speaking about the product in an environment that promotes openness and sincerity, gives the project a higher chance of interdisciplinary cover. Companies that give employees an opportunity for real impact are proactive. They come forward with ideas and propositions, instead of executing the client’s wishes to the letter.
Risks mitigation. Partially thanks to Agile and it’s predictable delivery pace but in reality, thanks to the collective mindset. When people talk to each other, potential communication bottlenecks and project landmines can be resolved or even entirely avoided.
Making a client a part of the team. By invoking transparency policy, the vendor invites the client to become part of the team. It breaks the ice, shortens the distance, gives the client an opportunity to participate in development. As an observer, but also actively; as a reviewer and mentor. Having domain authority, he’s always a step ahead of the team and can guide developers. Change the scope, widen horizons.
Promotion of accountability. On the current subject and topics mentioned now and below, we will touch later on in the article. For now, let’s just say that if a product owner, developer, quality assurance engineer are fully responsible for your product.
OK, but how exactly can a software company achieve these goals while delivering a functional product for the client? The key lies in understanding that delivery is possible because not despite all these points. The paragraphs above could be great talking points on some keynote presentation about business relations but as it happens, they have a practical translation on everything. From scope estimation, through design, to development, and ending with post-launch support.
How to make sure that transparency really works during the software development process
Reasons showing that transparency is important in software development come from two major sources: Agile mindset and internal, unique approach that some companies worked out over the years on a market. Let’s walk through all of them.
The client centricity
It’s a good practice to give the client constant access to everything; day by day. When you have access to the team, know peoples’ names, and can contact them at any time, trust is built. The same goes for JIRA, Confluence, and Tempo time logging. All these tools let you control basic properties of a project. Who worked on what and when? How big advancements has the company made throughout the sprint? Do they burn my money or do what they say they will do? Think of it as an invitation to the backstage. You can see the magic trick comfortably sitting down but it’s the talk behind the curtain that shines the light on what’s happening.
In a market-aware company, transparency begins with sales. Even earlier, through pieces like this one. But let’s focus on the selling process, because it’s the first time when you can speak to people. It’s a good practice to invite the delivery team (product owners, business analysts) to the meeting. This is your chance to meet the people who will take care of the product. At Code & Pepper, we go even further. Sometimes we even bring our principal software engineer to give you an inside on how to tackle the project from the technical standpoint.
When we agree on details, the talks about pricing begins. You should always know what the pricing covers and why. What will happen in every sprint, how much a specific functionality will cost. How much time we need to develop a minimum viable product (MVP), the finished application. Every single functionality.
The cost of the product always depends on its scope and the cost of the project. It’s the question of iterations. That, combined with potentially niche technologies, impacts the price. The price is shown in a form of several sprints and costs per sprint. You always have the information on the structure of every sprint. How many developers are on the project, what are their seniority levels, what amount of time per person is currently logged, etc. Every project has at least one senior to assure oversight and overall quality.
The scope of the project and the product roadmap help us manage development and help you understand where we are in the pipeline of tasks. To make that possible, we believe in constant communication. Or at least the possibility of it. Like every seasoned company, we provide access to product backlog items (PBIs), where you can comment and be a part of planning. We also have a special channel on Slack, where you can talk with the development team. Ask something before, after, or in the middle of the ongoing sprint. Comment on anything you found questionable.
There are also situations, where a client is a part of a bigger organization. He wants the project to be compatible and/or consistent with other projects already present within the company. We have to implement functionalities and design the overall look of the application to reflect that. A client may also want to integrate our reporting into his reporting, for his organization. At Code & Pepper, we do just that.
The risk management
For a software development company, the decision to enter a project is based on few aspects; one of them is risk assessment. From the client’s perspective, the risk analysis is about certainty and trust towards the software provider. It lets you judge the confidence level of how we estimate the time and project’s cost. It also shows you weak points in your project, so you can solve them for yourself and us; paving the way for smooth development.
If you want to make your first MVP in life, you probably want it fast and as cheap as possible. Also, with the humanly possible, lowest risk level. The thing is, proper assessment is everything. Application’s features can’t overshadow business realities. Every company that creates code expects you to know that. At Code & Pepper, we are always honest about possible risks in the project and educate the client about all the aspects linked to that topic.
One of these aspects is that vendors accept risky projects, but under some conditions. We can’t take a project if it has an unrealistic scope, expectations, and budget. Or when functional requirements are poorly communicated to the team. Being grounded and able to look at your project realistically is what makes the difference, especially at the early stage. Narrowing the focus is crucial. We can accept risks when they are known and accepted. And when the client understands them and supports our ways of neutralizing them. A true deal breaker here is your potential unwillingness to accept the risk on your part.
The second aspect – legal requirements. As the company specialized in FinTech we know how important the legal landscape is. Before bringing the project, you should always know if it’s even doable, given the infrastructure and economic reality of a certain country. What goes in Ghana doesn’t have to be completely accurate in Germany. What is regulated in the United Kingdom in a specific way can have completely different circumstances in Spain.
The third aspect of risk – your financial capability. Every project has its budget and limitations that have to be treated accordingly. If you want to change the scope of the project, the change itself will create its own set of possible risks and management challenges. It will also cost. Every software development company is open to changes, but when the project starts, everything must be in place. You should always be aware of the price – at the beginning and when the project is in full swing.
Another risk is unknown and changing market adoption: your FinTech sector and the market itself change rapidly, therefore in the next six months a portion of the project can look entirely different. By making any kind of product, we are taking the risk of not being 100% up to date at launch. Are you prepared for that, mentally and financially? Are you ready to change the scope basing on what’s happening on the market? Do you feel comfortable with the pivot? There’s a chance that you will want to change the scope. Not because we say so and recommend the change, but because the market will push for it.
Every vendor operates with the notion that the client knows the product best. What separates us is the ability to advise. Clearly and with a high level of transparency. At Code & Pepper, we always present potential risks to the client. It’s a good practice to communicate every potential bad news. Like sick leave in the team, for example. It’s the product owner’s job to keep tabs on everything and react when symptoms of anything bad happens. In the project and on the market.
Does transparency in software development really work?
Yes. If you have the right processes in place, that is. Transparency is not a made-up word used to boost a sales pitch before the client. If it’s not backed by rules and processes that are hard to get around, it’s meaningless.
In the world of product management, transparency is best described as following a set of rules. If a client wants to change the scope of the project, it’s possible but we need to follow our previously agreed processes to implement these changes. Creating a number of rules for every situation we can predict helps.
Transparency originates at the lowest level. By giving you access to all of our processes, we build predictability, and as a consequence, trust. Now: clients signal the need to create a change in the project’s scope. We assess the change in relation to the rest of the scope. What will be the consequence in the budget, time, non-functional requirements, possible interconnecting dependencies, etc. Then, we approach you and say: OK now you know how it looks, so please accept the implementation of the change or not. If the change is accepted, we add it to the budget. It’s about the triangle of product management: cost, time, and scope. If one changes, all have to change. They all depend on each other. We have to control and predict pivots.
The best way to do that is to make the process of development predictable. The ultimate key for that is transparency – we make all these rules and processes visible to you. If the client wants to make a change in the project, we as a vendor can always say: OK but it will cost a specific amount of money. What we say instead: OK but these are the consequences, higher amounts of work and risks. Plus, here is the change registry, when you can also browse at any given time. We log your change here and here. You always have access to it. You can always access the baseline budget and the current budget, even after implementing new functionalities. Each change has associated data – cost, time, etc. The benefits of being transparent come not from blindly accepting everything. They come from treating you as a member of the team.
Models of cooperation
A client will get different perks; all depending on the model of cooperation. At Code & Pepper, in end-to-end development, we make an estimation for the project, the price, etc. But we don’t just send an offer, we meet to discuss it and make sure that every question from the client is answered. We walk you through the estimated project. Showing what processes will be used throughout the development and what will happen at every stage of it. The value here comes from knowing what will be used, when and for what purpose. You will always know what the next step will be. It’s not about holding your hand, as much as helping and preparing for what’s to come, so that both sides can work seamlessly and without communication bottlenecks.
In the end-to-end model, you want a team who can build you a product. In team augmentation, you focus on people who are best suited for the team you already have. Clients have the ability to verify developers – talk to them, see how they feel about them, even on the personal level. It’s about language proficiency and cultural fit. Transparency here is about access to these specialists and the ability to verify them. The process is unlike Forest Gump when you had a box of chocolates and you didn’t know what you’re getting. You have to know what you’re paying for. This model benefits developers as well. They have information about you as the client, your company, its sector, and the product.
Transparency by design
The ability to verify developers shows how transparency in software development really works. It’s transparency on an organizational level. You may want to have a software development company that is transparent in contacts with the client. Even though some people, some developers, on a professional and even personal level, may not be entirely transparent in stressful situations. Human beings are faulty by design – we avoid situations that are stressful for us. This encourages behavior that is not transparent at all. To create a truly transparent organization, you can’t just declare: yes, we are transparent.
You have to create a mechanism of checks and balances. A set of processes that mitigates human nature to some degree and smooth over behavior that is not transparent. Even if the code is already delivered to the client and someone – a developer, product owner or QA engineer wanted to hide something, there’s no way it’s possible. All because of the precautions and implemented processes. This is transparency by design – we mitigate human nature by our own nature and design.
In fact, the “transparency by design” policy helps all. People don’t have to ask themselves: should I talk about it, mention it. People don’t hesitate how to react in certain situations. Developers simply act with the best intentions at heart, because they feel responsible for the product and there’s nowhere to hide anyways. It’s not about breaking people. It’s about creating a model in which people feel comfortable. They know they can make mistakes and fix them in a secure and respectful environment.
When it comes to Time & Material projects, clients have access to Tempo (which is a plugin for JIRA), JIRA, and Confluence. They see how much time developers spend on the project at any given time. This is how we like it at Code & Pepper – full disclosure. If someone will tell you that their organization is transparent, ask them about examples. At Code & Pepper, we can show you quite a few things. From initial contact, through contract signing, development, to post-launch support. As an element of transparency, we also plan sprints with you. We talk about what will happen in the sprint, what functionalities will be implemented, etc.
Transparency is a consequence, not a theme
It’s a very nice thought but what does it exactly mean for you as the client?
Well, Agile is a state of mind. It doesn’t require manuals with hundreds of pages. It has Agile Manifesto and Scrum Guide – short documents acting as a base. It’s a guideline, the rest is interpretation. At Code & Pepper, we have combined agile methods of working on a product with project management. Many companies similar in size and specialty have ways of implementing Scrum and working on a product.
In Agile, transparency is not a theme but rather a consequence. In Agile Manifesto, the value comes from customer feedback. Agile emphasizes a product not being a black box. It’s not like putting requirements in the oven and pulling out fully baked products. It’s about regular feedback while making an application and iterations based on requirements.
In Agile, in opposition to Waterfall, communication with the client is more frequent and goes both ways. In Agile, the project does not inform the client about the progress, but the whole development team exchanges ideas and opinions about the project’s progress. Product’s demo and constant delivery of increments strengthen transparency.
In Agile, we have to deliver something that works. With every single sprint. It can be a small element of the whole project but it can’t be soil in the garden that is disturbed. It has to be a constantly watered soil, that in each sprint is prepared for something bigger. By each sprint, the plant is growing.
Prepare, water, grow, expand
This is how we treat development. At Code & Pepper, we like to think of a project as a garden. The importance of transparency in the software development process may be about processes, pricing, development itself. But mostly it’s about what you as our client will get in the end. A working product that can win over real-world users.
We are not afraid to talk about what works and what doesn’t work. There are some reasons behind failure in FinTech. To create a garden full of beautiful flowers and plants, we have to cooperate. You are the gardener with a vision but we know a thing or two about cultivation. Let’s join forces.
