Working at Fourtress
Since 2014 I joined the team at Fourtress. We do not call our team players employees, but we are the ambassadors of Fourtress. Our ambassadors have different kind of skill sets, with that knowledge we create solutions for all sorts of high-tech innovations. Another important fact, or attraction factor as I like to see it, is that we grow our ambassadors on their communication skills through personal development. The combination of these topics is what convinced me to join this family, but that’s something for another topic / post.
Until then, our ambassadors were mainly employed for assignments at our customers. In that same year we collaborated on a project called ZOOF. One project became two, two became three and so on… resulting in an official Project Office within Fourtress. Since then our ambassadors either are working on an assignment externally at one of our customers or they are assigned to a project within our Project Office.
We are proud of seeing the projects and project office grow, but we were also facing new challenges since our ambassadors now are working at different locations. Meaning we had to deal with team changes!
Challenges
Due to this growth and frequent team changes, we ran into new challenges in missing some kind of standardisation processes for handling our projects. In other words, we needed to setup some sort of minimal standards and guidelines. So, we sat together, designed and created our ‘Way of Work’ to which all future projects should adhere. We teach(ed) our ambassadors on this ‘Way of Work’ so they integrate it in their daily activities.
This means each project now has the same base for its documentation, project- and test management, source control and continuous integration. With this way of working we are equipped for the future and better armed when team changes occur.
Release Management
One part of our documentation guidelines is release management. We made it a must to know which releases are delivered to our customers. Think about the risks if you don’t keep track:
- Loss of releases, because you can’t trace back what features are delivered
- Loss of code, because you can’t trace back what actual code is shipped
- Loss of time, because you need to search and gather everything together when a question or request from a customer comes in
To be honest we experience and see the importance of release management regularly within each project. Luckily, we always managed to serve our customers and no unfortunate event happened that we couldn’t resolve. However, imagine providing support to our customers if we didn’t prepare ourselves for these kinds of risks.
3 steps to simplify the release process
At this point you might be wondering: “That’s nice, but how do you take care of this release management?”. We researched several products and finally selected proven tools from Atlassian, which are also widely used by our customers.
- The first step starts with our project management tool JIRA. This is a web-based environment for project and issue tracking used by agile teams. Within your project, always bind your issues to a version. If you are starting from a new project we recommend using semantic versioning. You could also give your version a name like Mars, Pluto or whatever. The most important part is that you create a version and bind your issues to it!
- Second step is to create a release version via SourceTree. This is a Git client which simplifies the interaction with your Git repositories. When you start your release, update your version in code, test it and finally commit it. Finally finish your release and label it with the same version defined in JIRA. Check that a tag has been created and pushed to the remote Git server. Do not forget to update any library code or submodules associated with your release in other repositories. Let a peer member of your team review this.
- Third and last step is to update your release documentation in Confluence. This is a web-based document collaboration tool. Because all issues are bound to your version in JIRA, you can easily generate release notes via a Jira report page. Once the page is generated you have the ability to document extra information worth mentioning, like what versions of 3rd party libraries were used and where you have delivered or deployed your version.
Keeping your issue administration up-to-date saves you time and effort during the release process. This way our acquired knowledge can be easily transferred to a fellow ambassador.
Following these steps will generate more happiness within our ambassadors, but more importantly we can efficiently serve and satisfy our customers. This will leave more time for focus on doing the right things and exceeding customer expectations!
If you’d like to know more about our ‘Way of Work’ or how these 3 steps are actually done within these tools, feel free to contact. We are more than happy to give a demonstration and tell you all about it.