A project always begins with the identification of a need, followed by negotiation. Too often, we overlook the fact that, to ensure the success of a project, collaboration between the technical team and the customer is crucial.
As stated in the third value of the Agile Manifesto, “collaboration with customers more than contractual negotiation”. At Done, we encourage listening and open-mindedness. First and foremost, we try to fully grasp our customers’ issues and needs.
From there, we develop the perfect project.
The project is accepted : the requirements are clear, but where to start to carry out our development?
A natural reflex is to prepare everything in advance to be able to program without meeting obstacles relative to the technological environments. So it’s at this moment that the team organizes a round table and makes decisions according to its knowledge and its level of comfort with the tools. A choice is made for each of the architectural components (database, server, etc.) and we even have a more experienced member proposing libraries that will allow us to develop quicker. Why use this or that tool? Because we might need it later in the project…
We seem to have a complete toolbox that will help us face anything coming our way! But will a mechanic need the same tools as a carpenter? Let’s push the analogy further by asking ourselves : does a carpenter building of a house needs the same tools as his colleague creating a high-end table with intricate patterns?
Unfortunately, in software development, it’s often only at a late stage of the project that the team realizes that the tools or libraries chosen in the beginning can cover many more features than needed. The price to pay? A heaviness (and even sometimes slowness) of the application that can sometimes require an important investment of time in order to remove what’s unnecessary.
learn from our mistakes, and (better!) choose the components of our application
The fourth value of the Agile Manifesto reminds us that “adapting to change is more important than following a plan”. So, to be “agile”, you mustn’t be reluctant to change, you must constantly adapt.
The “choose what you need” mentality is widespread and promoted during Agile transitions. We wait until we need to back up our data before choosing a database, as there may be an important detail to consider that will make us choose one option over another.
At Done, versatility is important within the team. That’s why any task can be carried out by any member of the team. It’s therefore possible that a less experienced colleague will have to make this technological choice. We rely on peer support and collaboration, and take it for granted that he or she will ask for help if necessary. We make sure that this person has taken the time to read the documentation, that he or she feels confident to do the job alone, and so on. And the result? At the end of the sprint, the new technology has been integrated into our application’s source code in a way that normally pleases everyone!
We keep in mind that technological choices are not always visible and obvious, so a poor choice may go unnoticed and lead to specific development practices in order to succeed in writing code that will be compatible. When faced with this kind of problem, we try to deal with it quickly, minimize the impact and ensure that our colleague learns from it.
Once again, the consequence is an investment of time that can sometimes go unnoticed for a long time. A developer will need to be critical enough to question the initial decision before realizing that hours of work have been spent trying to get around a problem that was simply taken for granted. The more advanced the project, the greater the number of hours spent. What will the Product Owner, who manages the budget, think?
decide as a team and optimize the environment
As stated in the Agile manifesto, “people and their interactions are more important than processes and tools”. This means encouraging interaction with team members, rather than using cumbersome decision-making tools. Everyone’s knowledge must be put to good use.
Here are a few tips to help you develop an optimal project environment:
- Draw on the knowledge of the whole team;
- Eliminate manual and repetitive tasks (wherever possible);
- Assume that not everyone has the same configuration;
- Document development, with an eye to future developers or the eventual production release of the application.
Let’s address each point one at the time…
Benefit from the knowledge of all the team members
If we are responsible for choosing a tool or a component, it’s primordial that we put our egos aside and openly talk about our path toward the final decision. Inversely, the rest of the team has to question the choices made to make sure a trap that will engulf precious hours of work throughout the project is not setting itself up. So everybody needs to take responsibility for this integration, even if everyone will not part of it.
This point is especially important not to fall into a dynamic of pointing the finger that can divide the team and have some people feel incompetent. We all work together to help each other out!
Furthermore, it’s possible that a colleague has extensive knowledge about the technology that we chose. Sharing information is then a crucial step that will not only allow global skill improvement for everyone to know what they are getting into for the duration of the project, but also knowledge of how to work optimally with this new piece of the puzzle that is our product in development.
Tips and tricks taken from past experiences can be exchanged in discussions, which is much more useful and quick than an extensive study of the documentation. It’s by talking together that we will then be able to avoid traps and who knows, maybe even work in pairing with the one that already knows the technology. The benefits are important: an optimal development process, an information exchange and clarifications on the most obscure points; without forgetting a better quality of the final product. It should be taken into account if people external to the project question the relevance of having two people working on the same task.
While one of us works on the integration, the other can take this opportunity to write a page documenting a few leads that will allow the rest of the team to know where to start building with this new technology.
Eliminate manual and repetitive tasks
Talking about traps, how many times does a programmer need to deploy a version of the application on the test environment to make sure that the bugs are fixed? Once the application is stabilized, the Product Owner will undoubtedly want to present it to the project’s stakeholders by staging a demonstration. The application will then need to be deployed in another environement. Oh! We forgot something and the configuration from the wrong environment is being used. The demo is not functioning and this hour scheduled in the agenda of possibly overloaded people has been lost, undermining the morale of the Product Owner and the rest of the team.
However, deployments are frequently made and the process should be mastered by everyone! It’s only one example of a disastrous situation that can arise during a development project, but that could have been avoided by addressing a simple but repetitive task from the beginning.
That is why these manual tasks that may seem mundane, but entail their share of risks, should not be taken lightly. It would be better to invest more time in the beginning to put automated processes in place. Of course, that implies more efforts initially, considering the development tasks added to what could have only been the configuration of the infrastructure. The direct benefits are easily measured when noticing the hours saved on manual tasks, but the door is also open to other advantages we do not always think about.
For example, a script that will run every night can simply call one of the automated processes, or a user interface can be created quickly (for internal use, so it’s not necessary to linger on aesthetics) to enable some people who are not involved in the development to deploy the software in the environement they are using. There are a lot of possibilities that do not require a lot of development efforts, but that can seem insurmountable if we did not build our little internal tools iteratively.
Take for granted that all might not have the same configuration
How many times will programmers hear the following sentence during their career?
“Yes but it does not work on my computer, and only on my computer…”
Every time a software component is integrated to the project, this reality absolutely needs to be part of the first hypothesis. If we decide to use a tool that’s hard to configure, we inevitably have to expect to face a development environment that does not have the same configuration (or version) as the others. It is then that investigating can occupy a developer, maybe even two, for several hours, or even days.
The best approach to avoid this type of problem is to properly define, from the beginning, the different environments that will need to be supported by the software. In the case of a Web-based application, the automated tests suite may be built to be executed on several browsers. The tests will not only allow us to avoid regression problems as we add new features, but the team will also be confident that problems won’t arise on browsers that are not being used as frequently during the development process.
In the context of client-server applications, the server part of the software should not be neglected. Since the completed application needs to be executed on the developers’ workstations, the different configurations can bring twice as many problems. Unless you reset the developers’ computers after every project, you only need to have developed a few apps to have the past come back and haunt you. A tool we forgot to update, or a special configuration that was necessary not so long ago can cause their share of problems. And the cause is not always easy to find…
The arrival of containers and tools like Docker can greatly help avoid this type of situation. Instead of having a complete image of the computer that forces the developer to lose his customization after each reset, it is now possible to build a file that defines a container image from several preconfigured software.
Usage of this file by the rest of the team enables us to guarantee that all are using the same environment, without interfering with everyone’s customization. Once the project is over, we will simply be able to delete it from our computer. And if we had modifications to make a few months later? It suffices to rebuild the image from this file and we will find the same environment that we had, without installing and uninstalling our development tools.
You only need to invest a little time to learn it, but your developer’s life becomes so much easier!
Document for the future
Documentation is often the bête noire of team tasks. Creating documentation that’s easy to use isn’t easy, and documentation that nobody consults is useless.
The Agile Manifesto reminds us that “operational software is more than exhaustive documentation”.
So, to create the necessary documentation, you first need to build software that’s easy to use, and from there, think about the future, and have created the right documentation.
When a new member joins the team, what steps (not already automated) will he or she have to go through to be ready to develop? Each of these should be documented in a centralized location, so that you don’t have to assist with installation and run into the same problems over and over again.
The same strategy applies when our software goes into production and is accessible to all users. If it’s not us, the programmers, who are involved in this crucial stage, we need to make sure that the person in charge is sufficiently comfortable with the tasks involved.
By documenting development here and there, throughout the project, we can avoid having to put ourselves in the shoes of an outsider to write for long hours and run the risk of forgetting important points.
When a new member joins the team, what are the steps (not already automated) that he will need to pass to be ready to code? Each of these should be documented in a centralized spot to avoid having to assist his installation and always having the same problems.
At Done, not only do we try to improve the documentation a little at each sprint, and make it a final review at the end of the project, but we often encourage the intervention of a UI/UX specialist to reduce the need for documentation. This saves us from being woken up at three in the morning because the system administrator doesn’t know what to do in his deployment process…
The recipe is simple…
The secret for a perfect development environment? You only need not to make it too complicated! Don’t hesitate to involve the rest of the team in the implementation and also to actively be part of it when others are in charge. Anyways, you will be able to benefit from an important learning and will make sure that the next weeks (or months) will be without hitches.
Need help?
If you have any questions, please do not hesitate to contact us. The expertise of our multidisciplinary teams allows us to support companies that wish to develop the skills of their development teams.
To learn more about training and technical coaching, click here.
Good project!
