scaleup - insight partners

25
SCALEUP technology HANDBOOK | 2020 </>

Upload: others

Post on 29-Oct-2021

9 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: SCALEUP - Insight Partners

SCALEUPtechnology HANDBOOK | 2020

</ >

Page 2: SCALEUP - Insight Partners

For software ScaleUps, being able to rapidly build out products and features

is critical. Yet, when you try building without the systems, processes and

supporting technologies in place, it is far too easy for your engineers to get out of step, build with faults in the code, and set your product up for problems down the

line. Enter Atlassian.

Products like JIRA address bug tracking and Confluence allows for

simple collaboration between business and technical resources. This intro

to Atlassian is designed to help your ScaleUp reap the benefits from this

inexpensive, yet powerful and flexible solution. With Insight you can access

the best ScaleUp resources from the experts doing it now.

Page 3: SCALEUP - Insight Partners

Insight Partners

Atlassian Benefits Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Benefits of Confluence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Benefits of JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

What should you get from the tools? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Maturity Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Process (Tool Independent) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Atlassian Specific . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Confluence Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Common User Mistakes & Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Space Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Account Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Wiki Page Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Support Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

System and Application Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Non-production Confluence Environment (Server version only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Reporting Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Status Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Meeting Minutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Combination Reporting Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Reporting Add-ons/Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

JIRA Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Common User Mistakes & Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Project Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Global Content Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Project Content Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Reporting Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Agile Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Project-specific Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Common Administration Mistakes & Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Common Administration Mistakes & Best Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Attachment Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

User and Group Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Empowering Space and Project Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Email Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Confluence Specific . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Comments, Comments, Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

JIRA Specific . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Notification Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Permission Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Maturity Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Adding Atlassian Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Integrating Atlassian-to-Atlassian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Integrating Atlassian-to-3rd Party . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Other Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Atlassian Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Atlassian DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Help Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Page 4: SCALEUP - Insight Partners

4Insight Partners

ATLASSIAN BENEFITS SUMMARY

Benefits of Confluence

Confluence is a wiki-based system that increases collaboration among all project related resources. It is a powerful and flexible product on its own but adds additional value when it is combined with JIRA. The following are some benefits when Confluence and JIRA are integrated:

Centralization: All projects have their fair share of work associated with them – product require-ments, project plans, models, design specifications, etc. JIRA is great for helping teams plan and track the work but Confluence provides a central location to organize all of this additional content. Confluence provides a space that can be directly linked to its associated JIRA project and links can be created for a deeper integration.

Communication Barriers: Eliminate lost conversations, action items and critical decisions during the lifecycle of your projects. Confluence ensures all project resources stay on the same page and allows them to provide feedback directly on the wiki pages. You can also use the native templates that Confluence provides as opposed to creating your own. This ensures all project resources are working from the same set of templates so integration with other tools operate the same way from project-to-project.

Templates: As stated in the previous bullet, Confluence comes with a quality set of templates that can be used across the organization. Templates for meeting minutes, action items, requirements, etc. are valuable so project resources spend more time on the actual project and less time creating extra items for the project.

Visibility: Like JIRA, Confluence provides a level of transparency that ensures stakeholders and project resource have a way to stay current with project activities. You can create an appropriate hierarchy of pages within your space and implement restrictions as needed for more sensitive information.

Add-ons/Plugins: Like all Atlassian products, Confluence has a wealth of add-ons and plugins that allows you to completely customize the user experience

Benefits of JIRA

If your organization is thinking about using JIRA, then you may be wondering what some of the main benefits of using JIRA may be. Below are six common benefits to help you decide if JIRA is the right tool for your software team.

Visibility: One of the major issues that slows down a project is a lack of visibility as to what work needs to be done to address bugs and customer enhancement and improvement requests. JIRA solves this issue by connecting teams so that all resources can update each other in real time as work is opened, worked, and completed.

Prioritization: To ensure your products deliver maximum value to your customers and deadlines are consistently met, JIRA allows you to prioritize work that is in the backlog. In the absence of a tool like JIRA, projects can drift off track and work on items that are not important to the success of the actual product in the customer’s eyes.

Page 5: SCALEUP - Insight Partners

5Insight Partners

Productivity: Having a dashboard of prioritized work ensures resources know exactly what is being worked on and what should be worked on next. This eliminates resource downtime because they don’t have to figure out what to do next and wait for approvals, thus increasing productivity.

Stay Connected: JIRA offers a mobile application so resources can stay connected while they’re away from the office. Pulling up a customer’s tickets and providing real time statuses can make a huge difference with existing and potential customers.

Add-ons: While Atlassian has its own roadmap for its products, there are pieces of functionality that are important between all of its customers. JIRA has over 1,000 plugins and add-ons to address gaps in the native product. From advanced reporting to advanced time tracking, the Atlassian Mar-ketplace is filled with quality products that further enhances JIRA for your unique needs.

What should you get from the tools?

While both Confluence and JIRA are highly flexible tools and have a wealth of add-ons and plugins that can further enhance the Atlassian experience, an organization should expect to get the following information from the two tools.

• Enhanced visibility

• Increased traceability

• Better predictability and decision making

• Quality metrics and reporting

Specific to the tools, you should expect the following items to ensure your success.

• Confluence

• An appropriate hierarchy of wiki pages

• A top-level summary wiki page

• Integration with JIRA

• JIRA

• A project structure that supports your business

• Agile or Kanban boards

• Project specific

• Cross-project for management/stakeholders

• Dashboards

• User level

• Project level

• Cross-project level

• Management level

• Reports

• Project-level reporting found in each JIRA project

• Agile reporting such as burn down, capacity and ticket lifecycles

Page 6: SCALEUP - Insight Partners

6Insight Partners

MATURITY IDENTIFICATIONBefore engaging with a client on their Atlassian initiative, it is always best to perform an assessment to deter-mine the level of maturity within the organization. This assessment will assist you with drafting a roadmap to accomplish the desired end-state for the business.

The first part of the assessment should be to determine the maturity of the processes and procedures. You will encounter organizations that may be using a different set of tools and desire to migrate to the Atlassian stack or are simply startup or small businesses that have been working in an ad-hoc mode and need to mature or become more compliant with industry standards. This is called a Tool Independent Assessment. The following items should be reviewed under this assessment:

Application Lifecycle Management

• Requirements

• Development

• Testing

• Deployment

• Maintenance

This is a typical application lifecycle, but you can make adjustments as needed to ensure you are assessing the appropriate disciplines. Depending on the organizational needs, you may also assess other areas such as, but not limited to:

Business Process Management

• Sales/Marketing Lifecycle

• Onboarding/Offboarding

• Procurement

ITIL

• Change Management

• Incident Management

• Problem Management

• Service Requests

You will review at least one of the above discipline areas but you may need to review them all depending on the engagement. Once you have determined the discipline(s) you are reviewing, you need to determine the level of process implementation within the organization and the Atlassian Stack. The following is a checklist that can be used to assess the level of maturity:

Process (Tool Independent)

Process Implementation Maturity

• Level of process implementation?

• No process

• Some process/not end-to-end

Page 7: SCALEUP - Insight Partners

7Insight Partners

• Some process/end-to-end

• Project level implementation

• Department/Business Unit level

• Enterprise wide

Process Maturity

• What level of maturity has been reached?

• No process

• Some process

• Stable process

• Metric/Report producing process

• Process improvement

Process/Tool Maturity

• What level of process-to-tool implementation has been reached?

• No processes implemented in the tools

• Some processes implemented in some tools

• All processes have been implemented in all tools

Atlassian Specific

Atlassian Maturity

• What level of Atlassian Maturity has been reached?

• Single tool implemented

• Common tool combination implementation

• JIRA/Confluence

• Bitbucket/Bamboo

• JIRA/JIRA Service Desk

• Multiple tools implemented (3 or more)

• Atlassian stack

• What level of Standardization is implemented?

• No standards

• Some standards (department or organization level)

• Enterprise wide

• Are plugins being used?

• If yes, is there a plugin strategy?

Page 8: SCALEUP - Insight Partners

8Insight Partners

• Is there a backup/restore strategy?

• Is there an upgrade strategy?

• Is there a User/Group management strategy?

Automation Maturity

• What level of automation is in place?

• No automation

• Some automation/individual tools

• Some automation/multiple tools

• End-to-end automation/all tools

Metric Reporting Maturity

• What level of reporting is produced?

• No reports

• Some reports

• User level

• Project level

• Multiple projects level

• Cross project level

• Manage to level

• Portfolio reports

• If reporting on metrics exists, which reports are produced?

• Burn down

• Capacity

• Created vs. Resolved

• Average Age

It is recommended that a scorecard of some sort be created and used for this phase. Most organizational stake-holders are visual and grasp maturity concepts better when they can review a scorecard. Furthermore, standard scorecard will also ensure that all Insight Venture Partner resources are working from the same foundation and can collaborate amongst themselves when needed.

The point is to determine what areas the organization wants to engage you on and then review the existing process maturity levels. Not only will this provide you with an understanding of the current business practices and pain points, but it will also be your guide to creating a solid proposal for migrating the client to the Atlassian stack or enhancing their existing Atlassian environment. In the case of migrating the client to the Atlassian Stack, presenting key information to the client as far as what will transfer “as is”, what will transfer but will look and function differently, and what will not transfer. This exercise ensures that the appropriate expectation levels are set and gets the organization off to the best start possible as they start or transition to the Atlassian stack.

Page 9: SCALEUP - Insight Partners

9Insight Partners

CONFLUENCE GETTING STARTED

Common User Mistakes & Best Practices

This section will list out the most common mistakes that are made when organizations implement Confluence in their environment for the first time. Each section will contain best practice information to help organizations avoid these common pitfalls.

Space Restrictions

Problem: Organizations are too quick to start implementing restrictions and locking the tool down---stating security concerns.

Best Practice: Always start with a basic security strategy such as creating groups and controlling permissions at the default levels. Confluence is designed for collaboration and that experience can be negatively impacted if you start with heavy restrictions. Even in organizations where tough security implementation is a must, the user community must be allowed to experience the tool without minimal obstacles otherwise they will not use the tool.

Account Sharing

Problem: Many organizations like to create accounts that can be shared. A common shared account is a guest account. Organizations will also try to justify account sharing. For example, the organization has an external client that needs to have access to the system but don’t want to create an account for all of the client’s users that need access.

Best Practice: Regardless of the organization’s logic, account sharing is bad practice. The standards for orga-nizational security should always be applied—even at the tool level. Atlassian, like other tools, follows industry standard security practices to ensure the safety of its users and as with anything related to security, not fol-lowing the standards opens the door to vulnerabilities. In Confluence, it is recommended to always create the necessary accounts. However, if this is a hard requirement, you can create a separate space and implement the “Anonymous” permission on that space so that the external clients may freely access the desired content. If Confluence does not natively meet the organizations requirements it is best to review other solutions that are available to address the requirements. You never want to attempt to make a tool meet a requirement it is not equipped to handle because this opens the door to vulnerabilities.

Wiki Page Standards

Problem: Organizations new to Confluence often struggle with their wiki page designs. Some pages have endless content that forces users to scroll too much. Other times, there are too many pages and each page has very little content and that forces users to click around the space too much and they can become frustrated and unwilling to use the product.

Best Practice: Confluence is a very flexible collaboration tool and can be very powerful if used correctly. It is recommended to keep the information on each page logically grouped. In smaller environments, you may have a wiki page that discusses everything about a printer that the organization uses. However if you have ten printers, you don’t want to put the information about the ten printers onto a single wiki page. In this case, it would be best to have a parent page that contains information regarding the overall printer strategy and this page contains links to each individual printer sub-page. This creates a nice parent-child structure and ensures the desired

Page 10: SCALEUP - Insight Partners

10Insight Partners

information is easy to locate. Another example of proper usage is a document. You don’t cram everything into a single header section. You break the information up into logical parts. The reader can then look at the table of contents and jump to the desired section. In summary, keep your wiki pages short and on topic. If you have multiple topics, create a parent or summary page and then logically group the detailed content as sub-pages. Finally, if you have visual diagrams, models, or even a very large Word document, don’t reinvent the wheel by trying to recreate it in Confluence. Simply upload the visuals, models, or documents to the appropriate page within the structure.

Support Team

Problem: The most common mistake made by an organization is attempting to leverage an existing resource to support Confluence. Typically, the resource has other responsibilities and can become a bottleneck for Conflu-ence requests or he/she may be pulled away from their core responsibilities to perform upgrades, troubleshoot-ing, or resolve outages.

Best Practice: Organizations taking on the Atlassian tools should be willing to invest in new, dedicated resources to support the tool. In small Confluence instances, 1-2 resource will suffice. In mid-sized instances, 2-3 resourc-es will be needed. And in large enterprise-wide instances, 3-5 resources will be needed. The number of sup-port resources required would vary based on the skillset of the support resources, the maturity of Confluence standardization, and growth projections. Another factor to consider is user support versus environment support. Supporting users would mean user management, space creations, and assisting with user education. An envi-ronment support resource would be dedicated to resolve issues like disk space, memory allocation, upgrades, and so on. It is always best to have support resources dedicated to both discipline areas unless you can find resources that have both skill sets.

System and Application Auditing

Problem: As Confluence becomes a part of the daily organizational routine basic things like licenses; disk space and memory can be easily forgotten. It’s only when the user community starts complaining that these things are reviewed and by then it is usually too late as the system is typically on the verge of crashing and becoming unavailable to the user community.

Best Practice: The support team should create a checklist of items to review on a periodic basis to ensure opti-mal system operation and availability. The most common audits to perform are:

Licenses are the easiest to monitor since Confluence provides a panel that shows the number of licenses being used versus the number of licenses purchased. A good rule of thumb is when the licenses used gets to within fifteen of the license limit (ex. 85/100 licenses are being used). This gives the team enough time to take the appropriate actions. Whether that is as simple as purchas-ing additional licenses or performing a user cleanup to ensure accounts that are no longer active are not consuming a license unnecessarily.

Instance limitations, in many cases, can be resolved easily. If you’re using a cloud environment such as AWS, you can simply update the instance accordingly and restart Confluence. Server-based instances can be tougher as a new server may need to be purchased or someone may have to physically add additional storage or memory. In any case, it is better to regularly audit the instance before it crashes on the users.

Page 11: SCALEUP - Insight Partners

11Insight Partners

Non-production Confluence Environment (Server version only)

Problem: Organizations want something quickly and so they stand up a Confluence environment as fast as pos-sible. However, what happens when you need to test add-ons, plugins, or new versions of Confluence? It is not wise to update a production-based system on the fly, as there are always unforeseen problems that occur that either forces the organization to start from scratch or possibly endure a lengthy restoration process.

Best Practice: If you are self-hosting Confluence (even in a cloud based environment like AWS), it is always best to have a replica environment for testing complex user requirements, integrations (especially to third-party soft-ware), add-ons and plugins, as well as new versions of Confluence. A good use case for having such an environ-ment is upgrading Confluence to a new version. You can have the replica environment available for the upgrade and determine which plugins break as a result. Since the replica should be identical to the production-based Confluence, the testing of the upgrade will also allow you to identify other risks and resolutions so the produc-tion upgrade will go as smoothly as possible.

Reporting Strategies

While Confluence itself is not a reporting tool, the wiki pages can be setup to provide a variety of beneficial reports. Proper reporting equates to more effective meetings. Important topics or concerns can be discussed while other lower priority items can be skipped as the reporting page provides all the details necessary to stay informed.

Status Reports

Status reports are a good way to provide quick updates to stakeholders, management and team members with-out halting work to answer status questions. For small teams you can setup a summary page that contains key information for others to review. If you have multiple teams then each team can have it’s own summary page and then a master page can be designed to pull from the team summary pages.

Best Practice: It is always best to keep the status report pages focused and precise with the information that is desired. You don’t want stakeholders or clients scrolling endlessly looking for the data. Breaking the desired information into logical units will aid with getting the right information together on a single page.

Meeting Minutes

Confluence comes with a page template for addressing meeting minutes. This is an effective way to capture tasks, discussions and decisions that result from such meetings. When the next meeting occurs, the previous meeting minutes page can be used to ensure items that require multiple discussions or follow-ups are not forgotten.

Best Practice: Always try to use the meeting minutes template provided natively as opposed to developing your own. The native template has built-in features that won’t be available in your template and there’s really no reason to reinvent the wheel on this one.

Macros

Confluence has several macros that are useful when reporting on certain information. A good use for a macro is when you want dynamic content on your wiki page. When Confluence is integrated with JIRA, the JIRA Issues Macro can be used to pull relevant tickets onto a wiki page and content such as Status can be displayed and will be updated as the actual ticket in JIRA are updated.

Page 12: SCALEUP - Insight Partners

12Insight Partners

Best Practice: Don’t go overboard with macros on a single page because too many macros can cause a slow-down when loading the dynamic content on the page. For example, the JIRA macro is nice to pull back tickets. However, if the filter you’re using to capture the data is pulling hundreds of tickets then performance can de-grade and cause users to avoid accessing the page.

Combination Reporting Pages

If you find yourself in a position where you are tracking data on multiple pages unnecessarily, try combining the pages into a single page by mixing the macros with other native gadgets on a single page. Add charts to track the work by resources and add a JIRA macro to pull in the high priority tickets for an upcoming release.

Best Practice: As with macros, you should not go overboard with a single reporting page. Also, always test your pages using multiple browsers to ensure the page displays the content properly. Dynamic content from JIRA can be based on a project or a filter so you will want to make sure the permissions are set properly, otherwise your page will display errors on it for users.

Reporting Add-ons/Plugins

If you find that the native offerings just don’t meet your requirements, you are always welcome to explore the Atlassian Marketplace for add-ons and plugins that can be added to your Confluence environment.

Best Practice: While there are many high quality solutions available in the marketplace, you must use caution as the cost can become too much and maintenance can be overwhelming. Always be sure to test any add-on or plugin prior to introducing it into the production environment. Some add-ons and plugins can have a bad impact on the native templates or your own custom templates.

Page 13: SCALEUP - Insight Partners

13Insight Partners

JIRA GETTING STARTED

Common User Mistakes & Best Practices

This section will list out the most common mistakes that are made when organizations implement JIRA in their environment. Each section will contain best practice information to help organization avoids these common pitfalls.

Project Structure

Problem: While there are many different ways to establish JIRA in the organizational environment, the (2) most common structures are Product-based and Team-based. Either structure works when implemented correctly, however, users tend to not know which one to implement to meet their business requirements.

Best Practice: Because each strategy works and both are equally effective, you should choose the one that matches your requirements the best. Today, most organizations work in a team-based manner so naturally set-ting up JIRA projects based on teams would be the best choice for that. However, you also have to consider your filters and how you want to extract data for reporting purposes. For example, do you have a single project and all of the teams work out of that one project? Or do you set up a project for each team to work from? The first approach means your filters are isolated to a single project and thus, are simpler to query. The latter approach means your filter will have to account for project that exists in order to collect the desired metrics. Another consideration is permissions. Many times organizations like to have a bit of separation and not all work needs to be transparent to everyone. If this is a requirement for you, then you are better served by giving each team their own project and allow them to control the permissions as needed.

Global Content Items

Problem: There is a set of content in JIRA that is global and all projects depend on. The global content items are Issue Linking, Statuses, and Resolutions. There is a set of native values for each of these items. However, users that are new to JIRA tend to add unnecessary or duplicate values that cause issue later on and significantly im-pact the performance and accuracy of filters.

Best Practice: Stick closely to the native values for each global content item. The list of values for each item should remain small and concise. It is ok to add 3-5 values to each item, but any more than that will cause issues later on. Also, be careful not to duplicate any of the native values as those have source code tied to them that adds needed functionality. Duplicate values can confuse the tool in some cases and confuse the users in many cases. Finally, always make sure the values you add have meaningful names so they are easy to decipher.

Project Content Items

Problem: JIRA is a highly flexible tool and many users try to do too much in the beginning before they fully under-stand what they’re requesting and the impacts it will have later on. In this section, a lack of planning or a lack of a solid strategy will ultimately lead to chaos.

Best Practice: The first thing to do is make a copy of “all” of the default Schemes. Never modify the out-of-the-box schemes to meet your requirements. These items are used extensively throughout the tool and have critical functionality to the workings of the tool. Furthermore, modifying the default schemes can potentially take down the organization because when there are updates, it is possible that your customizations on the defaults will be

Page 14: SCALEUP - Insight Partners

14Insight Partners

overridden. After you make a copy of the default schemes, you may want to create your own fully customized schemes. Below are some guidelines to follow in the event you have requirements beyond those of the native offerings:

• Issue Types: JIRA comes with a default set of issues types and each JIRA product (i.e., JIRA Core and JIRA Service Desk) will add their own specific issues types to the list. JIRA basically offers most, if not all, industry standard types. However, if you find that you need something more you are allowed to create them.

• Best Practice: There are plenty of types to choose from and some existing issue types can be repurposed. The goal here is to keep the list of issue types to a minimum. There is rarely a need to add any more than (5) completely custom issue types to the list.

• Workflow: Standard workflows come with JIRA, but very few organizations use those workflows. Instead, organizations favor using their own homegrown workflows. Of course this is absolutely fine to do. However, most organizations go overboard and either have too many workflows or have overly complicated workflows that cause users to have negative experiences. An example of a bad workflow is one that has (10) or more steps and is linear. Meaning the user cannot jump to any status in the workflow but must go through each workflow status one-by-one.

• Best Practice #1: A good workflow typically consists of (7) steps and uses easy to recognize verbs for the transitions. Unless there is a solid reason for doing so, your workflow should not exceed (10) steps. The workflow should be flexible to use. There are times when a step or two must be hit before being allowed to move a ticket forward in the workflow. However, more than a couple of these items will cause users to be frustrated which you want to avoid.

• Best Practice #2: Each issue type can have its own workflow assigned to it. So Epics can follow one workflow while Stories can follow a different workflow. When considering this option you must consider your filters. It is much easier to filter for all Epics, Stories, and Sub-tasks in the Open status rather than to filter for all Epics, Stories, and Subtasks in the Open, To Do, and Backlog statuses. If you are just starting out it is recommended that you use the simple approach of one workflow for all of the issue types within your project.

• Best Practice #3: Don’t try to build validation and permissions into your workflow via the statuses. Doing so will cause the workflow to have too many steps. Instead, you should make use of the Triggers, Conditions, Validators and Post Functions that each workflow has available to it. These items allow you to build complex logic into the workflow while keeping it within the recommend size from Best Practice #1.

• Screens: When each project is created, JIRA provides a set of default screens depending on the Project Type you selected. Organizations will create an endless number of screens that ulti-mately serve no real purpose. For an Atlassian administrator, this can be a nightmare to maintain especially if there’s a migration that needs to be done.

• Best Practice: Use the default screens and update them as needed. Tabs are also available for each screen so it is better to logically group the necessary fields to a single screen than to have many different screens assigned to a project.

• Custom Fields: New users can go overboard very quickly when it comes to using custom fields. Everyone wants custom fields for their project. The maintenance of custom fields is exponentially worse than it is with screens because there are several custom fields that serve the same purpose.

Page 15: SCALEUP - Insight Partners

15Insight Partners

• Best Practice #1: Don’t use confusing names and do not use the names of any standard JIRA fields. Duplicate names make it difficult to capture the correct field on a screen as well as filter on. In these areas, JIRA does not provide a way for you to distinguish between fields with duplicate names. They are all simply listed in the dropdown.

• Best Practice #2: Validate that there’s not an existing field that can be reused. A good ex-ample of this is a custom field called Impact. Several projects want to use this field but each project has a different set of values it needs. An untrained JIRA administrator will simply create multiple custom fields. Each custom field has the exact same name because that is a requirement from the projects. In this case, the JIRA admin should find the existing Impact custom field and simply use Contexts on it. Contexts allow the field to be reused but have different values for each project.

• Versions: When starting on new work or bug fixes, projects will create a Version. Each Version will contain “x” number of tickets for the upcoming Release. The most common mistake when using assuming that Versions are global, but they are isolated to a single project. This confusion leads to bad filters and reports.

• Best Practice #1: Create a plan to ensure that all projects create the same Version. General-ly, the Project Management Office (PMO) or a Product Owner handles this task. It can even be the JIRA administrators. Regardless of which organizational role handles this task, it is important to understand how Versions work to ensure proper filtering and reporting when needed.

• Best Practice #2: JIRA tracks versions and releases using a single native field called Fix Ver-sion/s. When a version is created, it is scheduled. Once that version has been successfully deployed into Production, someone on the project teams has to go in and perform a release operation on that version. Doing this converts it to a Release in JIRA speak and this opera-tion is very important for auditing purposes.

Reporting Strategies

JIRA has multiple methods for reporting status on tickets and versions for the projects that reside within the tool. Each has it’s set of strengths and weaknesses so it is always best to use each for its strengths and rely on the other methods to present a complete and transparent view of the daily activities of development and the lifecycle of the organization’s products.

Dashboards

Dashboards are a feature in JIRA that extracts information from projects and displays it in nice native gadgets. You can even put charts and graphs on dashboards for a visual representation of the data. A good guide for set-ting up a basic, but very useful dashboard can be found here: 7 steps to a beautiful and useful agile dashboard. While this is a good starting point, the purpose of dashboards extends beyond a single setup and it is recom-mended that organizations take full advantage of dashboards.

Best Practice: Use dashboards in a 3-tier format: User, Project, and Management.

• User level: This dashboard is specific to an individual project resource. It helps them track the tickets in their queue, the work they’ve done, and the work they’ve completed. This dashboard is also useful for providing status reports to the team lead or project manager.

Page 16: SCALEUP - Insight Partners

16Insight Partners

• Project level: A dashboard at this level provides a view into the project’s overall workload and the work being done towards a given release. A project dashboard is necessary so that all of the project resources have a single source of information of how the project is doing and what resources are working on specific tickets to accomplish the overall release goal.

• Management level: Upper management and stakeholders don’t want to spend the time review-ing each individual’s dashboard and seeing the daily activities towards a given release. There-fore, a dashboard should be created that provides the key information that they want to see at any given time. Most management teams work on red, yellow, and green indicators to know a real-time status of the projects or releases. A gadget, such as JIRA’s Agile Sprint Health Gadget, displays how many tickets are in the Open, In Progress, and Closed statuses. If management desires to see data beyond the quick summary, they should be allowed to access the Project level dashboard as well.

Agile Boards

When working with agile boards, you have (2) options in JIRA: Scrum and Kanban. Scrum boards allow you to fol-low industry standard agile principles and include the concept of Sprints. Kanban works in the same manner as Scrum boards but do not include Sprints or the additional functionality. You can use either board based on your requirements or you can have a mixture of the two boards. So which option should you use when starting out?

Best Practice: To make things easier, you should start by using the Scrum boards. Regardless of which board you use, you should follow the same 3-tier principles listed under Dashboards but for boards you only need two levels: Project and Management.

• Project level: This board is the main level for a project and the work being done on a daily basis towards a release. It also includes features for the User level in that one can simply click on a link to only view the work that is assigned to them. This board gives all of the project resources the ability to see what is being worked on and what has been completed.

• Management level: This board either pulls data from multiple other boards or filters that extract the necessary data from multiple projects can drive it. The goal of this board is to provide man-agement with an overall view of the project activities towards a given Sprint or Release.

Project-specific Reports

Each project created in JIRA comes with a set of project-level reports. They are:

• Cumulative Flow

• Control Chart

• Average Age

• Created vs. Resolved Issues

• Pie Chart

• Recently Create Issues

• Resolution Time

• Single Level Group By

• Time Since Issue

Page 17: SCALEUP - Insight Partners

17Insight Partners

• Burn down Chart

• Time Tracking

• User Workload

• Version Workload

These reports are not as customizable as dashboards and agile boards, but they are meant to provide standard reports that all projects need so the user doesn’t have to create them manually.

Best Practice: Use these reports as much as possible. If you out grow them, you can always create reporting that expands on the information they provide using filters and dashboards. However, they provide a quick view for project resources that need to track these types of metrics.

Page 18: SCALEUP - Insight Partners

18Insight Partners

COMMON ADMINISTRATION MISTAKES & BEST PRACTICES

Common Administration Mistakes & Best Practice

As administrators work to try and ensure the best possible experience for the end-users, they sometimes make mistakes that lead to a bad user experience. This is not intentional as administrators have many factors to con-sider when tools are available to a large user community. Below are the most common mistakes made and the best practices associated with them.

Attachment Size

Problem: Attachments are a critical part of the collaboration experience and it is always recommended to en-able this feature in Confluence and JIRA. However, administrators tend to forget to change the default size limit of 100 MB so users run into various issues as they attempt to upload files larger than the default size.

Best Practice: It is recommended to always allow the users to upload files and the minimum size setting should account for your daily needs. For example, if you’re organization does a lot of media then you’re setting will be larger than an organization that just uploads screenshots. Another key consideration is the size of the file sys-tem. Be sure the available attachment space on the file system is large enough to handle the expected attach-ment load. This should be an item on your audit checklist so additional space can be added if needed.

User and Group Management

Problem: Initially, most organizations don’t develop a proper user and group management strategy. They may just add individual accounts or create meaningless groups and meaningless group names. If the instance be-comes large enough, this can present significant problems. A good example is trying to decommission a user’s account that is no longer with the company. It is bad practice for an administrator to go to each Confluence space or JIRA project looking for user accounts and removing their permissions. This approach becomes time and resource intensive in large Confluence and JIRA implementations.

Best Practice: When starting out, the typical mindset is “we only have five users, so there’s no need to create groups because it’s just us”. The Atlassian instance quickly grows to (250) users and now there is a serious user and group management issue. A simple strategy is to create a group for read-only, edit, and administrator permis-sions for each Confluence space or JIRA project that is created. The following is a brief description of each tier:

• Read-only: This tier allows users to “browse” the content in the space/project but the user can-not edit any of the Confluence wiki pages or tickets within the JIRA project.

• Edit: This tier allows users to “browse” the content of the space and they can also edit the con-tent of the wiki pages. In JIRA, the user can edit and assign tickets.

• Space and Project Administrators: This permission should not be confused with the global administrator permissions. The global level administrator permission is for administering the tools while the space and project level administrator’s permission is isolated to a single space in Confluence or a single project in JIRA. This tier allows the administrator to control access to the space or project by granting read-only or edit permissions.

Page 19: SCALEUP - Insight Partners

19Insight Partners

The following is an example of how to use the above strategy. Let’s say a new space or project called QA Documentation has been created. Using the above recommendation, the support team would create the following groups:

• qadocs-readonly

• qadocs-edit

• qadocs-admins

Now when users leave the company or are reassigned, you simply access that user’s account and remove them from the existing groups completely or remove them from the current space or project groups and add them to the groups necessary for their new assignment.

Empowering Space and Project Administrators

Problem: Within Confluence and JIRA, there is a separation of administrator abilities for good reasons. However, one drawback to this separation involves granting user access to the space or project. Depending on the internal processes of the organization, granting new users access can be a hassle in the absence of a dedicated Atlas-sian team. IT Support teams tend to have other priorities for customers, production applications and infrastruc-ture so adding users to Confluence spaces or JIRA project is naturally a very low priority.

Best Practice: It is always recommended that you have a dedicated Atlassian team that can readily address is-sues for the user community. However, not all organizations will follow this recommendation and thus, a strategy is needed to ensure daily tasks are not negatively impacted. The backup recommendation is to allow 1-3 space/project administrators that can add individuals quickly and then follow up by opening a request to ensure the resource is added to the appropriate group when time allows. This works very well when a resource requires temporary access to a space or a project. If this recommendation is implemented it will also be necessary to add this as an item on your audit checklist to ensure compliance when being audited.

Email Notifications

Problem: Establishing the proper balance of email notifications that get sent out can be challenging. Some like to be emailed when a space or a page has been modified. Others like to be notified more so rules for comments and other updates come into play. So how does an organization strike the proper balance?

Best Practice: First, create a global email notification solution that includes the minimum email notification requirements for all Confluence spaces and JIRA projects. Second, allow the space and project administrators the flexibility to customize notifications for their spaces and projects. Finally, make sure the users are aware of the permissions they have regarding the notifications they receive. A global email notification strategy ensures all of the spaces and projects send a default set of notifications. Users typically do not complain about the global strategy, but if they do then the proper adjustments should be made to evolve your strategy until it is mature enough that there are very few complaints about it. If a user is complaining about being spammed, it is gener-ally at the space and project level. In these cases the Atlassian team can have them communicate directly with the space or project administrator to determine a proper course of action. Once the space and project levels have been ruled out, make sure the user has the proper settings on the space or project in question. The most common issue in Confluence is a user is “watching” the space and is unaware that this has been enabled. Simply disable it and this should solve the problem. In JIRA, users can “watch” tickets as well and doing so means they will get an email any time a ticket is updated which can become overwhelming. Meet with the user and check their settings to ensure they know what their current settings mean and help them make any adjustments for a better user experience.

Page 20: SCALEUP - Insight Partners

20Insight Partners

Confluence Specific

Comments, Comments, Comments

Problem: Many administrators make the mistake of disabling the native comment features in Confluence. Sometimes it’s for performance reasons. Other times it’s because a small number of resources complain about getting email notifications and feel the tool is spamming them.

Best Practice: The comment features should always be enabled to ensure the best possible collaboration ex-perience. If turned off, users will find other ways outside of Confluence to provide their feedback. Once they do this, it is hard to get them back on track. Furthermore, it is always best to have as much of the communication in Confluence as possible to avoid users having to hunt for dialog that may have led to critical decisions being made.

JIRA Specific

Notification Schemes

Problem: Establishing the proper balance of email notifications that get sent out can be challenging. Some like to be emailed when a space or a page has been modified. Others like to be notified more so rules for comments and other updates come into play. So how does an organization strike the proper balance?

Best Practice: First, create a global, reusable Notification Scheme that includes the minimum email notification requirements for all spaces. If you copy the default JIRA scheme, it’ll notify the Reporter, the Assignee, and any Watchers the ticket has on it. If you create one from scratch, then you’ll have to setup these default notification manually. Generally, the Notification Scheme is one that can be used for all projects once created. However if you have special needs for specific projects, you can always create a Notification Scheme and isolate it to that project. However, you should not have more than (5) Notification Schemes in your JIRA environment unless your organization has very special circumstances. Any more than (5) without solid reasons means you need to reeval-uate your current strategy.

Permission Schemes

Problem: Most entry-level JIRA administrators are not aware of the permission hierarchy in place within JIRA. This lack of knowledge leads to unnecessary or improper permission implementations that can cause head-aches with using the tool as well as with administering projects.

Best Practice: The first level of permissions starts with Project Roles. Project Roles are where you assign access to the project and what the role can actually do. An example of such is a QA project role. With this role, a resource should be on the QA team so they may perform testing functions on the appropriate tickets. Next is the Permission Scheme. This scheme can implement further restrictions above and beyond those at the Project Role level. An example is within the Permission Scheme you can state that individuals, groups or Project Roles can perform certain tasks such as creating new tickets in the project. Like the Notification Scheme, the JIRA administrators should generate a global scheme that should be used on all projects. If projects have special requirements then you can create additional Permission Schemes to address those needs. But again, you should not have more than (5) Permission Schemes and if you have more without solid reasons then you should review your current strategy and refine it to be to (5) or fewer schemes.

Page 21: SCALEUP - Insight Partners

21Insight Partners

MATURITY ROADMAP

Adding Atlassian Products

Regarding the Atlassian stack, most organizations start with JIRA Software and Confluence. However, once these tools have been stabilized and are providing near maximum value to the business, the organization should explore adding all the Atlassian tools to complete the solution. There is no concrete rule for adding the other tools into your environment, but the following is a guide to help you successfully add the other tools with minimal disruption:

1. JIRA Software (Project and Issue Tracking)

2. Confluence (Document Collaboration)

3. Portfolio for JIRA (Connect Strategic Goals to Development Realities)

4. Bitbucket (Git Code Management)

5. Bamboo (Builds and Continuous Integration/Continuous Delivery)

Depending on your organization, other tools may be added after the above have all been implemented and stabilized. Tools such as:

• JIRA Core (Business Management)

• JIRA Service Desk (Service Desk & Customer Support)

• StatusPage (Incident Communication)

• Trello (Visual Collaboration)

• HipChat (Self-hosted Group & Video Chat)

• Stride (Team Communication)

• Fisheye (SNV, Git, and Perforce Code Management)

• Crucible (Code Review)

• Crowd (Single Sign-on)

NOTE: Not all of the tools have to be implemented to be successful and some of the tools offer duplicate value so be sure to install the additional tools into your non-production Atlassian environment first and create a strate-gy that aligns the Atlassian products with your business objectives.

Integrating Atlassian-to-Atlassian

The end goal should always be to have a fully integrated end-to-end solution with as much automation as possible. So as Atlassian tools are added into your environment, be sure to integrate them to experience the full capabilities of a streamlined, end-to-end solution.

With JIRA as the main product, you should strive to add on the other products as you evolve as a business and your processes mature.

Integrating Atlassian-to-3rd Party

One of the major integrations to a third-party product is JIRA-to-Salesforce. Admittedly, JIRA is not a customer management system so many organizations rely on products like Salesforce to fill this void. The following is a standard flow that involves both products.

Page 22: SCALEUP - Insight Partners

22Insight Partners

Salesforce-side

• Used for Customer Management

• Customers submit “Cases” to have work to be done on products being used by your organization.

• These tickets need to be given to the Development or Engineering teams for resolution.

• The Development or Engineering teams do not have access to Salesforce.

• The “Cases” need to be updated to ensure the customers stay up to date with the progress.

JIRA-side

• The Development/Engineering team needs tickets submitted into JIRA so they know what they’re working on.

• If the customer has updates, the Development/Engineering teams need to know about them.

• As the teams work towards resolution, they need to pass that information back to Salesforce.

• The customers do not have access to JIRA.

Rather than double the efforts of manually keeping the two separate systems in sync, you have the option of in-stalling a plugin that connects the two systems. After configuring the plugin to meet your specific requirements, the automation takes over and allows the systems to stay in sync with very little manual intervention.

One of the most common plugins used to address this requirement is made by ServiceRocket and the plugin is available for both on-premise and cloud versions of Atlassian’s JIRA:

• Salesforce & Jira Server Connector

• Salesforce & Jira Cloud Connector

There are other systems that also have plugins so be sure to review the Atlassian Marketplace to see what is available to meet your specific requirements.

Page 23: SCALEUP - Insight Partners

23Insight Partners

OTHER CONSIDERATIONS

Atlassian Migrations

There will be times when clients are encountered that may be using other products and desire to migrate over to the Atlassian platform. Those clients should feel comfortable in knowing that a migration from other major vendor products to Atlassian is available to them. For example, it is possible to migrate from Microsoft Team Foundation Server to JIRA Software.

Migrations can also occur within an existing Atlassian ecosystem. The client may need to move their setup to new servers due to a merger or acquisition. Or the client may desire to migrate from their internally hosted Atlas-sian ecosystem to Atlassian’s cloud---of vise versa. The takeaway here is that Atlassian supports:

• Third-party-to-Atlassian

• Atlassian-to-Atlassian

• Server-to-Server

• Server-to-Cloud

• Cloud-to-Server

The complexity of a migration effort depends upon the existing data and how much historical data the client wants to retain. However, even the simplest migration can be a significant undertaking. Therefore, it is recom-mended that the client always use a consulting firm that has the necessary experience to ensure the smoothest transition. The ideal consulting firm will have critical, undocumented knowledge that will be key to a successful migration effort. It may cost a bit more to use a consulting firm, but that cost is minor compared to attempting the migration internally and failing multiple times and having the internal user community down for days as the client attempts to recover from backups of the systems.

Atlassian DevOps

Atlassian offers a DevOps solution via their Bitbucket and Bamboo products. When adopting DevOps internally, Atlassian recommends a four-phased approach as found here in the blog The 4 phases of DevOps with Atlas-sian. Adding Bitbucket and Bamboo into your existing Confluence and JIRA environment adds another level of automation, transparency and traceability to your organizational efforts. If your goal is to achieve Continuous Integration/Continuous Delivery (CI/CD), then these tools are a must-have. Imagine the following use case:

• A bug is discovered and a ticket has been opened. (JIRA Software)

• A developer has resolved a reported bug and checks-in their code. (Bitbucket)

• The new code has been detected and a build is launched. (Bamboo).

• The build is successful and is deployed to a target environment.

• On the target environment, Unit Testing occurs.

• Unit Testing is passed successfully, so the new package is deployed to a QA environment.

• Associated JIRA ticket is moved to the next status.

• QA Testing efforts are successful, so the package is deployed to a Staging environment.

• Associated JIRA ticket is moved to the next status.

• Acceptance Testing is successful, so the new package is deployed to Production.

Page 24: SCALEUP - Insight Partners

24Insight Partners

• Associated JIRA ticket is moved to the next status.

• The new package has been successfully deployed into a Production mode.

• Associated JIRA ticket is moved to the closed status.

• All relevant Dashboards have been updated to reflect the new release.

• All relevant Scrum or Kanban boards have been updated to reflect the new release.

• All relevant Confluence pages have been updated to reflect the new release.

This is a simple example, but the point is that all of this can happen with minimal or no human intervention, which means your organization has achieved its goal of fully implementing CI/CD demonstrating the organization’s effi-ciency, decreasing its time to market.

Help Desk

There are many systems in the market today that have been around longer than Atlassian’s JIRA Service Desk solution. However, the other systems do not offer the deep integration that JIRA Service Desk has with the rest of the Atlassian stack. Another bonus is that JIRA Service Desk is really easy to use from a client perspective in that they use the built-in customer portal to submit tickets and stay in the loop via emails until their ticket has been resolved. The simple use case offered in the previous section can be taken a step further by introducing JIRA Service Desk as the first bullet item in that:

• A customer identifies a bug and submits a ticket using the Customer Portal. (JIRA Service Desk)

• The ticket is reviewed and the following occurs:

• A solution exists and the customer is directed to review the solution in the Knowledge Base. (Confluence)

• The ticket is validated as a bug and a ticket is created to inform the development team of its existence. (JIRA Software)

• The newly created ticket is linked to the support ticket and the customer is kept in the loop until the issue has been resolved.

JIRA Service Desk is not only for external customers, but it can also be used internally to support the employees of the organization. Just like JIRA Software, other support-based systems can be migrated to JIRA Service Desk to offer your organization a complete Atlassian ecosystem that is tightly integrated. Another benefit to using JIRA Service Desk instead of another vendor is that you have a single source of support for all your support needs as opposed to contacting multiple vendors to resolve an issue that may or may not reside within their product. A single vendor means your issues are resolved faster and your users are not down for extended peri-ods of time while everyone tries to figure out if it is truly their product that is causing the issue.

Page 25: SCALEUP - Insight Partners

25Insight Partners

SUMMARYThere is a lot of content in this document about various Atlassian products, add-ons and plugins. The key take-away is that we are living in a world where a single ecosystem solution has more benefits than an ecosystem that consists of multiple vendors. If you review the vendors whose products you are using, you’ll most likely find that they are good at a single discipline but do not venture outside of that scope to offer their customers an end-to-end, comprehensive solution. Nowadays, having a multi-vendor ecosystem is more costly and time consuming than say ten years ago.

Atlassian works hard to fill this void by creating a suite of products to meet as many of its customer’s organiza-tional needs as possible. In 2018, Atlassian has launched a marketing campaign directed at Human Resources and has stepped up its efforts to support DevOps initiatives. Imagine that your organization is operating using a single vendor that offers a fully integrated solution that you can add onto as you need to or easily scale back if necessary. That exists in today’s business world and that solution is called the Atlassian Stack.