Do you ever have an impression that the concept of transparency in software development could be more… transparent? In every company, it can mean something entirely different and, just like any other industry practice, it has fluid boundaries. At Code & Pepper, we start our transparency policy by explaining what it stands for and what aspects of cooperation it involves. Here we go with project transparency explained for every step of the way.
Getting started
When you partner up with a software development company, you may feel a sort of FOMO creeping into your cooperation. “How do I know if things are going according to plan? Will they deliver what they promised in the beginning?” you may wonder. By staying transparent, we make sure you have all the necessary resources and tools to stay on the same page with the team and see the progress clearly. Here’s how we take care of transparency before the development stage.
Team availability
I have all the time in the world.
no FinTech business owner ever
We completely understand that’s the harsh reality of many projects. However, it doesn’t mean you’ll be lured into believing that the team will kickstart your project in a snap if the crystal ball at our office says otherwise. You’ll stay informed about the availability of particular team members at all times. You can learn about your new team any way you want – by reading their bios and CVs or meeting them in person at your office. It’s all up to you!
Technology stack and documentation
Maintaining transparency in software development, especially the technological aspect of your project, might seem more complex compared to the business and management side of things, but everything becomes easier with clearly defined contract conditions and documentation.
Every member of the partner’s team (even a non-technical one) is aware not only of the final product results, but also the way the product works under the hood. This is achieved thanks to a detailed list of programming languages and technologies used in your product. To ensure a steady flow in the case of project takeover by a new team, we also prepare development documentation.
In the process
We work in full transparency and treat the client as a partner who works on the same team, not as someone from the outside who interrupts our sacred rituals.
Clearly defined MVP and delivery plan
The perception of what an MVP is often varies from business to business, just like the concept of transparency. When you have an epic vision ahead of you and burst with ideas, deciding what essentially makes your product viable takes a lot of effort. At Code & Pepper, we’ll establish the elements of your MVP at the very beginning, taking different factors and requirements into consideration. Once everybody is aware of product priorities, we can move on to the next step – delivery plan.
The delivery plan divides the project into clear stages and specifies the parts of the MVP delivered in each stage. Such precise planning makes progress tracking easier and provides everyone with more control over future plans.
Risk backlog
We are proactive in the field of any product-related risks, such as UX inconsistency, scope creep, inappropriate value vs cost factor. When the project is launched, an assigned Project Manager is obliged to identify all possible risks that can occur during a particular period and take them into account during project planning. In each period, we compare the risk backlog to the current project status and re-evaluate. Together with the risk backlog, we often create action plans to avoid or minimise any anticipated risk.
Code repository revealed
Many business owners imagine a code repository as a book of chaos – no idea why this urban legend still exists! It’s our prerogative to create an orderly, fully legible and reliable code repository you can look into whenever you feel like it. In most cases, our team will use your code repository, but in some circumstances it’s possible to switch to ours; no matter which option you go for, you’ll have full access at all times. Thanks to continuous deployment/integration you don’t need to worry about browsing through outdated code. Also, you’re always welcome to join us for code review.
Shared timesheet and progress tracking tools
Transparency can be executed on different levels – not only information itself, but the way this information is stored and shared. Every person involved should be able to see the current state of the project in terms of activities and time consumed. For this reason, your project will be tracked on a dedicated JIRA board and updated according to the actual progress. You will also have unrestricted access to team timesheet, which is updated on a daily basis. This provides real-time access to the project workload and full visibility of developers’ capacity.
Frequent meetings and open communication
If you want to learn what your team is doing not only from task boards and timesheets – let’s talk! Any person on your end can take part in any team meeting, especially the ones within the Scrum flow (daily standup, demo, review, retrospective). Daily messaging takes place on Slack, where the whole team can communicate without any intermediaries and you can meet everyone working for you at Code & Pepper. Sometimes we use Slack for daily catch-ups instead of meetings, particularly in projects managed with Kanban.
Transparency in software development – is that it?
Can we make things more transparent? Let us know! Transparency stands among our key values and your feedback is vital. If you have any questions or would like to learn more about certain aspects of the development process at Code & Pepper, don’t hesitate to contact us at hello@codeandpepper.com.