Challenges of migrating a company wiki to Confluence and why it is worth overcoming them (part 2)

Companies that want to convert from their current company wiki system to Confluence must overcome a few challenges: existing users are used to working with the platform, changing systems always involves trade-offs, and transferring existing content is complex and painful. In the previous article, we described these common challenges in detail. In this article, we will explain why the switch to Confluence is still a good idea and why the exhausting migration process is still worth the effort.

Challenges of migrating a company wiki to Confluence and why it is worth overcoming them (part 1)

If you take a closer look at the various company wiki systems available on the market and objectively evaluate them, you will likely come to the conclusion that Confluence by Atlassian is the best and most sophisticated solution out there. Often, such comparisons are made when a company already uses another wiki – a system that grew organically beyond a department, an open-source system introduced as a trial run, or consciously chose the Wikipedia system MediaWiki because it’s the most successful software of its kind.

The advantages of pair programming

In agile software projects, it goes without saying that the developers work together. Scrum is, after all, based on teamwork. In most cases, however, each programmer works alone in front of their screen. The concept of pair programming is different because it pairs up two programmers who then together work on the same task, taking turns who sits at the keyboard. Customers unfamiliar with the pair programming idea might think this is some sort of job creation program: Why should we pay for two developers to work on a task that one programmer could do alone? This would only make sense if it cut development time in half, but that is most certainly not the case. No, this is indeed not the case. But how does pair programming benefit customers then?

Reasons why you as customer should test your new software intensively and at an early stage

The core of agile software development according to Scrum is regularly releasing product increments to the customer. The software’s functions are gradually extended, but the customer receives a version of their software right after the first sprint. That’s why at the end of each sprint, a review meeting is held where the development team presents the new functions to the customer. In this article, we will explain why it makes sense for the customer to participate in the reviews and why they should test the software created for them intensively and at an early stage.

There’s life in paper yet: The InstaPrinta prints customized JIRA tickets for analog boards

The paper-less office was meant to banish all paper from the office. In agile teams, however, this does not apply and this is where InstaPrinta comes in. Admittedly, a tool like Atlassian’s JIRA is a great way to manage tasks. However, in day-to-day work, a digital Agile Board in JIRA does not have the same presence as a large magnet board right in the center a team office that is full of task notes. At a glance, every team member knows what needs to be done and who is working on what. Furthermore, the magnet board contains numerous additional sections like an improvement board, a skill matrix, an absence calendar and more. This makes the analog board the central “cockpit” for all information relevant to the teams.

Hackathon at //SEIBERT/MEDIA – Field report on developing the EasyEvents plugin for Confluence

The goal of a hackathon is to buckle down and create a product and/or complete a small project under time pressure (at //SEIBERT/MEDIA within 24 hours). The hackathon team alone plans and decides what kind of product or project to work on. We explained the reasons for regularly conducting hackathons in our agile organization in more detailed articles. On the one hand, we strive to create concrete and truly innovative solutions. On the other hand, we try to attain “soft” effects, such as promoting training, teamwork and personal responsibility and motivating our employees. Our latest hackathon took place in early July 2013. In the following chronological field report, we offer insight into the work of the team that designed and developed the EasyEvents Confluence plugin.

Diagrams in Confluence: Comparison between Creately and draw.io

There are several solutions to implement diagramming functions in Confluence. Creately is one of them – compared to the matured draw.io, Creately is at a disadvantage. We have compared Creately and draw.io regarding central requirements. Here is a comparison of both diagramming tools, let’s take at a look at the five most important aspects. Flash vs. native Browser technologies: Creately is based on Flash. This has been problematic, since Flash is well known for it’s security weaknesses and it’s vulnerability. Many enterprises (especially in Enterprise environments) do not allow Flash for standard computer installations and don’t allow users to install Flash at a later point. draw.io, on the other hand, is based on the market leading diagramming technology mxGraph – the only library that works in any browser without plugins and completely client based.

Easy Events for Confluence: Save time organizing events in the company wiki

Events, team events and office parties take place in every company. Meetings and discussions are part of daily life at the office. Creating and operationalizing Confluence documents to organize acceptances and rejections is repetitive and time-consuming work. The EasyEvents Confluence plugin developed by //SEIBERT/MEDIA does a lot of this work for you.

Budget planning in Scrum projects and possible reactions to cost explosions

Complex IT projects are always subject to uncertainty. You must often deal with unclear conditions and changing priorities, are dependent on third-party systems and/or service providers, are using new technology and must face new requirements. That’s why it’s difficult to make professional, reliable estimates on company expenditures regardless of which project management method you use. Risks, however, are significantly lower in Scrum projects, because you always remain in complete control of the budget.

Any Questions or Feedback? Contact us now!

Fill out my online form.
Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. OK Details