A report on how our specialists at EPOS CAT GmbH uses the collaboration tools of the Australian software manufacturer Atlassian in the automotive industry and what experience it has gained in the course of the years.
Compared with 20 years ago, we are now seeing entirely different business models emerge, developed by quick start-ups which turn new ideas into marketable products with astonishing speed. Organizations benefiting most from this success are those that are versatile, flexible or agile enough to be capable of uncompromising customer orientation. A start-up is usually established by the decision makers from scratch, allowing them extensive creative freedom. But what about the many organizations whose decision-makers see the need for agility, but whose structures and culture have developed far from the market?
With a collaboration team of about ten people, EPOS CAT GmbH looks after both such customer groups, and over the last few years has implemented a wide variety of projects in which extensive experience has been gained.
For the most part, software developers do not need to be told about Atlassian tools and their benefits – they generally use them as a matter of course and without major difficulties. However, for business teams in the fields of design, IT service management (ITSM) or human resources the implementation requires more explanation and is more challenging. And even here there is a strong culture gap. While young employees often demand up-to-date work tools – and are thus often the drivers behind the introduction of Jira or Confluence – older employees are frequently afraid of, or have at least strong reservations about these modern tools. Functions we know and are familiar with from social media, which enable the mentioning of colleagues in a text or the sharing of articles without sending an e-mail, require explanation. Needless to say, project teams which are forced to use collaborative tools are doomed to fail. The lack of interest or acceptance, and in the worst case a boycott, all prevent progress. This applies more than ever to the introduction of new working procedures. We have thus found that the success of a project depends entirely on taking in the entire team, with all its different roles and diverse (cultural) prerequisites, and on arousing enthusiasm in individual cases for the implementation.
After all, the product owner’s requirements for an application differ from those of the colleague on the support desk, or the tester. The Atlassian suite has the right tool, specific extensions as well as plug-ins for all parties.
In our projects, Confluence has proven itself as an entry point. Depending on the requirements of the project, additional tools from the suite complement the enterprise wiki. Easy to use, it can replace Word and, thanks to its central location, complement or in some cases replace the classic e-mail. The collaboration team at EPOS uses this wiki for working together on documents, creating and maintaining a manual, setting up FAQs or drafting offers and exporting them in one click as a PDF; these are just a few examples of the diverse application possibilities. It may sound simple at first, but there are still hidden risks. Therefore, the EPOS team has created an overview with several rules for successful project implementation. For example, new accounts require new passwords or an authorization structure that ensures that only your own team members have access to specific areas. Once again it is important right from the start to reduce inhibitions and minimize hurdles. Why not ask new colleagues to introduce themselves to the team in the wiki instead of writing a portrait for the intranet? Or encourage new colleagues to organize their entire training on Confluence in order to become familiar with the tool and its features.
According to Atlassian, Jira is the most widely used project management add-on for Confluence users. While it is well-suited to agile processes in software development, Jira is more of an organizational tool to most business teams. The tool lends itself to restrictive processes that require traceability and transparency or that need to be evaluated; budget approvals or decision making processes are examples of possible applications.
It is also obvious that tools are only put to everyday use if they are simple to operate and their functions are mastered. Accordingly, training and coaching as well as the subsequent support of the user are important. The training courses are mostly short standardized introductions to convey the features by demonstrating best practices and use cases. In addition to these basic training courses, there is also individually tailored coaching on Scrum, Kanban and plug-ins for software development and test management.
That was the human side of things. Now let us turn to our experiences with the methodological and technical requirements and hurdles. Last year our collaboration team had the task of equipping a young company specialized in autonomous driving with the complete Atlassian suite. The team consists of approximately 200 people and wants to use the tools to develop software for autonomous driving from layers 1-5. From the beginning, the applications were organized uniformly, with no configurations nor customizing. Jira was set up with exactly three different project types with remarkably simple authorization structures, so that each team can look at everything, apart from areas with explicit data protection restrictions. It is kept quite simple and is thus very sustainable, as it can be maintained cyclically. The use of Atlassian applications has also proven itself in companies and corporations that have grown over the decades or which have a hierarchical organization, as the next project example shows. For almost ten years, EPOS has been operating a Jira in automotive R & D. It was introduced in version 3.14 and is currently maintained by our experts in version 7.3. By March 2018, it had around 600,000 tickets with 1.7 million comments and around 4,000 active users per month. This Jira is controlled centrally and, as a corporate service, is designed so that project-specific configurations can take place. The ratio of projects by business teams and software development is estimated at 80% to 20% and therefore there are numerous project workflows which map out request evaluation processes or approval processes for the commissioning of external service providers.
One of our team members has the sole task of training users and adjusting configurations. In order to be able to keep this technically sophisticated system up to date, an internal billing model has been established by our customer. The research and development departments therefore use their Jira in their corporation as a paid service. This makes it possible to finance lifecycle, support or documentation and to offer a technically and methodically clean system. Financing through an internal billing model has proven itself many times and is therefore often standard in the enterprise environment. For strategically placed business services, it is particularly important that products are up-to-date, which is why we are principally concerned with keeping customizing low. It pays off to take into account the follow-up costs for licenses right from the start of the project, and to stay as close to the product as possible and to keep up with product updates cyclically.
The dangers of customizing include translations into your own language. In our experience this often leads to confusion and can also lead to amusing or misleading errors. We therefore urgently advise to use the tools in the English original. The wording can be found in the introductions, making it easier to seek help from Support or further workshops. The use of specialist terminology ensures that all team members worldwide can communicate in a consistent and comprehensible way.
After ten years of Atlassian projects, our experience in short is quite simple: take the whole project team through training and continuous support, motivate them in the individual roles for using the new tools to assist them in their daily work, and keep the applications technically and methodically simple and lean. The EPOS team would be pleased to hear about other experiences and to answer your questions. We will be at the next Atlassian Summit in autumn in Barcelona. If Ingolstadt or Spain are not on your travel plan, local user groups are a good alternative. In German speaking countries, especially in Germany, there are Atlassian user groups in many cities online at https://aug.atlassian.com/. In Scandinavia there are also local groups and partners with great expertise in Oslo, Copenhagen or Stockholm.