3 min read

Jira Service Management Request Types Best Practices

By Praecipio Consulting on May 10, 2021 3:10:00 PM

Blogpost-display-image_Jira Service Management Request TypesSince 2013, Jira Service Management has been Atlassian's solution to IT Service Management for both internal and external customers alike; more than 8 years of continual development has led to countless examples of how JSM has delivered value to its users. In this 2014 video, we can see how Puppet Labs used Atlassian's Jira Service Desk, now Jira Service Management, to resolve tickets 67% faster. Take it from Atlassian's ITSM Partner of the Year three years running, we love how JSM supports your IT governance strategy. However, when defining a service desk for your organization, one of the most important decisions that you'll make is around how you define your Request Types.

What are Request Types 

In Jira Service Management, the request type defines exactly what the customer sees and how the ticket moves and is displayed after it's been submitted. 

Request types allow you to map a single issue type to different kinds of requests. For example, you may have issue types like Incidents and Service Requests. That's how your IT team understand incoming requests and they have the benefit of being able to span multiple contexts. However, as an end-user, when I'm coming to the portal I'm not thinking in ITIL terms. I'm likely thinking more along the lines of "I can't login" or "I need a new computer." 

Request types allow you to represent both sides of the equation - the foundation of your portal are the issue types, but request types let you customize how they appear to customers in the portal. So, let's see what exactly we can do with request types.

What can I do with request types

  • Map a single issue type to many different request types: If there are multiple requests that follow the same workflow, you can utilize a single workflow across as many forms as you'd like!
  • Group requests: You may have multiple requests that can be logically grouped together, like Software and Hardware.
  • Change field display names: Even thought they're filling out the Summary field, on a request you may want it to say "What problem are you experiencing?" or "How can we help."
  • Show specific Jira fields: While an agent may need to see and edit fields like Team or Priority, you probably don't want your customer to see those on Create.
  • Preset fields: If certain request types have some constant information, you can preset fields without needing to modify the workflow or use any automation.
  • Customize how workflow statuses are displayed: If you don't need your customer to know that an issue is being escalated to Tier 2 or Tier 3, you can mask those statuses so all the customer sees is that the issue is "In Progress" and they won't receive notifications as it moves through that internal workflow. 

With that in mind, there are some best practices to keep in mind. 

Request type best practices

  • Think about the customer experience! Why are they coming to the portal?
  • Don't necessarily break request types or groups down by IT org structure. While this could be useful, there are lots of ways to route request types to the right place without having it affect the customer view.
  • Use hidden fields on your requests to simplify the experience - if you know a system wide outage is always urgent, don't make the user complete that field!
  • Use hidden components or Team custom fields to route to the appropriate queues. 

At Praecipio Consulting, we have the experts that can help you implement ITSM best practices across your entire organization.  Contact us, we'd love to help!

Topics: jira blog best-practices tips request jira-service-management
5 min read

A Carbon Neutral, Nature Positive Praecipio Consulting

By Christopher Pepe on May 4, 2021 11:09:00 AM

Blogpost-display-image_Praecipios green pathIn 2019 the Praecipio Consulting Green Team was given the goal of creating a carbon neutral future for the company as part of our Climate Action Plan. The Green team had already set its focus on Carbon, Human Health, and Sustainability. The net zero challenge was taken up with the goal of promoting those pillars. Praecipio Consulting has determined that the climate stabilization wedge of Proforestation best meets the company's environmental and human health goals. Our value "Maximize mutual benefit" is exemplified by the parcels that Praecipio Consulting has contributed to protecting. 

Finding our path

Praecipio Consulting initially rolled out a generous Green Stipend program to incentivize change in employees daily lives, and encourage others to do so as well. Through education and incentive we aimed to amplify the good that we could do. To reach carbon neutrality we would credit Praecipio Consulting for the carbon emissions that where eliminated by positive changes in behavior. Many employees improved insulation, installed new efficient windows, etc. Ultimately that program proved ineffective, however, it laid the groundwork for our future. The main issue was that the Green Stipend encouraged a holistic lifestyle change whose benefits were multifaceted, but the success of the program was only measured by the reduction in one's carbon emissions. The cost per ton of carbon dioxide equivalent (CO2e, a standard measure used to model carbon footprint) was too high for the program to reach carbon neutrality on budget.

The Green team wished to retain the behavioral incentive component of the Green Stipend. Since inception, the Green team has delivered presentations via a monthly all hands State of the Business, on how we arrived at a climate crises, and more importantly, how individuals can change their behavior for a future that is reintegrated with the natural world.

Praecipio Consulting also needed to achieve its publicly stated goal of being carbon neutral in 2020 and beyond. One obvious solution was to buy carbon offsets from any number of sources. There are publicly available volunteer markets (also regulated markets for carbon intensive regulated industry but that does not apply to this type of business), as well as many afforestation companies that are replanting forests all over the world. Digging into each of these options ultimately made us feel that while we could check the carbon neutral box, it wasn't maximizing mutual benefit. Carbon exchanges offer very cheap credits with little insight into their source. Credits may come from a forest, or they may come from any number of other sources, some of which are of questionable utility to addressing climate change. Afforestation is a noble cause, and we support organizations involved in those activities like TreeFolks. However, a 1" sapling planted today will take decades to sequester any amount of carbon and we simply don't have that much time. We applaud these organizations, and will continue to fund them because we will need those trees in the future, however we felt we needed to do more now.

Proforestation

Since the 1600s the United States has cut most of its forests. Estimates vary, but it likely that at most 10% of our old growth forests remain and even in heavily forested areas there are surprisingly few undisturbed forests. Europe has achieved some of its carbon goals by purchasing wood pellets from the United States to power electric generation plants. Far too much of these wood pellets are made from clear cutting forests which removes carbon sinks and increases atmospheric carbon. This practice is considered carbon neutral largely due to an accounting error that there is little incentive in acknowledging.

Simply put, proforestation is a management practice where a mature forest is allowed to self-regulate. This is contrasted with active management for timber, biomass fuel, or other disruptive uses. The benefits of mature forest are many including habitat for native species, clean water, and obviously carbon storage. An important finding is that while a mature tree has a slower metabolism than a young tree, it still adds more biomass (mostly atmospheric carbon) than the younger, more vigorous whippersapling.

Because existing trees are already growing, storing carbon, and sequestering more carbon more rapidly than newly planted and young trees (Harmon et al., 1990; Stephenson et al., 2014; Law et al., 2018; Leverett and Moomaw, in preparation), proforestation is a near-term approach to sequestering additional atmospheric carbon: a significant increase in “negative emissions” is urgently needed to meet temperature limitation goals.

Each year a single tree that is 100 cm in diameter adds the equivalent biomass of an entire 10–20 cm diameter tree, further underscoring the role of large trees (Stephenson et al., 2014)

Human Health

Like all humans, Praecipians tend to find comfort, rest, and restoration when in the natural world. The human world is an amazing place filled with bright lights, sounds, and smells, that are largely ours (tho you are really Never Home Alone). The high intensity of the human world is especially draining. We can turn to meditative practices like church, yoga, and other mindful experiences to recharge, however, these are amplified when they occur in a natural setting.

Mature forests are magical and restorative places for humans to spend time. The practice of Forest Bathing has gained popularity, and the recent pandemic-induced shortage of any and all outdoor sports equipment has highlighted how people feel when they are in the natural world. Praecipio Consulting has focused on supporting forests in places that employees can enjoy and recharge. While the goal of keeping these forests wild and productive (with respect to ecological services, and not timber) they will be a refuge to Praecipians for many years to come.

Existing projects as of 2021 Q1

The following are significant proforestation and/or preservation projects that Praecipio Consulting has or continues to support. All are important ecological service providers with wild recreation opportunities. All had the potential to be used in an environmentally non-beneficial way and are now protected to continue to provide those services. The forests store 3 to 5 years of carbon emissions based on Praecipio Consulting's current operational model. Travel to customers was our largest segment of carbon emissions and the pandemic has eliminated that. If the post pandemic world is half as video-conference friendly that will greatly aid in our effort to reduce our carbon footprint.

Praecipios green path-table

Protecting existing forests is a powerful way to maximize the mutual benefit for all living things and promote a resilient and stable environment for life to thrive. At Praecipio Consulting, we pride ourselves of being a people-centered company, and we strive to do business while staying true to our values. Taking care of our planet is centered at the core of who we are.

Topics: praecipio-consulting blog culture environment corporate-responsibility green-team
2 min read

Test Driven Development

By Praecipio Consulting on Apr 28, 2021 11:15:00 AM

Blogpost-display-image_Test Driven DevelopmentWhen we're in the process of creating a product, we want to see the end result. We have a vision of what the product will look like and how we want to get there, so it's tempting to try to get the product running as quickly as possible. However, if and when the product breaks or needs to be updated, we are going to be responsible for fixing it. With that in mind, we look toward Test Driven Development (TDD)

Nobody likes folding laundry. It takes time, and not everyone appreciates the results (at least not initially). The next morning is a different story: When you wake up to a crisp stack of folded shirts, choosing an outfit is easy - there's no rummaging through a laundry bin and you know exactly what's ready to wear. Sometimes, an initial time investment such as folding laundry, can help us out in the future.

Testing the Feature

We could test manually, going through our list of features and testing each feature to make sure the product is operating as intended. Or, we might write automated tests once the product is finished. But like rummaging through a laundry bin, working through this retroactively can be complicated and we may miss important information.

Many developers use TDD to prevent dealing with this "laundry". Instead of writing tests during the QA phase of development, developers write automated tests before anything else. Imagine a developer adding a new feature to software that allows the user to change the color of the background. The developer first writes an automated test to check whether the background color is changed once a button is clicked. The test may initially fail. They would then add the functional code and use the automated test to make sure the feature works.

Why would a developer want to spend extra time writing tests before building a product?

First of all, TDD keeps development simple and goal-focused. Features are added only when they can pass a specific test. This means that the developer has to make sure that each feature is necessary and the objective of that feature is clear. With no objective, it's impossible to write a test to pass your objective.

The TDD time investment leads to time savings in the future. Although it takes more time to include automated tests in the initial development of a product, there is potential for time savings in the future. When a product breaks, it's clear which part of the code is causing the failure. This means that QA may go more smoothly as bugs or product upgrades arise.

Test Driven Development-1Conventional development vs. Test Driven Development. Using TDD requires an initial time investment but can lead to time savings long-term.

Of course, TDD processes aren't the best for every team. When there are too many possible test cases (often seen in GUI development) it can become impossible to write tests for every functional situation. Like any set of processes a team uses, think about what makes sense for your situation. Does the product have finite requirements? Has QA testing used eaten away hours of time due to buried bugs? Making an early time investment can keep things orderly. Even if your sock drawer is destined to be a mess, think about how you're building your products.

Want to learn more about testing? Check out Could Testing Be the Missing Link for Effective Agile Transformation.

Topics: blog best-practices plan testing development agile
2 min read

Queues vs. Dashboards in Jira Service Management

By Rebecca Schwartz on Apr 26, 2021 10:15:00 AM

Blogpost-display-image_When do I use JSM queues vs. dashboards-When it comes to understanding the progress of work in Jira, Atlassian has some great options natively within Jira Service Management. Queues are available in each Service Management project in Jira and Dashboards are available in all Jira products. These features give users important insight into what teams are working on, but how do you know when to use which, and why? Having easy access to the progress of work in the system, as well as some of the stats that go along with the quality and completion of the work, is essential for any team's success. Below, I'll discuss the functionality of Queues and Dashboards in Jira and when one should be used over the other. 

What are queues?

Queues are groups of customer requests that appear in Jira Service Management projects. They are used by service desk agents to organize customer requests allowing the team to assign and complete customer requests quickly and efficiently. There are a few helpful queues that come with your service desk, but Jira Admins can also create custom queues if the ones in place are not the correct fit for the team. 

What are Dashboards?

A Dashboard is a page of reports and data visuals related to issues in Jira. Dashboards are customizable and can be tailored to meet the needs of various users throughout the organization. Individual users often create their own Dashboards to easily visualize what outstanding work they specifically need to get done. Teams can use them to see their overall progress of work. Management can use them to get a more high-level overview of the progress of work across the entire organization. Gadgets make up Dashboards and are often based on Jira filters or JQL. They typically come in the form of charts, tables, or lists. Dashboards are available no matter what kind of Jira project you're working in.

When to use queues vs. Dashboards?

Queues are great for agents and other folks who need to work on issues in a service management project. If queues are broken up by SLA's and/or priority, they help agents determine which issues are most urgent and need to be worked on ASAP. Then, agents can easily grab issues from the list and begin working on them. Queues don't give you any stats or overall status on work that's in progress or has yet to be completed. It's simply a way for those working on Jira tickets to organize them and decide what to work on.

While queues are limited to a single project, Dashboards can be used across multiple projects. They give more information on the work and can provide more details such as the time from creation to resolution, how many issues of a particular type were submitted in a given time period, and which agents completed the most issues. Dashboards are perfect for users who need to get an overview of what's going on, but don't necessarily need to work on the issues. Since Dashboards are meant for viewing Jira data, these pages are perfect to give higher-level users an insight into what's going on with the outstanding work. Using gadgets, these users can see where improvements need to be made if, for example, SLAs are continuously breached. They can also be used to see what works well for your teams. 

You have questions?  We have answers!  Contact us to schedule a call with one of our Atlassian experts.

Topics: jira atlassian blog tips service-management tracking project-management jira-service-management
2 min read

Get early access to Atlassian Data Lake for Jira Software

By Kye Hittle on Apr 23, 2021 2:00:00 PM

Blogpost-display-image_Jira Data Lake PreviewAt Praecipio Consulting we understand that the data contained within your Atlassian tools is a critical asset for your organization. To help customers more easily access their Jira data, Atlassian has developed Data Lake! As of March 2021, Data Lake is available to preview in Jira Software Cloud Premium and Enterprise.

Warning! Beta software should not be used for production purposes. Breaking changes are likely as Atlassian tweaks this functionality based on user feedback. Not all Jira data is currently available and permission levels are limited but Atlassian is quickly working through its roadmap. In addition only English field names are available, as of now. Therefore, any information presented here is subject to change.

Data Lake allows you to quickly connect the best-in-class business intelligence (BI) tools you've already invested in to query the lake directly.

Compatible BI Tools include:

  • Tableau
  • PowerBI
  • Qlik
  • Tibco Spotfire
  • SQL Workbench
  • Mulesoft
  • Databricks
  • DbVisualizer

Jira-Data-Lake-preview

Data Lake uses the JDBC standard supported by many BI vendors. Supporting an open standard provides tremendous flexibility and power in reporting on your Jira projects.

Once you've identified the components of your BI solution, you'll follow three basic setup steps:

  1. Configure the JDBC driver
  2. Connect your BI tool(s)
  3. Navigate the Jira data model

You'll need your org_id and an API token for your Jira Cloud instance. Except for creating an API token (if you haven't already), there's no config required within your Jira instance. There are instructions for connecting to various BI tools in the Atlassian community Data Lake Early Access group. In addition, you'll find posts and diagrams to assist in answering business questions using Jira's data model.

If you're a Premier or Enterprise customer and would like to access the Early Access Program for Data Lake, complete this form to request access. You can also post questions and feedback for the devs in this group.

Are you interested in unlocking the power of data stored in your Atlassian tools? We're a Platinum Atlassian partner with years of experience helping customers leverage their Atlassian investment for even more value, so get in touch!

Topics: jira atlassian blog enterprise jira-software atlassian-products business-intelligence data-lake
2 min read

4 things not to do when starting to use Jira Service Management

By Praecipio Consulting on Apr 21, 2021 4:35:00 PM

Blogpost-display-image_When do I use JSM queues vs. dashboards-Finding yourself in need of a solution where others can request for service, help and support without sending an email?  Do you have stakeholders constantly asking for status updates on things they emailed you 20 mins ago?  If so, you might be looking for a service desk solution, and Atlassian has a solution for you: Jira Service Management.  Here are four things you SHOULDN'T do when converting over to or just starting off with Jira Service Management:

  1. Forget about the portal.  At first it might seem like extra effort because you can utilize SLAs and automation without a portal, but you will be doing your customers and yourself a disservice.  That, and you might be spending more than you should.
    1. By utilizing the customer portal through request types, you can take full advantage of quick support request with helper text, self service functionality, and customer alerting, allowing your agents to focus on resolving requests, and your customer to have a simple portal for updates and visibility.
  2. Forget about approvals.  JSM makes approval auditing super simple.  Through simple query filters you are able to generate reports around approvals.  You can easily identify within the support requests, which approvals and who declined or approved.  And all of this can be done through the customer portal (see 1 above), with one click approval or denial.
  3. Forget about SLAs.  When tracking performance metrics in your Service Desk, Atlassian makes it easy to configure SLAs, allowing visuals references in the support requests and well as generating reports.
  4. Forget about Automation.  Through simple If..Then logic, Atlassian makes automating routine tasks a breeze.  Tired of aging support requests junking up your resolve status?  Add an auto-close automation to move them directly to Close without passing Reopen.

By taking advantage of the powerful out of the box features provided by Atlassian's Jira Service Management, you will be simplifying your life and delighting your customers. If you're wondering if it's the right fit for you organization's needs, or are looking for expert advice on all things Atlassian, contact us, we would love to help!

Topics: jira atlassian blog optimization tips jira-service-management
4 min read

Why Upgrade Your Atlassian Stack?

By Suze Treacy on Apr 16, 2021 11:18:00 AM

Blogpost-display-image_Why Jira-Confluence upgrades are importantOne key component of managing your Atlassian products is managing their upgrades. Upgrades can present a daunting and significant time investment for many companies, generally involving apps, custom-developed plugins, and integrations, with a large number of users dependent on their success.

You know what upgrades are and that they're important. So why am I talking to you about them? Imagine the scenario, you're busy, you haven't had a chance to check in on the latest Atlassian security vulnerabilities and the emails you've received about them have been missed. You have also had higher priority work eating up team time, which has prevented the planning and execution of your Atlassian upgrades. One day, your instance comes under attack through one of the vulnerabilities exposed in the CVE. Your data is potentially exposed. An urgent, large, expensive, complex effort ensues in order to secure the instance; after 3 days, 2 full sweeps of the instance and multiple upgrades, the vulnerabilities are mitigated and your instance is safe.

Are you confident in when your applications are due an upgrade? Let's review a few common reasons why an upgrade may be recommended:

End of Life Policy

Once Atlassian has released a major feature version, it, and all iterations related to that major version, are supported for two years. After that, the versions are considered End of Life, and you will no longer receive support from Atlassian for any issues which arise. It is when reaching this point, that many people start considering upgrading their instances.

Security Vulnerabilities

Every Wednesday, Atlassian releases any new security vulnerabilities which have been identified for their server/data center products. These vulnerabilities include a security level, which is based on an Atlassian-calculated CVSS score for each vulnerability.

Severity Rating System followed by Atlassian:

Atlassian_severity_rating_system

Although there may be opportunities to mitigate security vulnerabilities in your current version, it is recommended to patch or upgrade immediately when a Critical vulnerability is identified. Vulnerabilities with a critical score generally result in root-level compromise or servers or infrastructure devices, or are straightforward to exploit.

Current security advisories can be found here:

https://www.atlassian.com/trust/security/advisories

New Functionality/Capabilities

Did you know that there is a new feature release for Jira Software every 6 weeks alone? Atlassian encourage users to submit bugs and feature requests at jira.atlassian.com. This public forum allows users to vote for and comment on submitted issues, and the Atlassian team utilize this and other feedback as a factor in their decision for what to implement next.  Platform releases contain the most significant changes, while Feature releases contain new features, changes to features, changes to supported platforms and removal of features. Feature releases can be designated as Enterprise releases, which, generally designated annually, are preferred for companies who need time to prepare for upgrades, but still want to receive critical bug fixes.

Compatibility with other Server Components

From time to time, Atlassian add and deprecate support for other server component platforms which work alongside your Atlassian application. For example, did you know that in Jira Software 8.6 and Jira Service Desk 4.6, support was added for PostgreSQL 10 and deprecated for Internet Explorer 11, whereas in Jira Software 8.8 and Jira Service Desk 4.8, support was deprecated for Microsoft SQL Server 2012 and PostgreSQL 9.4 & 9.5. To ensure optimal operation of your Atlassian instances, it's just as important to upgrade components of your server architecture, as well as your instances themselves.

Plugin Support

If you are one of the many teams who utilize plugins within their Atlassian applications, plugin compatibility and support is another area to be aware of when considering upgrades. Has support been deprecated for the plugin with the Atlassian version you're running? Is the plugin still supported when you upgrade to your target version? Atlassian have developed the Universal Plugin Manager, available in both Jira and Confluence, to enable you to screen for any compatibility problems prior to starting your upgrade. There are 4 categories for Compatibility which plugins can fall into - Incompatible (the plugin is not compatible with the target version), Compatible, Compatible if updated (the plugin is not currently compatible, but will be once running the compatible version), and Compatible once both are updated (the new version of the plugin isn't compatible with your current instance version - you need to upgrade your instance prior to updating the plugin).

Unable to Skip a Platform Release

When considering which version you'd like to upgrade to, it's important to consider your current version and your target version. When upgrading, it is not possible to skip a platform release - therefore, for example, when considering a Jira Software upgrade, it is not possible to jump from a 6.X release to the 8.X release and skip the 7.X release, you would need to take an intermediate step to upgrade to a 7.X version. Due to the functionality changes being much greater between platform releases which are not adjacently sequenced, there are more edge cases, and thus, greater risk, when navigating an upgrade spanning multi platform releases.

For assistance with upgrading your applications, partner with Praecipio Consulting's Managed Services team! Our team, fully dedicated to the Atlassian stack, offer peace of mind through managing, supporting, and maintaining your Atlassian tools, enabling you to maximize the benefits of your Atlassian applications while allowing your team to focus on their core roles. Working with our Managed Services team offers tribal knowledge and best practice from over 10 years working in the tools, allowing us to enable your Atlassian stack is optimized and operating at peak performance.

For more information on Managed Services, or anything else Atlassian related, contact us, and one of our experts will be glad to talk with you.

Topics: blog managed-services marketplace upgrade version-control-system atlassian-products marketplace-apps
5 min read

How Do You Manage Releases in Atlassian?

By Amanda Babb on Apr 16, 2021 11:05:00 AM

Blogpost-display-image_How do you manage releases in Atlassian-At a recent Atlassian Community Event, I was asked to present on a topic of my choice. After some thought (and, to be honest, a poll to our Client Delivery team), I decided on Release Management. It's a frequent topic of discussion with our clients: how can I understand what will be or is released? Also, what changed between what was in Production to what is in Production now

I've seen many complicated solutions and I've seen many simple solutions. However, your team, your company, or your organization has to hash out the following: 

  • What is your definition of "Done"?
  • What is your definition of "Release"?
  • Are these two things in conflict? 

Definition of Done versus Definition of Release

As you may already know, in Scrum, "Done" is when the Product Owner accepts the story as complete, meeting all acceptance criteria, and packaged into a potentially shippable increment. While I agree with this definition, at the same time I challenge the phrase, "potentially shippable." This is where you, your teams, your operations teams, and your product managers need to have a conversation. Does "Done" and "Released" mean the same thing across your organization? 

In one organization, they had four definitions of done: Done, Done-Done, Done-Done-Done, and Done-Done-Done-Done. In reality, they were defining the QA, deployment, and Production Release processes with the four separate definitions of "Done". This was also directly related to their use of Jira Software and how to demonstrate success to management. Notice I said success and not progress. The Teams wanted credit for code complete in Jira Software to demonstrate a predictable velocity. QA wanted credit for test complete in Jira Software to demonstrate a continuous flow. Release Managers wanted credit in Jira Software for integration activities before deploying to production. Operations wanted credit in Jira Software for the production deployment. As you can imagine, this was relatively messy in Jira Software and tying work from code complete through release to Production was excruciating. 

While Done may be clearer to your organization, "Release" may not be as clear. Different parts of the organization will have different definitions of Release. For a team, "Release" may mean the code has been deployed to a QA environment. For Operations, "Release" may mean deployment to Production. In the example above, "Done" and "Release" meant the same thing among the teams, QA, and Release Management, but not Operations. Nor did it mean the same thing across the organization. Without clarity across the organization, tracking and managing Releases in Jira Software becomes nearly impossible. Clearly defining "Done" and clearly defining "Release" across the organization can drive organizational alignment. Once you understand these two concepts, you can manage these in Atlassian using the following two methods: The Release Issue Type or Bitbucket Pipelines.

Method One: The Release Issue Type

Within your SDLC projects in Jira Software, create a new Issue Type called, "Release." This lets the organization know that, while code is complete, there are additional items that need to be fostered through the process. These may include documentation, release notes, a hardening sprint, or anything that can foster work from code complete to Production. The additional items can be managed as Sub-Tasks of the Release to understand the scope of work needed to move it through the process. 

As with any new Issue Type, the Release will need a Workflow. The Workflow can be simple, however, we recommend using a Ready for Production Status in the workflow. When integrating Jira Software with Jira Service Management, the transition to Ready for Production is a perfect time to automate creating a Change Request. Your Operations team can review the change request with a link back to the Release Issue Type. 

How do we know which stories and bugs are tied to the Release? Do we link all the work to the Release Issue Type? No. I mean, you could, but why take the time to do that? Is it really a value-added activity for traceability? Is there another way to tie these things together that could be quicker and easier? the answer: Yes. 

Even long-time users of Jira Software forget about Versions. If used properly, Versions can provide every team the status, progress, and any known issues in a single view in the Release Hub. This is true for all development activities AND the Release issue. By adding the Fix Version of the intended Release, every part of the organization can see the progress of the Release. Because JQL supports Versions, all items tied to a Fix Version can be displayed in other places such as a Dashboard or a Confluence page. With a little up-front discipline during backlog refinement, or sprint planning, or even big room planning, managing a release is as simple as adding a Fix Version to the work as well as the Release issue. 

Once the Release issue has been deployed to Production, always go back and release the Version in Jira Software. Anything that is not in a "Done" status category can either move to the next Version or be removed from any Version entirely. 

What if a story or bug spans multiple Releases? There is still only one Release issue per Version. However, I would also challenge you to take a look (again) at your definition of Done versus your definition of Release. Are you actually completing the work or are you pushing it forward again and again because there's a problem? In the next backlog refinement meeting and/or retrospective, ask why this continues to happen. Really dig in and understand whether the work needs to be moved to an Epic, de-prioritized, completed in the next sprint, or abandoned altogether. 

Method Two: Bitbucket Pipelines

Using Bitbucket Pipelines still requires your organization to have a conversation defining "Done" and "Release". However, the entities that support these definitions are different when integrating Jira Software and Bitbucket Pipelines. The Release is managed through the Pipeline and requires little human intervention. Instead, we work with a series of Workflow Triggers and automated deployments to determine where the Release is in its process. 

You still need to create a Version in Jira Software. You still need good discipline during backlog refinement and sprint planning to ensure work is tied to the correct Version. You may also choose to halt the automation just before deployment to Production based on your Change Management processes. Clarify the process before implementing in Atlassian. 

After your Version is created and work is tagged with the Version, add Triggers to your development workflows. For example, you can automate a transition from Open to In Progress based on the creation of a Branch in Bitbucket. You can also automate a transition to Closed or Done once a Pull Request is merged. Triggers in Jira Workflows keep people focused on the work instead of Jira Software. But where Bitbucket Pipelines really shine is everything that happens after code is merged. Separate Pipelines can be created per environment. For example, if you need to manually deploy to production, a Pipeline can automate the process through build and deploy to a staging environment after it passes all checks. Commits, build, and deploy information is visible in the Development Panel of the individual story or bug. You can even quickly understand failures and receive additional information by clicking on the failure. For a specific Version, as long as work is tagged, you can aggregate the overall health of the Release in the Release Hub by viewing the Version. Status, success, warnings, and errors are available in a central location. If everything looks good, simply click a button and deploy to Production. Alternatively, if the staging deployment is successful, automate the production deployment in the Pipeline as well. 

Which one is right for you? 

At Praecipio Consulting, we believe the answer is: "It depends." Regulatory compliance, risk tolerance, product uptime requirements, etc., may dictate which method is right for your organization. And, to boot, the answer can be different for different parts of the organization. However, the critical first step to implementing release management in Atlassian is to have a conversation. Are your definitions of "Done" and "Release" at odds with one another? What do they mean from a process perspective? Is there room for improvement in those definitions? We here at Praecipio Consulting have extensive experience with both Release Management best practices and the Atlassian suite of products. Contact us to find out how we can help you manage your releases more effectively. 

Topics: atlassian blog bitbucket process-consulting scrum tips project-management jira-software
3 min read

Can a Product Owner also be a ScrumMaster?

By Katie Thomas on Apr 12, 2021 10:21:00 AM

Blogpost-display-image_Can a Product Owner also be a Scrum Master-TL;DR: No!

Can one person hold both the Product Owner (PO) and ScrumMaster(SM) role in an Agile team? It's a question that a lot of companies starting their way through their Agile transformation will ask themselves (and us!). The Scrum team has three specific roles: Product Owner, ScrumMaster, and (most importantly) the Development team. It's clear why the question of combining SM and PO comes up so often - trying to figure out where current roles fit into the new dynamic can be a challenge for an organization, especially if your teams are now smaller and you don't have enough resources to fill the role of an SM and PO for each team. 

However, combining these roles is the biggest disservice you can do for your Agile teams. It may seem like a small tweak to the model, but given the functions of the two roles, you are setting up your teams for failure. Let's start with the definitions of these two roles so we can see why that is. 

Product Owner

The focus of the Product Owner is on the Product, as you might have guessed by now.  According to ScrumAlliance.org, "The Product Owner defines the what--as in what the product will look like and what features it should contain." The PO is responsible for maintaining the product backlog, and are responsible for communicating with stakeholders internally and externally to identify what the development team is working on. In their day-to-day, they are responsible for creating and prioritizing backlog items and communicating with the team expectations and acceptance of complete work items. 

ScrumMaster

The focus of the ScrumMaster is the team. "The ScrumMaster helps the Scrum Team perform at their highest level. They also protect the team from both internal and external distractions. ScrumMasters hold the Scrum Team accountable to their working agreements, Scrum values, and to the Scrum framework itself", as defined by ScrumAlliance.org. Where the PO is focused on What, the SM is focused on Who and How.  Arguably, the most important part of this definition is the emphasis on protecting the team. Internal distractions often come in the form of scope creep – new scope being introduced once work has already been committed to. In Scrum this often looks like new stories or bugs being introduced in the middle of a Sprint, and the job of the SM is to prevent this from happening as much as possible.

While I'm sure that we all know that some scope creep is inevitable (unless perhaps you're inhabiting the perfect utopia of business environments, in which case, I'll keep an eye out for my invite), but it can get out of hand quickly if there is no one on the team who is able to push back against the business. 

Okay, so why can't they be the same person?

By definition, the role of the ScrumMaster is to protect the team from the Product Owner (and the stakeholders that they are representing). Blurring the lines between these two roles mean that there is no one to push back when scope is added last minute, or ensure that the team is sticking to Scrum best practices, despite heavy workloads.

The most common outcomes that we see when these two roles are combined are:

  1. Tons of scope creep. Just, loads of it. All over the place.
  2. Sprint commitments are consistently not met because the team is being asked to do more work than they've agreed they are able to. 
  3. Product Owners assign out work to the team , as they are now "Managing" the team. 
  4. Buggier products –  after all, if I'm a developer trying to get through more work than I've acknowledged I can do, quality is inevitably going to suffer

Overall, not great!!

So what should I do then?

In a perfect world, you should have a single ScrumMaster per team, and Product Owner per product. This means that Product Owners can span multiple teams, if the teams are working from the same product backlog, but ScrumMasters are dedicated to a single team. If you don't have enough resources to commit to this model, in the short term, a ScrumMaster could potentially span more than one agile team - but I would say no more than 2 - after all, one person can only attend so many Scrum ceremonies while also being available to unblock their teams. 

However, the long term success of your Agile transformation means that it's time to start planning to fill those roles. Combining these roles will almost certainly decrease the effectiveness of your move to agile, as your teams are left unprotected and (likely) overworked. 

Looking for more information on Scrum best practices? Check out Sprint Planning - How long should sprints be? or Agile Batch Size: An Ode to Laundry

Topics: blog process scrum workflows project-management agile
2 min read

Jira Tips: Create From Template vs. Create From Shared Configuration

By Katie Thomas on Apr 9, 2021 11:26:00 AM

Blogpost-display-image_Create from template vs. Create from shared configuration (1)

There are a variety of ways to create projects in Jira – whether from a predefined template from Atlassian or from a shared configuration with an existing project. As Jira administrators, this is one of the first questions you'll be faced with when onboarding new teams to the instance. Let's walk through the different strategies, and why we prefer creating from shared configuration. 

Creating from a template

Creating from the Atlassian templates will create a new set of unique schemes to that project - new items in your instance that are not shared with any other project. To create from a template, simply select one of Atlassian's predefined models on the 'Create Project' page. 

The benefit of using these templates is that each of your projects are self-contained, and a model has already been put together by Atlassian. Configuration is not shared with any other projects, even if everything is exactly the same. This means that teams can adjust their workflows, screens, etc. without affecting anyone else. This can be good for teams who don't share any processes with other teams using Jira, and allows project administrators more control over their projects. 

However, for organizations that are looking to scale and/or standardize, this can be a huge headache.

Creating from shared configuration

Using a shared configuration means that you are reusing existing and established configuration items in your instance. Rather than creating new sets of schemes when a project is created, you create based on another project. For example, if you created from shared configuration, both the old and new projects will use the same workflows, screens, and field configurations. Note that they won't share any Jira Service Management specific configuration items, like request types or queues. 

Additionally, once a project shares a configuration with another project, Project administrators can no longer edit the workflows without being Jira admins, which has the added benefit of supporting the goal of standardization and scalability in addition to administrative governance.

There are pros and cons to each of the above, but ultimately, it is recommended that whenever possible, projects should be created from Shared Configuration.

While templates allow teams to have more control over their projects, it does not lend itself to standardization or maintaining a clean Jira instance. Although IT teams often request more options for teams to self-service with Jira project configuration, in the interest of scalability, allowing any user to create their own Jira projects is not a best practice. Jira projects should not be treated as "projects", spun up or spun down on a regular basis: as a best practice projects should be long-lasting and consistent. Additionally, from an administrative perspective, it can be challenging to manage the sheer number of schemes and additional items when trying to troubleshoot issues or maintain the instance.

Looking for expert help with your Jira instance? Contact us, we'd love to help!

Topics: jira atlassian blog administrator best-practices tips
17 min read

The Journey to SSO, Part V: Onboarding and Offboarding Contractors automatically with SAML Single Sign On

By resolution on Apr 7, 2021 9:45:00 AM

Blogpost-display-image_Resolution Blog Series, Pt. 5Praecipio Consulting has partnered with our friends at resolutionan Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security, to bring you a series of blog posts about how to successfully implement single sign-on (SSO) with Atlassian tools. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps.

In the last article of these series on the journey to Atlassian SSO, we followed the steps of ACME, a company with large instances of Jira and Confluence on prem, planning a migration from AD FS to Azure AD.  

In particular, we had a detailed look at: 

  • How users from the Atlassian directories can be seamlessly migrated into Azure AD building a no code integration with User Sync 
  • How users can be mapped between Azure AD and the Atlassian applications even if usernames don’t match 
  • How to connect users from different organizations (ACME and CU.com, a consultancy firm) each with its own Identity Providers, both for authentication and provisioning purposes. 

In order to complete the setup, however, ACME needs to add some restrictions to CU.com users to answer the following questions:  

  • Who at CU.com must have accounts in ACME’s Jira and Confluence? 
  • How long should access be retained? 
  • How should access be revoked? 

Let’s look at how to automate the process for onboarding and offboarding consultants so that these are the answers: 

  • Who should have accounts? Only contractors assigned to active projects. 
  • How long should access be retained? Only for as long as the project is active. 
  • How should access be revoked? Automatically, as soon as the project concludes. 

How to provision only contractors assigned to active projects 

Let’s quickly recap what ACME needs to set up: 

Challenges 

  • Access to ACME’s Atlassian tools should only be granted to consultants who have been assigned to specific projects 
  • Consultants have a quick turnaround. It’s important to give them access quickly and deactivate them as soon as their assignments conclude. 
  • It’s also vital to ensure that consultants only occupy licenses of the Atlassian products while they´re on an active assignment. 

Implementation steps 

The approach has four steps 

  1. The group that gives consultants access will be operated from Contractor’s Okta and filtered in ACME’s User Sync connector. 
  2. Specific project permissions and roles in the Atlassian applications will be managed locally.  This has important implications, as the Okta and local group settings must coexist and not overwrite each other. 
  3. The synchronization between Okta and ACME will be scheduled to run every night (but users will also be updated when they login, eliminating waiting times entirely). 
  4. As a result of the synchronization, consultants who no longer are on active assignments will have both their access and their licenses revoked. 

Here’s the walkthrough: 

1. In the Okta User Sync connector configured in the section above, ACME adds a filter so that only consultants in a specific group are passed and enabled in Jira 
  • Go to User Sync > Azure AD Connector > Edit > Advanced Settings 
  • In Groups mandatory to sync a user, create a new entry group filter user sync
  • Add the group active-acme-jira-project Filter by active project
2. Now we need to tell User Sync which local groups may be added locally in Jira to these contractors. These are the groups that define what projects contractors have access to, and which roles they fall under.  

It's extremely important to add this information! Failing to do so results in removing access  to Jira projects:  

  •  every time the contractor logs in 
  •  with each user sync. 

However, we can protect groups in both contexts from the User Sync connector,  

  • To protect the groups in the connector, we go back to the Advanced Settings and add all the groups used to give permission to Contractor Unlimited consultants in the Keep these Groups field. Note that you can either include every group, or regular expressions, if there are any patterns. keep groups 
3. Now, we will schedule the synchronization at regular intervals to happen every morning at 3am using this cron expression: 0 0 2 ? * *schedule user sync with cron 
4. Finally, we will tell the connector to deactivate contractors who have finished their assignments so that they don't consume any licenses.  
  • In the cleanup behavior dropdown, select disable users. cleanup behavior disable users

What does this last step mean? Consultants will be automatically deactivated in Jira and Confluence following this process: 

  • When an assignment concludes, the consultant is removed from the active-acme-jira-project group 
  • At 3am, the user sync connector runs 
  • The user is removed from the active-acme-jira-project group in Jira, together with any other changes. 
  • As a consequence, the user is deactivated in Jira. 

Bonus trick: With the right SAML setting, if the consultant logs into Jira after they have already been removed from the active group, the login will succeed but will also result in the deactivation. 

We reached our destination! 

Congratulations! You have finished the journey to Atlassian Single Sign-On! Hopefully by this time you are on your way to an implementation that will last for many years to come. 

The sample implementation in the last two articles has offered a selection of very popular options among Atlassian on prem customers. As you have seen, User Synchronization is very often a cornerstone of the implementation, since it permits to use the Identity Provider as a single source of truth to automate user on- and offboarding. At the same time, it’s compatible with multi-IdP setups and access provision to partner organizations. 

However, the example is just that – an example. And it might be very different to what you need to solve. 

How can we help you? 

If you have any doubts or need help with advanced technical issues, there are several next steps. 

  • Our friends at Praecipio Consulting will be happy to help you get up and running. We go way back with a long history of shared implementations.  
  • If you need help configuring the resolution SAML SSO application or the User Sync standalone that can be combined with the Data Center SAML, we provide free screenshare sessions every day. 

Excited to see you there, very soon! 

Topics: atlassian blog optimization practices security collaboration human-resource
6 min read

Leadership required when moving to Cloud and Digital

By Christopher Pepe on Apr 6, 2021 2:32:00 PM

Blogpost-display-image_Leadership required when moving to Cloud and Digital

2020 – What a change!

By now, every technology leader has torn up their plans and strategies as they began a ten-month tactical, fire-fighting effort to move their organization to virtual. In some cases, they were able to assist with changing how people performed their jobs, not just their staff but everyone, in which case they now joined the Digital Age.

CIOs further realized that moving to digital required a move to the cloud, and with it completely new ways of working that took advantage of the internet capabilities and bandwidth. Transferring your data center to a cloud service provider is no more going to cloud than moving your teams to Zoom makes you digital. Cloud requires a different mindset, skillset, and culture on how technology will enable your organization.

2021 is the year CIOs can own the Digital watercooler and change their role to being a Business Technology Officer, integrating software into every aspect of how their company performs tasks and services customers. But first, CIOs must address new ways of hiring, financing, and benefitting from technology, their people, their processes, and their IT. Accelerating the path to digital and cloud is the only way to remain sustainable, competitive, and compliant going forward.

The path has two main steps: funding and the creation of a new operating model

  1. The innovation funding model – iterative investments using VOI as the guide to obtain technology value sustainably

Before you decide on your cloud service provider (CSP) partner and how to migrate your applications, you will need to determine how you fund the migration to enable your organization to do work better, sooner, and safer. You need to separate the process of budgeting – a plan on what resources will be required – and funding, which is the action of providing those resources.

Current budgeting practices limit moving to the cloud and digital by:

  • Asking individuals to annually decide what they will need – and how would you know in this VUCA world?
  • Constricting work to be feature-focused but with no indication of what it will add to customer satisfaction or help staff perform better
  • Adding to technical and cultural debt with no strategy as to paying it off

The central dilemma of every executive board is how to plan, fund, and prioritize technology activities. The current best practice is not to use cost savings as a goal and instead let that be an outcome as you do things differently aided by software. You can prioritize by:

  • Application review
  • Moving from a Project mindset to a Product culture
  • Cost of Delay
  • Creating platforms for products
  • Decide on the WHY of moving to the cloud and digital, on HOW it will help, and WHAT tasks will accomplish your goals
    • Faster time to market
    • Reduction of manual activities
    • Making work more compliant
    • Creating workflows that provide agility and flexibility to meet customer demand, staff requirements, competitive threats, and external issues such as Brexit or COVID19
  • Get your entire workforce and significant suppliers to be part of the planning and allow them to focus and contribute to the proposed strategy

Shift-left! Think as your customer or staff and deeply analyze your applications, products, and services. Which ones are unique to you, and which ones could you source from a SaaS provider? Which ones do you no longer need? Now group the applications into product groups and allow your IT teams to create platforms (see next section) to service these groupings from the cloud.

Many organizations follow McKinsey's advice to create a FinOPS team of cross-functional product business leaders or at least a team comprised of IT, Finance, Risk, and HR. FinOPS will frequently negotiate with stakeholders to allocate resources (money, people, etc.) to continue the innovation or improve services. They will base their decisions on the value of investment towards the company. Frequently repeating and communicating this interaction creates the ability to pivot or stop work quickly, creating new behaviors, and embedding new disciplines on technology use.

FinOPS will rely on analytics, reporting dashboards with real-time data, and automated processes to make decisions visible and linked to business activities. Leaders will have to coach a new culture of moving from CAPEX funding to OPEX. This team will also introduce training to upskill the entire organization on how technology is applied and that by making use of cloud and digital, they will not lose their roles.

Where needed, a partner such as Atlassian and Praecipio Consulting can help you begin this journey of becoming a sustainable business, maximizing resources while reducing costs and making the entire process transparent.

 2. You have the funding model, and now you need the digital cloud operating attitudes, behaviors, and culture to achieve scalability, agility, and continuity

Can you answer these questions?

  • Which business workloads are most important to your company?
  • What are your goals by business line for the next quarter and year?
  • What are your obstacles to these goals?
  • What are your strengths for achieving these goals?

Taking the answers to these questions, review what activities you have planned in your IT department. If a user story or request is not helping solve a problem or achieve a goal, stop it. The FinOps should ask these questions monthly, which will influence resource allocation decisions for technology tasks. Visualizing findings to the company will illustrate the importance of product stories while embedding the capability of pivoting or stopping work, as necessary.

Your operating model will require:

  • A compensation model mapped to the technical activities that are not divisive
  • A full review of your applications mapped to the business lines
  • A map of the way data flows throughout your organization
    • What it entails
    • How it is used
    • Storage, archival, and continuity requirements
    • Security and access obligations
    • Tools that maintain the applications
    • A full list of proposed enhancements
    • Server, network, storage, and operating system supporting them
    • If provided to a specific location, why and how

Using this list, technology leadership needs to help the company move from a project model to a product model. Services must be led by an owner fully accountable for the resources and associated workload, including packaging software into chunks (platforms) that can be used interchangeably throughout the company.

FinOPS and the Product Owners can collaborate on which business domains would benefit most from enhancing the applications used to provide their services. Management can utilize the model to ensure that the right CSP is chosen for each platform. As you mature, you can empower your development teams to decide the best CSP for designing and deploying platforms, be they SaaS or containers. At the beginning of your journey, the strategy should be to communicate the intent and collaborate on the outcomes.

FinOPS also needs to be cloud-savvy. The pricing and SLA options are numerous and complicated. You need to ensure that what you choose is the right decision. You also need to affirm the best path for migrating your application and data to the CSP. Should you port it as it is (provides little benefit), rewrite the application, switch the workload to a SaaS provider? Remember that the avoidance of technical debt, adding to cloud migration's complexity, must be avoided.

There is no shortcut or other option to having Product Owners. You cannot interject a translator or business analyst between what people call the business and your IT. You are all part of the same company, and technology needs to be owned by the business area that provides that service. Further, the people that support these services need to feel that they also own and contribute to these services. This change in attitude and behavior will reduce incidents, increase innovation agility, and enhance your employees' satisfaction, who will feel empowered to see their contribution to the business goals.

The cloud offers the capability of completely altering the way you use technology. Do you need a new instance or environment? Build it, use it, dismantle it, and all within a few minutes at a minimum cost. The software lifecycle of products will be a combination of IaaS, PaaS, and SaaS, depending on the services' platform. Data lakes can share information across the company powered by analytic and reporting tools that would not be accessible to you unless you are quite large.

Security and continuity are other strengths of the cloud as you adopt the framework used by your CSP. Using IAM and Zero-trust security concepts will ensure that you do not become front-page news. Product Owners will have to maintain the governance model required and test it as part of any software change using DevSecOps practices. Scalability, both up and down, is another cloud and digital feature, enabling you to offer new products that can sense and respond to demand.

Are you worried about regulations? Globally FinOPS and Product Owners are finding that regulatory bodies, such as the Bank of England, are moving to the cloud themselves and more than willing to help ensure that their mandates are provisioned accordingly by your CSP. Even if you use a hybrid approach of more than one CSP, which leadership needs to consider, the governance and management models exist via SIAM® to support cloud and digital operating models' best strategies.

The business product operating model is not to become vendor dependent but instead use microservices and containers so that you can migrate your applications as needed to another CSP or a different offering with little effort. This abstraction mode offers the best efficiency in technology enablement. The FinOPS and Product Owners will help to create the loose guardrails to be used by your staff and IT teams as they develop software provisioned products and workloads of your business

In summary

Done correctly, the number of technology instances and applications you currently maintain will decrease but not the requirement of technical skills. Your business flexibility behaviors should be to create agility via innovative use of software, cloud, and digital. Done correctly, the time to market and lower technology costs will be your outcomes. Let all of your organization be involved in the migration strategy as you join the Digital Age, and if you need help, Praecipio Consulting is here for you.

Topics: blog efficiency finance plan saas cloud culture digital-transformation leadership frameworks
3 min read

Jira Workflow Tip: Global Transitions

By Katie Thomas on Apr 5, 2021 11:47:00 AM

Blogpost-display-image_Jira Workflow Tip- Global TransitionsBuilding Jira workflows can be overwhelming. As Atlassian Platinum Solution Partners for over a decade, we at Praecipio Consulting have spent a lot of time building workflows (seriously, A LOT). 

One piece of workflow functionality that we often see either ignored or abused are global transitions. A global transition in Jira is a transition to a workflow status that is able to be triggered regardless of where the issue is in the workflow. These can be very powerful, and we use them in some capacity in almost all of our workflows. However, there are a few things that we put into place to make these transitions easier to use. 

When do I use a global transition?

While these are not appropriate in all situations, we recommend using them in situations where users should be able to move to the status from anywhere else in the workflow. The most common use cases are "On Hold" or "Withdrawn" transitions, where users should be able to place the issue there regardless of where it is in the life cycle. It is understandable that users shy away from global transitions, as without specific configuration they have the potential to be confusing to end users and open up the workflow in ways we may not want. Keep in mind that global transitions should not be overused - using direct transitions allows for processes to be enforced, while global transitions are great options when you need to remove an issue from its normal flow.

With that in mind, we recommend the following configuration on all global transitions:

How to configure a global transition

Transition Properties

Opsbar-sequence is a transition property that allows you to determine the order of all transitions in your workflow. To use it, you assign numbers to each transition, and Jira will numerically order them on the issue view. 

Global transitions generally belong at the end of the list, so we usually give them a high number (100 or  500) so no matter how robust your workflow gets, they're always at the end of the list of available transitions. 

Conditions

Workflow conditions prevent transitions from showing when certain criteria are not met. As a best practice, we always add a condition so the transition is not available from the status it's going to – e.g. if we have a "Withdraw" global transition that goes to Closed, the condition should be "Status != Closed". If this condition isn't present you'll see the global transition available when you're in the status it's going to. 

Post Functions

One of the biggest issues that we see with global transitions is around resolution. Jira resolutions are an extremely valuable tool, and if you don't configure your global transitions correctly, they can affect your data integrity. So, 

If the global transition is moving into a "Done" status (e.g. Closed or Withdrawn), add

  1. A post function that automatically sets the Resolution, OR
  2. A transition screen with resolution that prompts users to enter a resolution before the transition

If the global transition is NOT moving into a "Done" status, add

  1. A post function that clears resolution

With the above configuration, your workflows will be more user friendly while also ensuring that your Jira data stays clean. 

Still need more help with your workflows? Praecipio Consulting is an Atlassian Training Partner with a robust catalog of training, including Workflow help!

Topics: jira blog tips training workflows configuration atlassian-solution-partner
3 min read

Tracking CSAT through Jira Service Management

By Suze Treacy on Apr 1, 2021 5:03:00 PM

Blogpost-display-image_How Jira Service Desk helps track CSATCustomer Satisfaction, or CSAT, is a customer experience metric measuring satisfaction with a product, service or support interaction. The metric is captured through a short simple survey to enable the customer to provide their feedback.

CSAT in Jira Service Management

Did you know that your customer feedback is collected by default within Jira Service Management Projects? This means that when an issue is resolved, the customer receives an email requesting their feedback through a simple question such as "How satisfied were you with our service?". That simple question is editable, and can be defined by your project admin.

Remember, if you're utilizing next-gen projects, site administrator access is required to edit your CSAT survey question

There's a handy Satisfaction report built into Jira Service Management, visible to project administrators and agents. This report displays average customer satisfaction scores, as well as individual scores and comments for the team. You can toggle the report anywhere from the past 48 hours, all the way up to the past year by month!

jira-service-desk-satisfaction-report

It's also possible to configure your own custom report to track satisfaction trends. For example, you may want to see satisfaction by assignee, satisfaction by service request, or even a trend graph to track satisfaction changes over time.

The Pros of CSAT

CSAT, a very popular methodology, offers a quick and easy way to entice customers to give feedback. This then provides a clear metric for you to understand customer expectations, and work to exceed them. With CSAT enabled, your customers will receive a survey every time their request is resolved. This enables you to track customer satisfaction at different stages of their journey with your team, making bottlenecks and areas for improvement clear, with very little effort on your part.

CSAT also offers a fast way to compare yourself to your peers. According to the American Customer Satisfaction Index (ACSI), the average CSAT score across the nation is 76.5% - that's just over 3/4 of your customers reporting a satisfying experience. This figure differs by industry - you may not be too surprised to hear that, in 2019, Internet Service Providers and Subscription Television Services reported low CSAT benchmarks of 62%, while Breweries reported a much more favorable CSAT benchmark of 85%. But remember, while it is useful to be able to compare yourself to your competition, the true value from CSAT comes when you analyze and utilize feedback to drive continuous improvement and better your own customer experience.

Considerations of CSAT

While CSAT is a useful metric to track, there are a few considerations to take into account. The customer who takes the time to fill out their satisfaction is likely one who is happy with the service they received. Customers who are unhappy, or just moderately satisfied, are less likely to complete the survey, which can skew the data. CSAT has also been found to be a poor measure of loyalty - although poor CSAT scores can predict attrition, a high CSAT score has not been found to be a reliable predictor of repeat business. Cultural differences should also be taken into account - different standards and expectations will affect the score that customers are driven to pick, which, in part, can make it difficult to understand true customer satisfaction.

So, CSAT isn't a unicorn which can address all customer concerns with support. However, it does offer a valuable insight; one which should be paired with other tools to track and measure customer satisfaction. At Praecipio Consulting, we can help you make the most out of the benefits of collecting CSAT in Jira Service Management, and use those results along with other anecdotal evidence such as customer comments, number of tickets raised, cadence call discussions, and repeat business, to drive change, improve your customer offerings, and ultimately, reap the rewards!

Topics: jira blog tracking reporting customer-experience jira-service-management
2 min read

Should Stories & Bugs Follow Different Workflows?

By Joseph Lane on Mar 31, 2021 10:07:00 AM

Blogpost-display-image_Should stories and bugs follow different workflows-The short answer: Not really. Stories and bugs are both software development items by different names. As such, the vast majority of activities and controls that we model for a story are applicable to bugs. The key distinction between stories and bugs often comes down to data. Bugs should include Affects Version/sSteps to Recreate, Expected Behavior, and Actual Behavior. How and when we require this data relies on what practices we're observing.

For teams using Kanban practices where there is a Backlog status and a Ready for Development status, the transition to Ready for Development can be used to capture required data based on issue type. In this simple case, we would have two transitions from Backlog, Ready for Dev and Ready for Dev - Bug. For each transition, include a transition-specific screen to capture the appropriate fields.  Example: SDLC Ready for Dev - Bug Transition Screen will include: Affects Version/sSteps to Recreate, Expected Behavior, and Actual Behavior in addition to any other fields needed in both cases. Then, leveraging your workflow conditions allow the Bug issue type to only use the Ready for Dev - Bug transition. All other issue types can default to the Ready for Development transition by explicitly checking that the current issue type is not a bug.

The considerations above work well in workflow cases where you have gated controls as a function of status change. This might apply to teams that include requirements definitions and design efforts within the story or bug life cycle (as might be the case with Waterfall). Additionally, this logical approach allows for workflow reuse which in turn decreases administrative burden and increases process consistency.

Scrum teams view Ready for Development a bit differently. Good Scrum practices dictate that product owners will refine their backlog as items are prioritized upward. Refinement provides all functional details necessary for the scrum team to be able to work the ticket including validation of bug reports and associated details. Once prioritized, the development team will review stories and bugs at the top of the backlog to make sure they understand the requirements. The work is considered Ready for Development at the moment it is accepted in to a sprint.

I hope this explanation helps you avoid unnecessary workflows!

Topics: blog best-practices bugs kanban scrum workflows software-development coding
2 min read

The Impact Installing Apps Can Have on an Atlassian Application

By Chris Hofbauer on Mar 30, 2021 1:30:00 PM

Blogpost-display-image_The impact of apps on an Atlassian applicationPerformance and uptime are crucial when hosting any application. For the Atlassian suite, the use of apps can have a major impact on these hosting aspects. There are many third-party developers as well as Atlassian developed apps that are available to be installed within the Atlassian tech stack. Depending on the app installed, each of these apps will have its own impact on the application and its health. Many apps that may be installed are considered lightweight and the impact would be very minimal; however, there are apps that are resource intensive and can cause significant impact of application performance. The apps that tend to cause the largest impact on application performance are those that allow customization of scripts and manipulation of data within those scripts, especially if these scripts are capable of running on a particular cadence or during certain issue functions. Other app types that are frequently found as the culprit for performance issues are those that return long running database queries. Common impacts from these resource intensive types of apps are high CPU usage and high memory usage. When either of these metrics begin to rise, the server is forced to work harder in order to operate the application, which then can cause the application to face performance degradation, manifested in slow page loads, timeouts, or outages. 

There are best practices you can implement in order to prevent your apps from having an impact on your application's performance. It is highly recommended that you install apps that are supported and developed by a trusted developer. Be sure to also read any documentation and truly understand what the app does before installing. It is extremely important that the apps are always up-to-date as well: apps may have bug fixes in releases that are ahead of yours, and even though you may not be currently facing any issues with your release, it is best to be sure you are on the latest version so that you can prevent any issues that may already be known by the developers. We also recommend that you thoroughly test any app you are considering installing within a non-production environment. Running User Acceptance Testing in a lower environment will allow you to capture any performance issues that may come from the app. Following this approach will strengthen your instance and help prevent any potential impacts your apps can have on your Atlassian applications.

If you run into any trouble with your Atlassian apps, let us know, we'd love to help you make the best of your tools.

Topics: atlassian blog best-practices hosting marketplace-apps
3 min read

Getting the Most From Your Jira Service Management Automations

By Jerry Bolden on Mar 29, 2021 2:45:22 PM

Blogpost-display-image_Getting the most from your JSD automationsHow many times is the number of clicks, fields or screens having to be navigated through used as a reason that work efficiency is low?  It is a main way to discuss lack of efficiency by users of any system.  Well, Jira Service Management has automation built in for just these type of issues. And when leveraged properly, Jira Service Management automation can help drive closing out issues for users as well as ensuring customers feel engaged and informed.  

While time is a focus of most people, as it is the one thing that never stops: being able to use it effectively on things that NEED your attention is key.  Yet, the first hurdle most people have is identifying what actions do not need to be performed by someone.  Automations are things that can be based on inputs by a person, and therefore are always going to be selected the same. For example, filling in a customer based on name or filling out a number field based on selection of priority.  Once these are identified and agreed upon, you can then start to figure out the next phase: how to build the workflow around these to aid in the automation. 

One of the keys to automation is how the workflows are set up in Jira Service Management.  The workflow, when configured with either the correct transition or status or combination thereof, can facilitate the automation. Having a workflow set up to allow for automation based on a specific entry into a status or trigger of transition will helps both agents and administrators of Jira Service Management manage their work more easily.  On the administrative side, the proper set-up will allow for focused automation(s) and ensure they are easy to link without writing out complicated if-this-then-that statements.  On the Agent side of the house, the simple automation UI makes it easier for them to understand their triggers. The Agent can then move on to another issue until the need for follow-up arises. For example, transitioning a request to Pending Customer may pause the SLA, but automating the transition back to In Progress based on a customer comment alerts the Agent they've received their feedback. 

At this point you may be wondering what are some of the items that can be automated in Jira Service Management to ensure efficient flow of information.  Here is a list of some of the ways to use automation for communication:

  • Customer alerts for approval
  • Alerts for review of information
  • Alert them to closure of ticket
  • Alert to lack of response

The first part of the communication is understanding what YOUR customers will need from your team to understand what is happening with their issue.  For the most part, customers want to be appraised of receipt and communication of progress consistently.  With this mindset and communication to customers, you will inevitably save time by eliminating constant customer inquiry on what is going on with their tickets or the "do you need anything from us?" question.  While this can be a bit overwhelming at first, at Praecipio Consulting, this is one fo the many items outlined in our Accelerator for Jira Service Management implementation.  We have gathered best practices from many different implementations to put together a "starter kit" on automated communications. 

The other side of the automation for Jira Service Management is automating information based on user inputs.  By filling in specific fields based on user input or spinning up linked tickets to connect to the current issue, the automation inside of Jira Service Management for tasks that, while not hard, can become tedious, is where the Agents and Customers see the benefit.  Remember, the users main complaint centers on the amount of time they take to get the issue closed and move on to another one.  So while remembering that fields can be adjusted is a good thing, spinning up another issue that is linked is even quicker, thus eliminating the time to move information and instead having it done automatically by selecting the correct workflow transition.  

Overall, the key to getting the most out of the automation in Jira Service Management is first figuring out where you can save time for the users of the system.  Second, determine how to communicate to your customers in an effective manner that can be automated, but also ensuring your customers' satisfaction.  This should be centered on letting them know what is happening with their ticket and drawing them back in to the solution when needed.  As always, anything to remove steps (clicks) from the user is going to not only get more out of Jira Service Management, but also drive a higher usage of the system, correctly, back into your organization. 

We are experts in Jira Service Management, and would love to help you make the most out of this powerful tool.  If you're curious to see if Jira Service Management is a good fit for your organization, drop us a line and one of our experts will get in touch with you.

Topics: jira blog automation workflows jira-service-management
4 min read

How Service Management Capabilities Improve Your Organization’s Employee Onboarding

By Joseph Lane on Mar 26, 2021 9:13:38 AM

Blogpost-display-image_How Service Management Capabilities Improve Your Organization’s Employee OnboardingHave you ever started work at a new organization as an eager new employee, only to find that you don’t have everything needed to “hit the ground running”? It might be that your laptop isn’t ready. Or you have a laptop but you’re missing a critical piece of software (or access to a critical online service). Of course, it’s not only the IT department that can fail to provide a new employee with what they need to be productive from day one. Human resources (HR) might have missed a new employee from the mandatory onboarding training course. Or the facilities team might have failed to arrange building access or to provide them with a suitably equipped place to work.

Alternatively, the issue might not be that these things are repeatedly missing on new employee arrival. Instead, it might be the necessary lead time has an unwanted business impact – that employees can’t start in their new role for two months while the manually-intensive employee onboarding process slowly grinds out what’s needed for them. Or it might be that recruiting managers need to waste their precious time “keeping on top of” all the various departments responsible for ensuring that their new employee can work productively from day one.

To help, this blog explains how Service Management can be used to improve employee onboarding operations and outcomes.

Why employee onboarding is a common issue

None of the above scenarios are ideal – for the new employee, the recruiting manager, and business operations – yet they still happen too frequently when the onboarding process and its many “splinter” sub-processes are manually intensive. It might be that the sheer complexity of all the moving parts, with multiple business functions needing to do “their bit,” causes the issue in terms of the logistics. Or it might be that the immediate lack of urgency for the individual tasks means that they’re a low priority in each business function’s work pipeline, such that some tasks unfortunately “slip through the cracks” when people are bombarded with a continuous flow of higher priorities. Or it might be that the high level of manual effort is the cause of organizational and provisioning mistakes being made.

As to how common onboarding issues are, a commonly-quoted employee onboarding statistic on the Internet – which is sadly from 2017 but still worth pointing to with an age caveat – is that:

Only “12% of employees strongly agree their organization does a great job of onboarding new employees.”

Source: Gallup, State of the American Workplace Report (2017)

Thankfully, Service Management – the use of IT service management (ITSM) principles, best practice capabilities, and technology to improve business function operations, services, experiences, and outcomes – offers a digital-workflow-based onboarding solution that’s commonly one of the first adopted use cases of Service Management within an organization.

Plus, the global pandemic has made employee onboarding more difficult

While onboarding has traditionally been problematic for organizations, the operational impact of the global pandemic has made the potential issues worse. First, because new employees might be remote workers, meaning that any failure to fully enable them on day one is now harder for them to work around. For example, using a spare office “capability” isn’t viable when you aren’t in an office. Second, some of the various business function employees charged with setting up new employees might be home working, which makes it harder for the manually intensive process flows to work across what are now both functional and locational divides.

How Service Management helps with employee onboarding

The ITSM principles, best practice capabilities, and technology employed within Service Management offer a platform for business-wide digital workflows and optimized operations and outcomes. The technology, in particular, helps in terms of making employee onboarding all three of “better, faster, cheaper” through:

  • Workflow automation and service orchestration
  • Service level monitoring, alerting, and notifications
  • New technology-enabled capabilities, such as AI-enabled intelligent automation
  • Self-service portals and other digital channels
  • Knowledge management enablement
  • Dashboards and reporting capabilities

More importantly, Service Management not only helps internal business function operations but also the intra-business-function operations that are a big part of employee onboarding – with the need processed by both HR and the invocation of services from other business functions.

Examples of Service Management at work in employee onboarding

The digital workflows required to get an employee road-ready and productive from their first day of work can be taken back to the initial need for a new employee to fill an existing or new role. The initial workflows can therefore cover all of the following:

  • The line manager notification of the need to recruit (to HR)
  • The approval of the recruitment
  • Job description creation and/or validation
  • The advertising of the role
  • The screening of candidates
  • The interviewing of candidates
  • The selection and notification of the successful candidate

You might argue that this is recruitment rather than onboarding but, in a truly digital environment, this can be an end-to-end workflow such that the successful candidate’s acceptance of the offer, perhaps after personal negotiations, triggers the next set of onboarding steps. These can include:

  • The HR team sourcing and populating the required information in the new employee's HR record
  • The legal team making the appropriate background checks, processing contract paperwork, and ensuring that other legal necessities are met
  • The HR team arranging employee benefits, which could include a company vehicle lease agreement via either the corporate procurement or fleet teams
  • The HR team arranging and maybe delivering the required onboarding training – that covers employee polices, IT usage, finance-related “how-tos,” etc. – plus any other immediate learning needs (physical and/or virtual)
  • The IT team ensuring that the required devices, software, and access permissions for the role are all provisioned in time for the employee’s start date
  • The facilities team sourcing and provisioning the required working environment for office-based working, home working, or both
  • The security or facilities team providing appropriate physical access permissions and means
  • The facilities team providing corporate car parking facilities if warranted

This list isn’t exhaustive, but it’s indicative of how starting the employee onboarding workflow(s) – perhaps via a self-service portal – can trigger the prioritized execution of a wide range of required processes and tasks across multiple business functions using automation and logic. Where the enabling technology not only monitors and manages task progression, but it also integrates with other systems (for record updating, ordering, and provisioning), seeks task-related approvals when needed, provides reminder notifications, and flags up delays and other onboarding issues for appropriate human intervention.

Why wouldn’t your organization want to automate the end-to-end employee onboarding process with digital workflows to save time and costs and to deliver a better employee experience? If you would like to find out more on how Service Management can improve your employee onboarding capabilities, reach out to the Praecipio Consulting team

Topics: blog service-management cost-effective human-resource itsm digital-transformation
25 min read

The Journey to SSO, Part IV: A Killer Implementation of SAML Single Sign On with Jira and Confluence Data Center 

By resolution on Mar 22, 2021 7:33:45 PM

Blogpost-display-image_Resolution Blog Series, Pt. 4Congratulations on reaching the final destination in our very special journey to combine frictionless Atlassian applications with enterprise security! If you haven’t yet, you can have a look at the first article on the symptoms that your company needs a single sign-on solution and the second part on the existing opportunities to implement Identity Providers with your current infrastructure. 

With the goal of identifying realistic solutionsithe third article we reviewed the top SSO requirements for Atlassian Data Center applications:  

  • Are usernames consistent across user directories? 
  • Are there multiple sources of identity? 
  • Do you need to centralize user management on your Identity Provider? 
  • Is there a need to automate user activation and deactivation? 

Then, we mapped possible responses to competing alternatives so that you could tell when Data Center SAML could do the job, and when it would be better to look for an alternative in the Marketplace. Go back to our detailed comparison if you want to dive into the enterprise customization options! 

In the following two articles we will see the four requirements come together in a killer implementation of resolution’s SAML SSO. Let’s follow the steps of ACME Services Ltd! 

ACME is (obviously) an imaginary company based on the hundreds of customer implementations that our support team has guided to completion. 

The starting point  

  1. As part of a larger effort to centralize user management in a central team, the company ACME Services has decided to migrate their Jira and Confluence users from a local Active Directory where users login locally with username and password to Azure AD SAML SSO will be used to connect with the Atlassian applications. 
  2. ACME works for specific technology projects with Contractor Unlimited, a large consulting firmConsultants will need access to ACME’s Jira and Confluence applications with their existing Contractor accounts, hosted in Okta. 
  3. Obviously, only the contractors assigned to projects can have access, which should be revoked as soon as their assignment concludes. This step will be shown in an upcoming article. 

Note: While the scenario includes both Jira and Confluence, we will only cover the implementation in Jira as an example. Keep in mind that the steps are virtually identical for both applications! 

1. The migration from the local AD to Azure AD 

Username transformation with User Sync

Challenges 

  1. Usernames sent from Azure AD are different to the local Atlassian usernames:  first.lastname@acme.com versus first.lastname 
  2. ACME has a central IT department separated from the team of Atlassian admins, and collaboration between both teams usually takes time. To increase the speed of the implementation, it has been decided to transform usernames on the Atlassian application. 
  3. Users from Jira must be first migrated to Azure AD, since it’s a historic instance with thousands of existing tickets. 

Prerequisites 

In this guide we will focus on the critical tips and tricks, but will assume that you already have a basic working configuration that includes: 

  1. Creating a User Sync connector for Azure AD following the Configuration Guide for Azure AD. Do not sync yet! It's best to wait until the implementation is complete. 
  2. SAML SSO configured with your Azure ADHere is the guide 
  3. Having read, understood and followed our guide on how to migrate the Jira/Confluence internal directory to User Sync to retain user history, groups, etc. 

It’s convenient to configure User Sync and SAML SSO in this order so that you can select an existing User Sync connector to provision your users during the SAML SSO setup. 

Important note: Migrations can be messy, so it’s fine to recognize it if you have trouble solving the 3 prerequisites above. Don’t be afraid to ask for help either Praecipio or resolution –we regularly host free screenshare sessions with our customers to get their SAML SSO implementation ready for production! 

Implementation steps 

In this walkthrough, we’ll implement username transformations on both the SAML SSO login process and the User Synchronizations via API. You may we wondering why the transformation must be completed on both sides. We asked one of our engineers, and here's what he said: 

"What happens when the SAML SSO app searches for a user during login and the user is not found? That the login will fail. That's why you need to keep the transformations consistent on both sides. If User Sync creates username “example” stripping the email domain that is stored in Azure AD, and then SAML SSO searches for a user called example@domain.com without stripping the domain before looking it up, it will fail to find the user. 

  1. First, let’s instruct the User Sync Connector to copy user attributes from the local directory into Azure AD whenever a user is createdYou can find this in the advanced settings of the Azure AD connector you have just created. copy behavior
  2. Now we need to configure how usernames will be transformed as they are synchronized into Jira/Confluence from Azure AD
    • Go to Attribute Mapping in the advanced User Sync settings, and click on Edit for the username row Username mapping
  • Now it’s time to add the transformation. Here’s the regex example that would do the job of transforming elon.musk@acme.com into elon.musk: 

Regular expression: ^(.*)@.*$ 

Replacement: $1 email domain stripping

  • As in the example above, you should test with a real user whether the transformation works. 

    3. Now we need to configure the same transformation in SAML too. 
  • Go to Identity Providers User Creation and Update > Attribute mapping and click on Edit for the Name ID / username row username mapping SAML
  • Use the template from the dropdown to strip the email domain no code transformation templates
  • Click apply and save your SAML configuration. no code email domain stripping

Note: The no-code option to strip the email domain from a dropdown will be included in the upcoming release of User Sync, both as a standalone and as a feature of the SAML SSO apps. 

             4. Finally, ACME must change the priority order of the user directories, so that the User Sync dir
ectory is above the local one. To do this, go to User Management> User Directories in the admin section of Jira, and move the Azure AD directory to the top.directory rank 
  1. Connecting users from multiple organizations into the same Jiramulti-IdP setup

After the initial setup, Contractor Unlimited (CU.com) need access to Jira/Confluence. Since they also want to use SSO connected to their Okta, a new UserSync connector is configured for Okta. 

Challenges 

  • Implementing the most appropriate method of combining both Identity Providers (IdPs) 

The final decision is that Okta should be triggered based on the Contractor Unlimited email domain. An alternative would be to show an IdP selection page where users can select whether to log in with Azure AD or with Okta. However, the central identity team at ACME prefers the ACME login to be a more branded experience without a reference to Contractor Unlimited’s Okta. 

Prerequisites 

  • Setup Acme's SAML SSOnow with the Contractor Unlimited's Okta instanceFollow this guide. 
  • Configure a User Sync connector with their OktaFollow this guide. 

If you want to know more about the different IdP selection methods, you can watch this video tutorial. 

Implementation steps 

  1. Go to SAML SSO > IdP Selection 
     IdP Selection tab
  2. In the dropdown, choose select IdP by Email Address     IdP Selection by Email Address
  3. Now, let’s create a new rule item so that CU.com emails are routed to Okta for authentication add email rule
  4. In the rule, we’ll add the domain in the corresponding field. In this case, cu.com becomes cu\.comOkta email rule
  5. Now, let’s test the email of any contractor to check whether the rule is triggered.  test Okta email rule
  6. Let’s now repeat steps 3-5 for acme employees and Azure AD. The result should look something like this: email rules okta azure ad
  7. Finally, ACME decides to tweak the selection page a little bit so that it has the right look and feel
    To do that, they go to the page templates section of the SAML SSO configuration
     Page Templates tab
    and navigate to the IdP Selection By Email Page Template (2nd template) Selection Page Velocity Template
  8. And that’s how it looks like for them by simply changing the font and adding their logo!customized login page 

To be continued: Setting up an automated process to provision and deprovision consultants. 

At this point, CU employees have access to ACME's Atlassian tools. The door is open. But ACME still has to make sure that it the door can be closes so that only CU.com contractors who are actually needed can get in. 

In the next and final article of the series, we’ll look at how to set up an automated process for onboarding and offboarding contractors so that they always have access when they need it, and they immediately lose it when their project is over. Without manual work, and without any bottlenecks. 

Stay tuned!

Topics: blog optimization security resolution identity-management
7 min read

Root Cause Analysis: Leonard, Howard, and the 5 Whys

By Amanda Babb on Mar 10, 2021 9:50:40 AM

Blogpost-display-image_Root Cause Analysis- Leonard, Howard, and the Five WhysDIY or DIE!

For those of you watching from home, I have been on a home improvement journey for quite some time. Applying an Agile mindset to home improvement (or really anything I do) is one of my passions. Even at my most recent Women in Agile meeting, we discussed applying Agile concepts to daily life and feeding these back into building a great resumé. One of the principles of the Agile Manifesto reads: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. We all know this applies to Agile development practices, but it also applies to IT Service Management. Specifically, Incident and Problem Management. For me, it applies to my recent home improvement adventure. 

Strong fences make great neighbors

My neighbor and I spent the better part of a Saturday fixing our mutual fence. You see, I have two dogs: Leonard and Howard.

 IMG_4511IMG_4512

oth are rescues. Leonard is eight and was "free to a good home" while Howard is four and was adopted from my county's animal shelter. Both dogs have been with us since their puppyhood and, as any dog owner will say, they are the BEST. DOGS. EVER. Except when they're not. This was not the first time my neighbor and I had to work on the fence. Observe one of the troublemakers in his natural habitat. 

IMG_4507

This epic saga started in May of last year. I would diligently fix loose boards, prop items against the fence to "patch" holes, and monitor their outdoor activity while I was awake (awake being the key word here: 3am barking and fence-patching sessions are no fun). I supplied my neighbor with fence planks because, well, they're my dogs. We fixed the section above and let the others lapse until a series of shenanigans prompted my neighbor and I to spend our Saturday replacing three additional sections. My neighbor and I became united in making sure my two didn't escape. While my neighbor "doesn't care" that my dogs are in his yard, my (very good) boys take the opportunity to break out of his fence and wander the neighborhood. Howard usually comes back, but Leonard meanders through the streets, swims in pools or the lake, and generally causes mayhem until I can coax him in my car to come home. 

IMG_4508

Not in my back yard...

Before this latest patch, I was determined to find the root cause. Previous to May of last year, this was not a problem. My puppers would frolic in the backyard and simply bark at other dogs in the neighborhood as they walked by. I made sure they were let out several times per day to make sure they were relieved in addition to daily walks. While I was traveling, they were also well-taken care of and monitored. What changed? 

Root cause analysis is, simply put, problem solving. While it is widely used in sciences and engineering, it is also a key element of IT Service Management Incident and Problem Management. When reacting to an incident, the team must restore functionality as quickly as possible. Upon resolution, root cause analysis helps us understand why. It then prompts us to ask, "Is there an action I can take to prevent this from happening again?" Incident Management leads to Problem management and through root cause analysis, we can move from a reactive organization to a proactive organization. 

Of the many techniques of root cause analysis, my favorite is the "Five Whys". It is the simplest technique: ask why until you've identified the root cause. Not like a petulant child, however. Asking the first why should be easy, then continuing to ask well-curated questions based on the previous answer helps you determine the root cause. I applied this to my situation: 

  • Why do I have to replace parts of the fence? 
    Because the dogs are chewing through the fence.
  • Why are the dogs chewing through the fence?
    Because they can access the backyard whenever they need.
  • Why can the dogs access the backyard whenever they need?
    Because we installed a dog door.

IMG_4509

HA! I found it. The root cause. And it didn't even take me all five whys. 

Any root cause analysis technique does not stand alone. There exists a plethora of other techniques. Pareto charts determine that 80 percent of your problems are derived from 20 percent of the causes. An Ishikawa (fishbone) diagram looks at measurement, materials, methods, machines, management, and mother nature. Scatter plots let us look at correlation and causation. Was the dog door the root cause? The existence of a dog door doesn't change the behavior of my boys. Having access to the backyard doesn't make them chew through the fence planks. Did we ask enough questions to actually identify the root cause? Did I also consider a Pareto analysis, an Ishikawa diagram, or a scatter graph to understand why I was constantly chasing my boys through the neighborhood? 

I stopped at three whys: "I have a dog door."

What happens if I keep asking why? 

  • Why did we install a dog door? 
    Because Howard wasn't fully potty trained. 
  • Why wasn't Howard fully potty trained? 
    Because I didn't take the necessary time to train him. 

AHA! My Ishikawa diagram identified "management" as the issue. My Pareto identified the 80 percent as my time to train my puppers. My scatter plot showed the amount of time spent correlated to the amount of dog-induced shenanigans. I would add these to the post, but won't because...reasons. More importantly, I simply kept asking, "Why?" until I identified the root cause. 

Actions speak louder than words

Now that I have a root cause, what is it that I can do to prevent this issue from recurring? When looking at Incident and Problem Management, Atlassian products such Opsgenie and Statuspage can ingest, aggregate, correlate, and trigger the creation of Jira Service Management issues. With Confluence, we can create specific root cause analysis templates to be shared with our customers and stakeholders. However, it's up to our techniques and processes to help us determine the actions we need to take going forward. 

For me and my puppers, it's simple. 

  1. Take at least 30 minutes out of my day for dedicated doggie exercise
  2. Reinforce good behavior while in the yard
  3. Lock the dog door overnight (no more 3AM "let me sing you the song of my people" moments)
  4. Finish replacing the aged planks on the fence

By taking these actions based on my root cause analysis, I should have this solved quickly with redundancies built in. My puppers will be safer and happier, I will have a beautiful new feature of my home, and the three of us will have less stress day-to-day. Using root cause analysis techniques, and Agile mindset, and drawing from IT Problem Management, I can easily solve this problem and any additional ones around my home.

BRB, gotta run and get some more fence planks.

IMG_4510

Topics: blog confluence plan problem statuspage incident-management itsm women-in-technology agile opsgenie jira-service-management health-check
5 min read

Tips for Performing a Successful Root Cause Analysis

By Mary Roper on Mar 5, 2021 10:55:01 AM

Blogpost-display-image_Tips for Performing a Successful Root Cause AnalysisRoot Cause Analysis: The Under-appreciated Hero

When implementing an IT Service Management (ITSM) system, I always look forward to spending time on root cause analysis (RCA). Of course Incident and Problem Management play the central role in ITSM design- it's crucial to give your teams, customers, and systems intuitive ways to communicate when something has gone wrong. However, it is equally important that organizations spend time identifying the key driver of these problems by performing an RCA to prevent them from reoccurring. This is because, at the end of the day, incidents and problems cost your organization money, and a good RCA can help save it. It's this viewpoint that has led me to dub RCA the under-appreciated hero of ITSM and in this post I will share with you the aspects of a successful RCA that can help vanquish problems once and for all. 

It's important to distinguish between Problem Management and Incident Management. In broad strokes: the goal of Problem Management is to get to root cause, and we can understand its goal to be increasing the meantime between failures by determining root cause of one or more incidents thereby addressing with appropriate change to prevent recurrence of the incident; in this sense it's a proactive approach. On the other hand, Incident Management's goal is to reduce the meantime to recovery by responding and resolving fast; its approach is reactive.

What is Root Cause Analysis?

The core function of root cause analysis is to uncover the core reason why a problem occurred. While there are many different tools and approaches to perform an RCA, I've consolidated the key steps into the diagram below: 

Root Cause Analysis Blog Post

  • Define the problem: First, make sure you and your teams align on "What happened?" and are speaking to the same problem.
  • Collect Data: Then, the focus needs to be "How did this happen?" and gathering data around the problem, whether customer testimony or incident reports.
  • Identify Casual Factors: Casual factors also help to answer "How did this happen," and in this step, teams should be guided to identifying fixable causes.
  • Identify the Root Cause: Next, teams should leverage one of the techniques of the RCA process, such as the "Five Whys," Fishbone Diagram, or Fault-Tree Analysis, to drive to the root cause of all the causal factors. 
  • Recommend and Test the Solution: After the root cause has been identified, teams should work to develop a solution that gets recommended to the Executive team for approval before testing can begin. Once approved, the solution should enter a testing phase, where it can be rolled back if not successful. 
  • Implement and Monitor: Once the solution is implemented, teams should continue to monitor it in the production environment to ensure that it is working as expected. This active analysis step is why RCA is depicted as a cycle; if the solution did not resolve the problem, it could be that the problem was a casual factor and the team needs to begin the RCA process again. 

Why Does It Matter?

I've worked with teams who have a well-defined RCA process and others who are just beginning. I reference this diagram when we focus on RCA because it helps to illustrate how simple of a process RCA can be. There aren't rigid guidelines or rules to follow; organizations can adopt their own RCA policies. What many don't realize, especially those who have yet to adopt RCA as a business process, is that it has a big pay-off: cost savings.

Root cause analysis can be a cost saving tool for organizations for a couple of reasons. First, identifying and acting on problems early saves money. The longer a problem goes on the more money it costs the organization, and a properly deployed RCA process is built to help organizations become more proactive rather than reactive. Second, the main goal of the RCA process is to prevent incidents from cropping up again. If the incident does not reoccur, then there won't be downtime or lost production, saving money in the long run.  

How Can I Help My Organization Embrace RCA?

When working with organizations to implement an RCA process, there are several aspects that I help coach my clients on which can help the organization embrace RCA. They are:

  1. Talk about what went well.....and what could have gone better
    1. When the team is starting the RCA process, guide them to start by discussing what happened and framing the problem. Then, go one step further and document what went well. This will provide you data and help to explain what is not the issue or what not to blame. It's equally important to talk about what could have gone better, as this will likely begin the discussion and documentation of your causal factors. 
  2. Make it work for you
    1. In some organizations, "Root Cause Analysis" can be viewed as too formal and intimidating. I've come across some resistance to them due to their structure or even the invitee list. For these reasons, it's important to make sure you're adopting a RCA structure that feels natural for your organization. This could mean:
      1. Being mindful of the attendees, especially if the invitees include senior management and above. Ensure you include the right people in the room at the right time. Your front line team has the most firsthand knowledge of the systems or processes, and you will want them to feel comfortable participating candidly in any discovery meetings. 
      2. Having a neutral party leading the meetings. The leader shouldn't have anything to gain by the results of the RCA process and should be able to maintain a "blame free" atmosphere.
      3. Reframing RCA as something more approachable, such as a "Lessons Learned meeting,"  where the RCA process is still followed, but in a less formal way. Feedback and idea can be gathered via sticky notes and shared on a board so that it is anonymous for example. 
  3. Root causes can only solve one problem
    1. Remember that the main goal of RCA is to avoid future incidents. Teams should not be applying a previous root cause to a current or future problem- if that is the case, then it indicates that rather than identifying the root cause, the team actually identified a casual factor. In these instances, I've coached teams to go back and take their RCA process one step deeper, for example asking another "Why" question if the "Five Whys" is used. 

The goal of Problem Management is to get to root cause. Incident Mgmt goal: reduce the meantime to recovery (by responding and resolving fast); reactive
Problem Mgmt goal: increase the meantime between failures (by determining root cause of one or more incidents thereby addressing with appropriate change to prevent recurrence of the incident); proactive.

Ultimately, where incidents and problems cost your organizations money, RCA saves it. It is for this reason that I think of RCA as an under-appreciated hero of ITSM. While the biggest barrier to accomplishing RCA can be time, putting in the time upfront to accomplish the RCA process will prevent repeat incidents from cropping up, saving your company time and resources in the long run. By implementing a few of these tips, I hope you come to appreciate RCA as I have, and if you have any questions let us know, we'd love to help. 

Topics: blog plan incident-management itsm health-check
3 min read

Three Things No One Tells You About Custom Fields in Jira

By Mary Roper on Mar 4, 2021 12:19:10 PM

Blogpost-display-image_Three Things No One Tells You About Custom FieldsCustom fields can be an over-looked configuration point in Jira, and it's easy to see why: they're easy to create, modify, and make available for your users. Although Jira ships with several system fields, it's inevitable that teams using Jira will reach a point where they require additional fields to input specific information into their issues. But in order to maintain Jira's performance as well as instance hygiene, it's important that Administrators take great care when it comes to custom field creation. That's why today we're sharing with you a few custom field insights we've gleaned over the years. Read on to learn three things no one tells you about custom fields. 

1. Technically, there is no limit to the number of custom fields you can have. BUT...

Custom fields do impact system performance in Jira. Below are some recent results breaking down each configuration item's impact on Jira. Here, we can see that custom fields have an impact on the speed of running a large instance. Your teams may feel this impact in the load time of issue screens. As an admin, one indication can be having a long page of custom fields to scroll through. Additionally, this is often accompanied by longer than usual load time for the custom field Administration page. 

Response Times for Jira Data Sets

To combat this, Jira Administrators should partner with the requestor and other impacted users to determine some guidelines for creating custom fields. For instance, requiring the requestor to submit an example of how they plan to report on the custom field or having the Administrator ensure the custom field can be used in the majority of projects (>=80%). Execution is crucial here: once the guidelines are aligned with management and stakeholders, it's crucial they are followed to prevent your custom field list from unnecessarily growing.

2. There are native alternatives to custom fields.

There are a few usual suspects to look for when reviewing custom fields. Duplicate custom fields ("Additional Comments" as a supplement to the "Comments" system field), variations of custom fields ("Vendor" vs "Vendors"), and department specific custom fields ("Company ABC" vs "Vendor") are a few custom fields that can needlessly drive up your custom field count. To prevent this from happening, Admins can offer their business partners alternative suggestions to creating a custom field by looking at the following:

  1. Utilize an existing custom field that may be more general, but is fit for the purpose to get the most out of what is already in place.
  2. Rather than implementing a custom field, Labels or Components can be used to help organize issues and categorize them for future reporting.
  3. Apply a custom field context to help maximize the potential for picker, select, checkbox, and radio button custom field types. Adding field context enables Administrators to pair different custom field select options or their default values to specific projects or issue types within the same project.

3. You can proactively manage custom fields.

Rather than waiting for custom fields to pile on and create a lag on the instance speed time, proactively scheduling time to scrub your instance for stale custom fields will help Administrators keep on top of their custom field list. This can be a visual check to understand what fields aren't associated to a screen- those are good candidates for removal- or if there are similarly named fields- those can be good candidates for consolidation. More information from Atlassian on how to identify and clean up these fields can be found here.

Ultimately, a well-maintained Jira instance includes a good understanding of custom fields and their overall impact on the system. As your instance grows overtime, the guidelines around custom field development will become all the more important. Bringing these tips to life will help your instance run at top speeds for your users. 

Need help making the best out of your Jira instance? Our experts know Jira inside-out: contact us and we'll get in touch!

Topics: jira blog best-practices optimization standardize configuration bespoke health-check
4 min read

Do testers need to be in sprint planning?

By Marcelo Garza on Mar 3, 2021 11:30:58 AM

Blogpost-display-image_Why do testers need to be in sprint planning-In today’s business environment, high-speed implementation is a must. This applies to all products and services. Suppose you were using an application and got stuck because of a bug: after reporting the bug, you expect the team to fix it as soon as possible. If not, your next move is probably going to be switching to another service.

Software companies want teams working together providing quick and on point solutions to save time and resources, which can only be accomplished by the involvement of all of the teams working on a project. That’s why companies are opting for testing with Agile teams, since it allows for a greater collaboration across teams on a project. 

Agile allows a key collaboration between testing teams and developers which can’t always be accomplished with traditional approaches. It enables testers to share their perspective from the start of the sprint planning; this leads to less bugs during testing and creates a better possibility for sprint delivery dates to be met on time.

Let’s dig a little deeper to understand what this means.

The objective of Agile/sprints/scrum 

Agile methodologies were born as an alternative to traditional software development approaches, like waterfall methodology. 

The following images show the big difference between agile and waterfall methodologies. (Source)

wCXkvvXwQxlBYxwzr_327Yp6iURV_I96Tp1aH_7sZ_o-nN_WgAHqwLsCGZhKraLYAj96nyay0z6VH3GqeZvv7HdSwF1OCGvp

On one hand we can see that the traditional approach (Waterfall) aims to understand user needs and develop a product. After development, testers test the product and report bugs before deployment. The development team then works on them and fixes any errors using the best possible solution. This is progress through phases, one starts only when the previous one ends; this does not create an opportunity for proper feedback or collaboration between testing, developers and users teams.

On the other hand, Agile is mainly focused on performing constant, small deliveries of the product in order for the customer to be able to see how the product advances through the lifecycle. This gives the opportunity for testing to take on a bigger role and to get involved at an early stage of product development and throughout all the lifecycle of the product.

Agile has four important values:

  1. The focus should be more on individuals and interactions instead of processes and tools

  2. Working software is more important than comprehensive documentation

  3. Customer collaboration is more vital than contract negotiation

  4. The process should respond to change rather than follow a plan

Testing in sprint planning: The goal of sprint planning

During sprint planning, the team discusses which stories they will focus on in the upcoming sprint based on aspects like priorities, time frame, feasibility, etc.

The whole team involved in the development of the product should be involved, and if additional expertise on specific backlog tasks is required, then stakeholders can also be part of it.

Sometimes, during this meeting, the testing team can take a secondary role since the main focus tends to be on the development of the stories; this is understandable since it will set the start of the sprint. However, the testing team's' perspective can lead to some serious benefits for developers.

Why testing should be involved

One flaw of working in traditional testing (i.e. Waterfall methodology) is that during the test case design phase, although testers receive the requirements, most of the time they don't get access to the software they will test until it is time to begin the test execution phase.  It is well known that there is usually a big gap between what a requirement specifies and the actual software developed. 

This leads to a huge time investment on the testing side to reach out to both developers and users to define how the product works and how it should work in order to define the correct test scenarios and test cases.

Agile methodologies give testers the opportunity to be involved in the development of the product from the get-go. Testers can be involved in the design of the software by working closely with developers to assess and advise on testability aspects.

An Agile tester should understand the relevance of technical skills. A tester is always prepared to contribute to the technical discussions of the team. Their contribution may extend up to code reviews, user stories grooming, and understanding requirements. The Agile Software Tester gets to work with the developers when they are performing unit testing and share the perspective of testing from a tester's point of view instead of a developer's. The tester can work collaboratively and productively with the product owner and the customer to form acceptance criteria from the sprint planning itself. 

Before any user story is sent for development, the tester and other team members can discuss the complete user story with the team members to find out what the customer wants. Having testers collaborate with developers from the very beginning of sprint planning helps to achieve more accurate estimations and to ensure that everyone has some testing tasks as part of their responsibilities

Great testing teams know they need to become an extension of the customer and end user. Testers need to understand the customer's needs: an Agile tester should be able to describe the feature as well as the customer.

Drop us a line for expert advice on testing and all things Agile, we'd love to help your teams achieve their true potential.

Topics: blog testing tracking collaboration agile software-development
2 min read

Jira Administration: Sys Admin vs Jira Admin vs Project Admin

By Luis Machado on Mar 2, 2021 7:35:43 AM

Blogpost-display-image_Jira Administration- Sys Admin vs. Jira Admin vs. Project Admin2When thinking about Jira administration, or really administration of any software, project, or endeavor, the old idiom “too many cooks in the kitchen” often comes to mind. There’s a fine line between empowering your user base and setting the stage for mass hysteria and confusion within your instance. Fortunately Jira offers some out-of-the-box options to help with setting up boundaries for those users who need more control over the instance but keep them from wreaking too much havoc.

Admins

We’ll start with the bottom, Project Admins. There was a time in ancient Atlasssian historical records when those who were managing projects almost had to be System Admins as well. This was because the permissions needed to make necessary regular changes to the projects these individuals were maintaining required as such. Atlasssian has been improving upon this incrementally as of Jira 7. Since that update it is possible for Project Admins to add Components and Versions to their projects and even as of 7.3, expanded with 7.4, make adjustments to the workflow among other things. So if you’re evaluating your System Admin group and discover that many of the individuals are really only responsible for maintaining specific projects it would behoove you to re-assign those you can to the Project Admin role within the projects they are responsible and get them out of your kitchen.

The next level of administration is the Jira Administrator. Now this is where things can maybe become a bit confusing because the powers granted to that of the Jira Administrator are very similar to that of the System Administrator, but there is a very key distinction which we’ll explore. Those within the Jira Administrators group are not able to make changes related to the server environment or network. This would prevent them from making changes to things such as configuring mail server settings, export/import data to and from XML, configure user directories, as well as many more functions related to the system as a whole. Where this could be useful is delegating out some of the more regular tasks such as creating new projects, creating users, etc. This gives larger organizations a way to separate out the tasks without increasing the risk of potential hazardous changes to the application.

After having covered the last two, the final role should be somewhat obvious. The System Administrator permission is for the Grand Poobah of the Royal Order of Buffalos. This role allows unlimited access to all aspects of the Jira instance. It is recommended that only 1 - 3 people maintain this permission as needed. Again, the idea is to ensure that there is concise and regulated changes being made to the instance as well as accountability. With great power comes great responsibility. When in doubt, opt for the lesser of two evils when granting administrative permissions. You can always bump them up If it’s not serving your needs. Again, the goal is to empower your user base, not have them overpower you.

For question on admins, or anything else Jira, contact us, and one of our Jira experts will get in touch.

Topics: jira atlassian blog administrator best-practices
2 min read

Praecipio Managed Services: The power of a part-time, full-stack Atlassian admin

By Suze Treacy on Feb 18, 2021 12:50:00 PM

Blogpost-display-image_The power of a part-time, full-stack Atlassian admi-1Do you find yourself tasked with administering Atlassian tools on top of the normal duties of your job? Have you ever been faced with an Atlassian question that is out of your wheelhouse? Are you interested in improvement opportunities to configure your instance and architecture to Atlassian best practice standards? If you answered yes to any of these questions, then read on!

With a wide range of Atlassian products available, and a marketplace full of apps to accompany those, it's hard to find admins who specialize in everything. Particularly with the Atlassian toolset being highly configurable, administrators should be able to analyze a request and advise the correct path forward, balancing functionality available to them, with corporate governance and best practice processes. Here at Praecipio Consulting, we have the answer to this unicorn, part-time, full-stack Atlassian admin, through our Managed Services offering.

Atlassian Experts, Best Practice

With over 10 years of Atlassian experience, our team has knowledge across the full stack - whether your question is about hosting considerations, tuning, networking, infrastructure, process-related, Marketplace Apps, or anything else, we can advise and implement functional, practical, industry-specific, best practice processes to maximize efficiencies among your teams. As we are squarely focused on the Atlassian toolset, your IT teams can focus on all of their other tasks, driving productivity and innovation among your team.

Preventative Measures

We're proactive, with bi-monthly cadence calls to discuss your long term goals and objectives, and monthly health checks to ensure your instance is secure, clean, and performing efficiently. We monitor Atlassian vulnerabilities, alerting you of any CVEs affecting your instance, alongside recommendations to mitigate. If you are hosting with us through Cumulus, we monitor your systems too, identifying and resolving issues before they become expensive incidents, and minimizing downtime.

Predictable Cost, Scalable Model

Whether you're utilizing Atlassian Cloud, Server, or Data Center, whether you need 9-5 support, or 24x7, we're always here to help. You dictate your monthly hours cap, enabling Atlassian administrative support at a fraction of the cost of hiring an admin. Even with the cap, it's possible to utilize more hours - managed services is scalable as your business and Atlassian needs grow.

Relationships

As Platinum Enterprise solution partners to Atlassian, we're big on relationships with our clients, Atlassian, and App vendors. When faced with issues, we can be the connection between yourselves and the answer you need, to discover the optimal outcome available for your circumstances. We're vested in your instances being healthy and working for your business: allow us to be a trusted partner in helping your business grow.

Praecipio Managed Services can help with your Atlassian needs, we'd love to talk to you more about our offering! 

Topics: atlassian blog implementation managed-services atlassian-products bespoke
32 min read

The Journey to Atlassian SSO, Part III: 6 essential questions that will define the scope of your Atlassian SSO implementation

By resolution on Feb 17, 2021 9:07:08 PM

Blogpost-display-image_Blog Series-Pt3Praecipio Consulting has partnered with our friends at resolution, an Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security, to bring you a series of blog posts about how to successfully implement single sign-on (SSO) with Atlassian tools. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps. 

In Part 1 and Part 2 of this blog post series, we saw the main symptoms of a password disease that can be healed when applications are secured with single sign-on. We have also taken inventory of the core identity assets involved in an SSO implementation -- including web applications, SSO connectivity, user directories, and opportunities to deploy identity providers. 

In other words, we’ve looked at where you are. It’s now time to look at where you want to go 

A part of that journey involves making a final decision about what will be the home for your user accounts once you move away from Active Directory. Will it be Okta? Azure AD? Or some other vendor? 

Another part of that journey relates to extremely specific requirements that you will need to analyze to make sure that the implementation of single sign-on in Atlassian applications makes all stakeholders happy.  

In this article, we'll spell those requirements out. 

Write them down. These are the most important questions that you will need to answer in full detail before evaluating specific SSO solutions for your Atlassian applications. 

Question 1: Do your Atlassian applications support SSO out of the box? 

blog_sso-pt3We saw this already in the last article, but it’s worth revisiting. 

Your options depend entirely on the type of hosting of your Atlassian products, as you can see in the summary table. If you are on Server, you will plan a migration to either cloud or Data Center in the next couple of years, so that's where you should look. We won't consider SSO solutions for Server applications in this article, although the answer is easy: go to the Atlassian Marketplace. 

If you are on the Atlassian Cloud, your options can also be spelled out with 2 words: Atlassian AccessThe good thing is that you need to search no more. The downside is that Access can be quite expensive, and there is no competition. 

In terms of functionality, Access has everything you can ask for. In fact, it does much more than just SSO, making it a high standard against which other solutions can be measured.  

Audit log, directory syncs, and lifecycle management are components that go beyond the basic SAML SSO functionality and towards a comprehensive Identity and Access Management framework on the Atlassian stack. 

If you're already on a Data Center license or planning a migration in the next couple of years and before the Server End of Life in 2024, then you do have (or will have) SAML SSO out of the box. But the Data Center SSO offering is far away from Access. Which takes us to the next question.  

Question 2Will Native Data Center SAML SSO be enough for you? 

Here are some facts:  

  • Atlassian started providing native SSO capabilities with the SAML protocol in 2019. Originally as a free app, it’s now a preinstalled app for any Data Center customer. 
  • While more functionalities are being added to the SAML based authentication, the app is still behind. You can check their roadmap here. 

What this means is that if you have a simple need and a simple infrastructure, Data Center SAML SSO may work for you. Otherwise, you should look for a commercial alternative. In this article we will look at how common additional requirements are covered by resolution’s SAML SSO apps, with over 7 million users in 58 countries. 

Let’s have a quick overview of what the Data Center SAML SSO can do before we look at how additional requirements can be solved with resolution’s SAML SSO. 

A quick overview of Data Center SAML SSO: 

First, we'll cover the main functional requirements that Data Center will solve. 

At a high level, the Data Center SAML SSO app can: 

what-can-data-center-saml-do

  • Authenticate users into Jira, Confluence, and Bitbucket Data Center on behalf of an Identity Provider. Spoiler alert: you will need exact username matches on both sides (see question 3). 
  • Create users into the Atlassian applications during their first login, without the user being prompted to enter their Atlassian password. This is commonly called Just-in-time provisioning and happens with the information that the Identity Provider sends in the SAML response. 
  • Update the information stored in the local Atlassian directory. This also happens during login exclusively and applies to the group memberships that define user permissions and access. 

There’s no question that these three functions alone are powerfulHowever, a more detailed examination is needed to ensure that you can effectively implement Data Center SSO with your current infrastructure. 

The following two questions are aimed at clearing that part of the dilemma, before we embark on additional functional requirements. 

Question 3Do you have different naming conventions on the Identity Provider and in the local Atlassian directories? 

If the answer is no, then Data Center SAML SSO will accommodate you right away. You can skip to the next question. 

For example, if you are implementing Azure AD the UserPrincipalName attribute will be populated with user emails. If you also have email addresses in the Atlassian username, the match will be perfect. naming-convention-saml-1

But if the answer is yesit will not work. When the usernames don’t match immediately on either side, it will be impossible for the Data Center SAML SSO to identify which user in the Atlassian database is trying to log in. 

This will happen, for example, if instead of the example above, there are full names in the Atlassian usernames. naming-convention-saml-2

This will give you two workarounds: 

  • Modifying all the usernames in your Atlassian applications to align them to the naming conventions in the IdP (Identity Provider). 
  • Modifying usernames on the IdP side to align them with Atlassian (but potentially disrupting the rest of your connected applications). 

But if you want a more elegant solution, you can use the user-mapping and transformation features in resolution’s SAML SSO.  naming-convention-saml-3

In our example, there are two different strategies to create a match with resolution's SAML SSO: 

  1. The UserPrincipalName is mapped with the e-mail attribute, which can be then selected as the attribute that is looked up in the Atlassian database for authenticating users. 
  2. The UserPrincipalName is transformed into the username by simply stripping the email domain.  options-for-saml-resolution

Note: No-code transformation options are quite varied. 

Question 4: Do you have to connect Atlassian applications to multiple identity sources? 

Enterprises rarely have a single, monolithic user directory. For historic and legacy reasons, but also because IT governance models give a lot of autonomy to geographic regions, it is most common to have a few user directories, even from different vendors. 

But even in more centralized approaches, large organizations tend to have separate user directories for different types of users, even if those directories are provided by the same cloud vendor. For example, Jira users and Jira Service Management agents could be stored in different instances of Okta. And it's even more common to separate customers and employees. 

If that is your case, then you won’t be able to use the Data Center SAML SSO app. 

On the contrary, in resolution’s apps, you can setup multiple IdPs and decide when each of them is triggered based on multiple methods: 

  • The user’s decision on a selection page 
  • The user’s email domain 
  • Specific information included in the http request headers 
  • Priority scores (by weight) multiple-identities-saml-1

Note: Atlassian has put this feature on their short-term roadmap, but it’s unknown what will be possible with it and whether the setup will support dynamic IdP selections. 

Question 5: Do you want to centralize user management from your Identity Provider? 

In an enterprise setting, there is not a right or wrong answer to this question. It can make sense to manage users in every application locally. This usually happens when the IT team has the right expertise, and the company is small enough that change requests don't swamp the workload. 

But on a larger scale, a decentralized user management framework can become a major issue.  

What happens when user management is centralized? As employees are promoted, change department, or are assigned to a new project, permissions can be changed directly from the Identity Provider alone. Then, they propagate immediately to all connected applications. 

The technology behind this benefit is a one-way synchronization from the IdP to the connected apps via API. Once set up, the sync will update users’ group membership at regular intervals and therefore automatically modify their access rights. 

Data Center SAML doesn’t have the ability to sync with IdPs, which exists both in Atlassian Access for cloud applications and in resolution’s SAML SSO apps. 

As you can see in the image, resolution’s User Sync functionality provides connectors with most commercial IdPs. Connectors can then be configured so that they align to your group management practices and nomenclature. We will show a practical example of this in the next article. multiple-identities-saml-2

Question 6: Do you want to automate user on- and offboarding? 

User syncs are vital if you want to automate user management throughout the entire lifecycle.  

Besides the satisfaction of having the power to control every detail, few administrators enjoy onboarding new users into every application. They understand it’s a job that needs to be done. They also grasp the urgency of removing access to applications when an employee leaves the company. But sometimes they might be too busy to put that task at the top of their list or to double check that every access was effectively disconnected. 

User syncs can automate the three key on- and offboarding jobs: 

  • When a new employee joins the company, they have immediate access to every application without even having to login for the first time. 
  • When an account is deactivated on the IdP, all accesses are immediately blocked. 
  • Deactivate users temporarily when they don’t access an application like Confluence for specific time (for example, 3 months)  

For the third job, it’s even possible to create a specific connector that takes care of the automatic deactivations. deactivate-users

How to evaluate your answers 

Until now we have looked at the main requirements that you must consider for your SSO implementation. It's vital to have a clear answer to all these questions before making a final decision.  

But now that you have your answers, let’s translate them into realistic options. 

 The table below summarizes your options, mapping combinations of answers with the most suitable SSO solution.  

To find which product we recommend for your use case, simply find the row that contains your answersblog_sso-pt3-2

As you can see, there are three main possibilities: 

  • If you don’t have any of the requirements listed in questions 3 thru 6then Data Center SAML SSO might do the job 
  • If you answered yes to question 3, question 4, or both, then it seems like resolution’s SAML SSO will be your best shot. 
  • If you answered no to 3 and 4 and you still want to automate user management, then you have two alternatives  
  • The simple alternative is to go for a complete product like resolution’s SAML SSO. This will simplify your implementation and the number of touchpoints with support experts. 
  • The cheap alternative is to implement the existing functionality in Data Center for the basic SAML, and resolution's Users and Groups Sync to automate user management. This will make you the advanced features you need to manage users and groups, but at half of the prize of the SAML SSO app. 

Now you know what’s your basic fit.  

Make sure to complete your evaluation going over all your additional requirements as instructed in the next paragraph. 

Continuing your evaluation  

We hope that our attempt at boiling down your implementation project to its essentials was successful and your scenario is realistically captured in the options above.  

But beware! These six questions leave out many details. To quickly cross-reference your feature wish list, we have published a full tour of customization options and how they compare to the Data Center defaults.  

Here’s a high-level preview. blog_sso-pt3-3

But if you want to learn how it workshave a look at the in-depth comparison we have prepared for you. 

spot-the-difference-resolution

What’s Next 

In this article we have reviewed the native SSO capabilities of Atlassian products depending on their hosting type and doubled down on what Data Center SAML SSO can do. We have then focused on three major requirements that cannot be solved with it: username mapping and transformations, multi-IdP setups, and user management automations. Finally, we have taken stock of the combined requirements and presented the best solutions for each of them. 

The next article will conclude the journey to your Atlassian SSO, going even deeper into how to address these requirements with resolution’s SAML Single Sign-On. We will go over the implementation project of an imaginary company that has decided to migrate out of their Active Directory into a cloud Identity Provider. We will identify their challenges, understand the value that the implementation will create for the business, and offer reproducible how-to steps to solve their case. 

We've got you covered with more tips on advancing your journey towards a successful single sign-on for your Atlassian tools with the last installment of our blog series. Stay tuned! 

Topics: blog saas security support collaboration data-center resolution
4 min read

How to Handle Delete Permissions in Jira

By Courtney Pool on Feb 16, 2021 11:47:00 AM

Blogpost-display-image_Why you should restrict who can delete issues in JiraPermissions are one of the most important things to “get right” in Jira. Sure, having the right fields, screens, and workflows are all vital pieces of the puzzle as well, but they can easily be tweaked along the way. While permissions can also be updated as needed, a user who can’t see or edit the issues they need may have their work completely blocked in the meantime.

And then there is the group of permissions so important, so crucial, so absolutely imperative to get right that they earned a blog dedicated solely to them: the delete permissions.

“Well, of course,” you may be thinking, “everybody knows that.” But even if it may seem like common sense to you, it can easily slip through the cracks — it’s happened to others before, and let me tell you, it doesn’t always end well.

You see, delete permissions are so incredibly critical for one reason:

There is no recycling bin in out-of-the-box Jira.

This means that if something is deleted, whether through intent, accident, or malice, it’s gone. Poof. And while the loss of one item may be easy to recover from, the loss of tens, hundreds, or even thousands? Even I can feel the sweat dripping down your spine now.

So, to summarize: Delete permissions? Very important.

Types of Delete Permissions

Amongst these permissions are four groups:

  • Delete Worklogs
  • Delete Comments
  • Delete Attachments
  • Delete Issues

And two types:

  • Delete Own
  • Delete All

Delete Own Permissions

The Delete Own permissions, as the name implies, will allow a user to delete content tied to their specific user account. These permission types exist for the majority of the above-mentioned groups, with the exception of Issues.

Delete Own Worklogs applies to any time that's been tracked to an issue, whether through Jira's native feature or through an app like Tempo Timesheets. As such, it is a fairly innocuous permission and can be assigned to any user with access to a project, unless you have very strict requirements otherwise. It will likely primarily be used for clean-up, and the ripples it can cause are fairly limited.

Delete Own Comments is also often used for clean-up, and again, its area of effect is a bit smaller. However, just because a comment is deleted doesn’t mean that people haven’t already seen it, or even acted upon it. It may be better to instead point users in the direction of comment editing, or have them enter new comments entirely, even if it’s just to say, “Disregard the last.”

Delete Own Attachments is another permission that can be used for tidying. This might be useful were someone to, say, accidentally upload an adorable picture of their dog rather than the spreadsheet they were looking for. It's fairly low impact as well and can likely be given out to any users within your project, especially if you're following the Backup Rule of 3 or similar internally.

Delete All Permissions

Each of the Delete Own permissions has a Delete All counterpart. Delete Issues exists here as well, though the naming convention differs from the other four. Delete All permissions give a user access to delete items associated with any user account. As such, we generally recommend these permissions are limited to only certain groups, such as Project or System Admins.

Delete All Worklogs, Delete All Comments, and Delete All Attachments can each only be performed in a single issue at a time. This barrier helps to protect against mass deletion, but in the interest of data integrity, you’ll still want to restrict who is allowed to perform these actions.

And as for Delete Issues? This will also give a user the ability to delete from within a single issue, but unlike the three mentioned above, this permission gives a user access to Bulk Change as well, which allows actions to be taken across multiple issues at once. As such, ask yourself if you even need to grant this permission at all. Sure, there could feasibly be a time when you need to mass delete issues, but it’s likely to occur so rarely that, should those stars align, the permission can be assigned when needed to system admins and then removed as soon as the job is done. This extra step will save you from being the organization that just lost a year’s worth of tickets.

If something is deleted in Jira, it’s gone forever. This can be a nightmare for many, but especially those in organizations with heavy audit requirements. Rather than leaving yourself open to a very unpleasant surprise, do your team a favor and review your permissions now.

Stop worrying about Jira and make full use of its powerful features!  We can help you implement and optimize your Jira instance, contact us, and one of our experts will be in touch shortly.

Topics: jira atlassian blog best-practices tips configuration verify bespoke
4 min read

Which Atlassian Cloud Tier is Right for My Organization?

By Amanda Babb on Feb 15, 2021 9:33:00 AM

Blogpost-display-image_Which Atlassian Cloud Tier is Right for My Organization--1In October 2020, Atlassian announced End-of-Life for their Server products coming on February 2, 2024. With Atlassian's continued investment in both their Cloud and Data Center hosting options, many organizations are making the switch to Atlassian Cloud. Atlassian is continuing to invest in and expand capabilities in Cloud to support even the largest customers. 

With the announcement, you and your organization have decided to either migrate to Atlassian Cloud or deploy an Atlassian Cloud instance and migrate teams as they're ready. But which Atlassian Cloud tier is best for you? 

The Four Tiers

Most Atlassian Cloud products* are available in four tiers: 

  • Free
  • Standard
  • Premium
  • Enterprise

*Trello and Bitbucket are the exception. More information on these two products later. 

Standard, Premium, and Enterprise tiers can be licensed either monthly or annually and each product can be licensed individually as well. For example, you can license Jira Software Standard monthly at 50 users and Confluence Premium annually at 200 Users. As always, Atlassian provides you the flexibility for your unique implementation. Even if you don't make the right choice the first time, you can always upgrade to Standard, Premium, or Enterprise in addition to adding licenses as needed. Let's take a closer look at each tier. 

The Free Atlassian Cloud Tier

The Free tier is a great way to get started with the Atlassian Cloud products. If you've never used Jira Core, Jira Software, or Confluence, pick a pilot team of less than 10 people (including Administrators). This team can act as your test team to both configure and use the products. You can also add other products such as Bitbucket and Jira Service Management. Bitbucket is free for up to five (5) users and Jira Service Management is free up to three (3) agents. The Free tier also includes limited storage for attachments, out-of-the-box reporting, and (depending on the product) automation. And of course, you can extend functionality through the Atlassian Marketplace. Support for the products is offered via the Atlassian Community: a robust Q&A platform that references Atlassian's product documentation, Marketplace vendor documentation, and general answers to just about every question you can think of about the products. 

Don't forget about Trello! Trello is another way for a team to organize and collaborate on work. Trello is free for up to 10 boards. There is no user count limit. Trello allows teams to create Lists and create and manage Cards to represent their work. The team can create as many Lists and Cards as they'd like on a single board. And with up to 10 free boards, the team can manage multiple work efforts on separate boards based on categories or work types. 

As an example, I have a Free Atlassian Cloud Jira Software and Confluence instance for my household which consists of my parents, a few close friends, and myself. This allows us to plan trips and vacations with one another (all Jira issues are sitting in an On Hold status currently), share pictures, links to events and lodging, and organize decisions as needed. I also have a Trello board that helps me organize my longer-term home improvement projects. Since these items are longer lived without any specific due date, I prefer Trello's flexibility such as creating lists, updating labels, and reprioritizing based on my monthly and annual budgets. 

Standard Versus Premium (and Enterprise)

Each of the three tiers (Standard, Premium, and Enterprise) can accommodate up to 10,000 licensed users. The key difference between the Standard and Premium tiers in Atlassian Cloud is added functionality. While there are a few differences between Premium and Enterprise, they only apply to specific requirements such as data residency, uptime, the inclusion of Atlassian Access, and billing. Let's focus on the key differences between the Standard and Premium tiers. 

First, storage is limited in the Standard tier to 250GB per product. If your organization attaches to or stores a significant number of files in issues or pages, you may hit this limit faster than anticipated. Second, support is offered during local business hours. That usually means 9am to 5pm in your timezone. And third, Standard has no uptime guarantee. If your organization requires 99.9 or 99.95% uptime, you should look at Premium or Enterprise, respectively. 

The Premium tiers for each product offer a significant amount of added functionality with more on the way. For example, Jira Software Premium adds Advanced Roadmaps for Jira and both Jira Software Premium and Confluence Premium allow for native archiving. For larger instances, archiving is an administrative boon as older data is removed from the search index and can only be accessed by a designated group. In addition, the Premium tiers add a significant amount of administration logging and management, adds unlimited storage, and adds 24/7 Premium Support. 

Bitbucket Standard offers unlimited end users, an increase from 5 on the Free tier. The Bitbucket Standard tier also increases Git Large File Storage to 5GB (from 1GB at the Free tier) and Build Minutes increase from 50/month to 2500/month. Bitbucket Premium, however, provides even more Git Large File Storage (up to 10GB), increases build minutes to 3500/month, and adds enforced merge checks and deployment permissions. As of the writing of this document, there is no Enterprise tier for Bitbucket. 

Trello has a slight difference in the names of their tiers. Instead of Standard, Premium, and Enterprise, Trello uses Business Class and Enterprise. As you would expect, Trello Business Class adds unlimited Boards, significant customization opportunities (i.e. backgrounds, custom fields, and templates), and automation runs (though capped at up to 6000 per month). Trello Enterprise includes all the same features as Business Class, increases automation runs to unlimited, and extends administrative capabilities such as organization-wide permissions and enhanced restrictions for things like attachments. 

What should I be asking when trying to decide which one is best for me? 

<Insert typical consultant answer here> It depends! Atlassian has provided transparent pricing for each of their products and each tier of each product as well. Atlassian has also included a handy comparison table for each product for you to quickly see what is included in the tiers. Here are a few additional things to be asking yourself as you start your journey to Cloud. 

  • How many people will need to work in the products? 
  • How are those users managed currently?
  • Do you have any data residency restrictions (e.g. GDPR)? 
  • If you're currently using the Atlassian products, how large are the instances?
  • If you're currently using the Atlassian products, which Apps are you using?

While not an exhaustive list, these questions may help guide you in looking for the right products at the right tier. Of course, Praecipio Consulting has extensive experience with the Atlassian Cloud products and we're here to help! Reach out to us today to let us help you narrow your options. 

Topics: atlassian blog bitbucket implementation teams cloud licensing trello
3 min read

Tips for maintaining a Jira instance

By Chris Hofbauer on Feb 11, 2021 12:07:37 PM

Blogpost-display-image_Tips for maintaining a Jira instanceAtlassian's Jira is a powerful tool to promote best practices of internal processes and provide efficiency to development teams within your organization. The powerful nature of the tool is not only with the features offered by Atlassian but with a vast variety of options at your disposal to customize the instance. These customizations can come from the native features and options available as well as the apps brought to you via the Atlassian Marketplace. While these can all be great in building your Jira instance to get the most out of it, they can also have the potential to be detrimental to the health of the instance and negatively affect your organization's teams. 

Marketplace apps

Following best practices when configuring your instance as well as proper control over the integrations added to your instance is critical. If not properly managed you can experience system issues resulting in downtime due to a number of reasons but most commonly high memory or CPU. While installing apps through the marketplace may seem trivial and rather safe, keep in mind that each install of these apps does modify the database and can also be creating items such as custom fields in your instance. Make sure to properly vet all apps, check the reviews in the marketplace for any reports of impact to the instance. Also, review any documentation for the app to see how the application integrates with your instance. Most importantly it's highly recommended to install any apps in a lower environment (Dev or QA) before installing it in production. Thoroughly testing all new installs will give you the best idea of how the application will impact your instance once installed into production. 

Configuration

In addition to the configuration items created by apps are the ones created manually. Being mindful when adding items such as custom fields, statuses, workflows, etc. can save headaches long-term. It's important to reuse configuration items wherever possible. Having numerous, similar or duplicate, custom fields and statuses will create an administrative burden. Having a large number of these items will also have an impact on exporting issues and projects as well as for instance performance when loading reports, project boards, and dashboards. 

User Management

Proper user management will help to keep licensing costs to a minimum as well as give better control over access to the instance. Use groups wherever possible in permission schemes, boards, and filters. Provide only Jira administrator access and Service Desk agent licenses to those that need it. All users may not need Service Desk agent licenses and since these are billed separately in the instance, assigning all users to the Service Desk group can incur unnecessary charges going forward. Frequent review of active users is important as well. Based on business rules, users who have not logged in for some time (3 to 6 months) may be able to be made inactive. Frequent review of these types of users will also allow you to keep access to a minimum, save licensing counts, and in turn reduce user tier costs.

Stale Data

Review stale or old data is critical in maintaining a Jira instance as well. Instances will begin to grow over time and as your organization and teams grow, so will the ticket count in your instance. The larger the instance size, the high likelihood for performance degradation and instance issues. Analyzing your instance for stale old data is a key step in maintaining a healthy instance. For stale data, take a look at any unresolved tickets as well as any older tickets that have no resolution or that are not in a "Closed" status. You will also want to review any projects that have not had a ticket created in them for a long period of time (we generally recommend 3 to 6 months). After thorough analysis, you will want to close any stale tickets and archive any projects that are deemed to no longer be in use. 

Praecipio Consulting's Managed Services

Praecipio Consulting offers guidance and services to help maintain your Jira instance and provide you with industry best practices. Through years of experience, we at Praecipio have developed a wealth of knowledge in properly configuring and managing Atlassian products that will ensure you get the most out of the product for every use case in your organization. As part of our Managed Services offering, we deploy our proprietary Health Checks. These Health Checks include a thorough review of various aspects of maintaining your instance. Praecipio's Health Checks are split into two main categories: Infrastructure and Process; and include topics such as Licensing, Database Health, Security Vulnerabilities, User Management, Upgrade Readiness, Performance, Process Consolidation, Stale Data, apps/App and Workflows. With these Health Checks and working with Praecipio Consulting's Managed Services, your instance will be in an optimal state for growth and longevity.

Topics: atlassian blog best-practices managed-services optimization health-check
3 min read

Should scrum teams track their time?

By Amanda Babb on Feb 5, 2021 8:03:49 AM

Blogpost-display-image_Should scrum teams track their time-"How many hours are in a Story Point? Pink. Because penguins don't like ice cream." -Amanda Babb in every conversation about hours and story points. 

While I use this example as a cheeky way to say the two methods of estimation (hours and story points) don't coincide, the reality, of course, is much more complex. Business and product teams typically think in terms of dates and schedules. Development and operations teams typically think in terms of level of effort. That's not to say story points and dates do not nor will ever coincide, it's a matter of how to speak each other's language. 

What is a Story Point?

Our Dragon of the West, Christopher Pepe, explained it well in a previous post. Humans are terrible at numbers. That's why we have so many ways to express things without using numbers. For example, I have Big Dog (Leonard) and Tiny Dog (Howard). Tiny is small in comparison to Big Dog. However, at 50 pounds, he's not small compared to, say, a Chihuahua. This is what we call relative estimation in the agile world. This thing is larger or more complex than the other thing over there: it will take a larger level of effort to complete. 

Computers, on the other hand, are wonderful at numbers. It's part of the reason we invented them. In Jira Software, a story point is simply the numerical expression of a relative estimate. When we need to understand the level of effort of more than one thing, we aggregate the relative estimate into a total level of effort. This is known as the commit in a velocity chart. As we complete work, we burn down the level of effort until we understand what's left. At the end of a sprint, we determine whether we met our commit or not. The completion of the work over several sprints determines our velocity. From there, we can reasonably predict the level of effort we can complete during a sprint. 

Why can't a team estimate in hours? 

It's not a matter of can't. At Praecipio Consulting, we've seen many teams succeed well in estimating their level of effort in hours. However, this involved a significant effort to run time studies on routine tasks for the team. In a time study, an outside party will watch a person do a task and time it. Then watch them do it again...and again...and again. Then, the outside party watches another person perform the same task several times. The outside observer will continue with this until they feel they have sufficient data to make a reasonable assumption (read: average) of the time it takes to complete said task. Rinse and repeat for all tasks all personnel complete in a day and through out the week. 

Estimating in hours works well in repetitive work environments. The same tasks must be completed the same (or similarly enough) throughout the day and week. However, when we're thinking about software development, we all know this is rarely the case. What may seem like a simple feature request can become a significant effort when looking at how the new feature interacts with the rest of the services, modules, or products. Yes, we've done something similar before and it took four hours. But what has changed since the last time we implemented something similar? What else have we deployed? Did we change our methods? Are we integrating this with another system? Have the APIs been updated or changed? How many releases have been performed since the last time we did this? 

The shoulds and shouldn'ts of tracking time in Scrum

Why are teams being asked to track time when they estimate and understand level of effort in story points? In a word, Money. Under complex financial and regulatory practices, most businesses report quarterly earnings to regulatory bodies and markets. The best way a business has to gather and report this information is through complex financial systems that aggregate data from inputs across the organization. One of the more critical inputs? Time tracking. So how should we and shouldn't we track time in a scrum team? 

  • You should establish the minimum time guideline such as 15-minute or 30-minute increments
  • You should not expect accuracy down to the minute for a given task
  • You should expect the team(s) to continue to estimate their level of effort in story points
  • You should not make the team switch to hours to estimate their level of effort
  • You should centralize where the team should track time
  • You should not expect the user to log in to multiple tools to track time
  • You should download our Lean Budgets White Paper which details different ways of managing the data and provides a solution in Jira Align
  • You should not expect to implement a fundamental change in financial tracking and reporting across your organization without help

At Praecipio Consulting, we have implemented several solutions to this problem across industries and with all sizes of organizations. For help regarding how your teams can balance time tracking, scrum, and financial reporting, feel free to reach out to us! 

Topics: blog plan process scrum lean-budgets agile
10 min read

The Journey to Atlassian SSO, Part II:  Make an Inventory of Identity Assets

By resolution on Feb 3, 2021 7:56:53 PM

Blogpost-display-image_The journey to Atlassian SSO, part II- Make an Inventory of Identity Assets

Praecipio Consulting has partnered with our friends at resolutionan Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security, to bring you a series of blog posts about how to successfully implement single sign-on (SSO) with Atlassian tools. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps.

In the last article, we offered an overview of the most common pain points that can be felt across an enterprise when no single sign-on (SSO) solution has been implemented – or when it doesn’t extend to important corporate software like Atlassian tools. 

Now you understand that without SSO, end users will stick to bad passwords habits.  

Your Help Center will be flooded with password recovery requests.  

And, to the despair of your security experts, your admins will keep forgetting to deactivate former employees from Jira’s internal directory. 

So, what are you going to do about it? 

Luckily for you, we are laying the grand journey to SSO before your eyes. In this, article we’ll show you the exact steps to take inventory of your existing identity resources. Once the inventory is completed, outlining the implementation project and choosing the SSO vendors should be straightforward. 

The journey to Atlassian SSO, part II- Make an Inventory of Identity Assets-blog

 

Step 1: Take inventory of web applications 

What software do your employees use? Completing an inventory of all the B2B apps used in your organization is easier said than done.  

By some accounts, employees used an average of 191 accounts in 2017; but about half of the workforce uses software that was not distributed to them by their IT department. 

When setting out to complete the list, try a good cop approach. Interview colleagues at different departments and explain the benefits of bringing every possible application under the roof of a unique, centralized login. 

A percentage of these applications will be small SaaS vendors where the head of the department paid with a corporate credit card without requesting a budget approval for it. This type of products have all the chances of becoming Shadow IT: unaccounted for and unknown to the IT department until there’s a problem. 

However, for the purpose of single sign-on you should only be concerned about the apps that are relevant: 

  • They’re used everyday by some roles 
  • They are essential to completing the employee’s job description 
  • They have individual user accounts 
  • They contain sensitive data about the company that you shouldn’t be disclosed 

Atlassian tools like Jira, Confluence or Bitbucket meet all items on the above checklist.   

In case of doubt, a quick scan of data sensitivity should be enough to convince you. Bitbucket is the repository for the company’s software, Jira Software has all the plans about the product’s future features, Jira Service Management contains hundreds of customer conversations, and finally, Confluence is used to organize and disseminate documentation, strategic business plans, and links to confidential assets. 

Step 2: Check which applications support SSO  

Once you know which web applications you need to connect to your SSO solution, you should perform a quick due diligence:  

  • Does the application support SSO natively?  
  • If yes, what protocols can be used to connect it? SAML, OAuth/OIDC, SSH, or even older ones? 
  • If no, are commercial connectors available that you can rely on to do the job? 

Screen Shot 2020-12-05 at 1.09.30 PM

Atlassian on-premise applications, for example, do not support SSO natively. However, there are plenty of alternatives in the Atlassian Marketplace that allow them to connect to IdPs, mainly via SAML. Resolution’s SAML SSO is the most important example. 

In the case of Data Center, there is also a free SAML SSO app by Atlassian that covers a part of the SSO specifications, including authentication and some other aspects of user management. We will go into more details in the following article of this series. 

For each of the applications in your inventory, you will have to ask yourself: Where are the application’s users? Are they stored internally in the application, or are they drawn from a corporate user directory? 

In the case of Atlassian users, there are three main non-SSO options: 

Option 1. Users are stored in Microsoft’s Active Directory 

Screen Shot 2020-12-05 at 1.09.50 PM

Active Directory (AD) is starting to be a legacy technology from the time of Windows 2000, but it’s still the most common starting point for a lot of companies using Windows Servers.  

When your users are stored in AD, they can be synchronized with Atlassian applications using LDAP – then they will be able to use their AD credentials for the Atlassian login. 

Pros: It’s a well-tested option that is natively supported by Atlassian applications. Besides, many customers are already using the AD FS role to integrate with cloud services like Office 365 or Salesforce via SAML. And if they haven’t yet, they can do it for free. 

Cons: LDAP is a very poor choice in remote-first approaches: it usually requires firewalls and VPNs, it scales poorly in terms of performance, and it’s not supported by many cloud Identity Providers.  

Option 2. Users are stored in Jira’s internal directory 

Screen Shot 2020-12-05 at 1.10.18 PM

Jira’s internal directory can also be connected to other Atlassian products like Confluence to be used as the source of users. 

Pros: Users don’t have to be managed in other Atlassian applications. They can be centrally run from Jira’s internal directory. 

Cons: The most important disadvantage is that Atlassian applications will still be siloed against the rest of your tools. Every time you adjust access and permissions for an employee, you will at least have to do it twice: once for Atlassian apps, another for your other directories. 
Additionally, when Jira is down, your entire Atlassian stack will be unavailable. 

Option 3. Users are stored in multiple directories, but centralized with Crowd 

Screen Shot 2020-12-05 at 1.10.40 PM

Many enterprises have multiple on-premises historic instances, each of them with their quirks and their settings. Often times some are Data Center, other are Server. Rather than merging everything, standardizing and consolidating in a mega instance, it’s simpler to just accept the complexity and add Crowd into the mix to centralize user management. 

Pros: Federating multiple Atlassian instances with Crowd is fairly simple, and you can manage users and their permissions across different directories. 

Cons: Crowd is sold as an SSO solution, but that is only true for Atlassian products. If a user logged to Crowd tries to access any non-Atlassian tool where he doesn’t have an open session, he will be prompted to login. Also, Crowd cannot handle SAML responses from an IdP. 

Step 4. Analyze IdP opportunities 

You will need an Identity Provider that can serve as the single source of truth for user identities in all your applications. 

A new IdP can be a significant financial commitment. However, sometimes you can get a top IdP vendor for free because you are already using their technology for other purposes. Let’s have a quick look at the most common scenarios. 

Have a look at resolution’s independent evaluation of the most important IdPs for more details. 

Scenario 1: Microsoft Active Directory 

Screen Shot 2020-12-05 at 1.11.24 PM

Second time we encounter AD in this article, and it’s no coincidence.  

If your administrators are already using Active Directory to manage employee access and permissions to your networks' resources, then you can have SAML-based SSO for free. Simply make use of the AD Federation Services role and start using AD FS as your Identity Provider. 

Scenario 2: Office 365 

Screen Shot 2020-12-05 at 1.11.47 PM

A similar scenario to the above, but with cloud pieces of Microsoft’s game. If your company is on Office 365, then you can get Azure Active Directory for no additional cost.  

If you do so, keep in mind that the free version of AD FS has some important limitations. You can see all the details here, but our summary might be a better use of your time: 

  • You can only use applications in the Azure app catalog (don’t worry too much, we are in the catalog) 
  • Some advanced features like user assignments will only be available on a per user basis 
  • Conditional access policies, including MFA, will not be available at all. 

Scenario 3: GSuite 

  Screen Shot 2020-12-05 at 1.12.11 PM

Everyone has a Gmail account, and thousands of companies, particularly in the US, have adopted Google Workspace (formerly G Suite) for their office applications. If that is your case, then choosing Google’s Cloud Identity is a natural option. 

Cloud Identity Premium is included in the premium tier of Google Workspace with a cost of $25 per user, per month. 

Next Steps 

In this article we have seen how to build a comprehensive inventory of your identity assets that includes sensitive B2B applications, the user directories for your Atlassian users, and common opportunities for adding an IdP vendor from your existing stack. 

For the next article of the series, we will go over the most vital questions that will help you define the scope of your SSO implementation. 

Will a simple setup be enough? Will you connect users coming from different directories? Will you automate user creation and deactivation? These are some of the considerations that will impact your project and what a successful solution will look like.

In the fourth and last article, we’ll inspire SSO project leaders with walkthroughs and actionable examples of advanced implementations.

Stay tuned to for more tips and insights on advancing your journey towards a successful single sign-on for your Atlassian tools!

Topics: blog optimization security resolution identity-management
3 min read

Individuals and Interactions Over Tools Doesn't Mean No Tools

By Morgan Folsom on Feb 1, 2021 11:00:00 AM

Blogpost-display-image_People & Process over tools doesnt mean no tools-1"Individuals and interactions over processes and tools"

It's an important line from the Agile Manifesto – one that establishes that the focus when trying to work in an Agile way is the people. However, we often see this used as a justification to provide inadequate tools to teams. In a well-run Agile organization, you shouldn't have to think about the tools - they should support the work that the team needs to do without getting in the way. Organizations often make the mistake of implementing tools to make teams work in an Agile way. However, tools are in and of themselves not enough - the people and processes behind them are what makes a business go.

However, this doesn’t mean we should ignore the tools we use, opting for whatever’s cheapest, easiest to setup, what we’ve always used, or something that’s “good enough.” Rather, we should take the exact opposite approach and select our tools purposefully, deliberately identifying the tools which best empower employees and promote processes. Because of this, there are two properties of utmost importance when considering a new tool: the tool should allow our team to run with the process that best meets our team’s needs, and the tool should help our team members work better together.

To fit the first of these criteria, the tool should be customizable in a way that allows your team to use your own process. Much of enterprise software today shoehorns teams into predefined configurations and settings which the tool manufacturer thinks are best. This leads to frustration, difficulty in using the tool, and potentially costly transitions to new software. In our experience, every team is at least a little bit different, and even two teams that want to implement the same fundamental process will find they have a few differences they would like reflected in the process. Because those differences tend to arise from the uniqueness of your team, they are important to capture in the tool in order to give your team the tools that best meet your needs.

Further, a good tool will promote communication and collaboration between teammates, inside or outside of the tool. Information tends to get lost when team members do their work in one system but communicate that work in another. For this reason, an ideal product will allow for conversations to take place within the product, ideally directly on the work item those conversations are referring to. Historical conversations should be preserved to allow for a look back on what decisions were made and why, and the tool should have options for how users are notified of important communications. Further down the collaboration path, handoffs should be made simple if not automatic, and any approvals should be doable within the tool. Finally, high-level or detailed status reports should be visible and accessible by any team member who needs or wants to see them.

These two crucial properties are two of the reasons we like Jira. Atlassian’s strategy for a long time has been to develop applications to meet the 80% of needs that are shared by most teams, such as collaboration features, malleable processes, and easy visibility of work, while allowing the remaining 20% of needed functionality to be determined by individual teams and sourced in the Marketplace. The result is a product which delivers good performance out of the box, but can be optimized to meet the needs of any team.

Consider the role that Jira plays in Agile. A large portion of the functionality is built in: Kanban and scrum boards, backlogs, issue types, workflows, and sprint reports. However, the software is customizable to the point that it works equally well for teams that have a quick, simple process with a few issue types and teams which have a complicated process with several rules, handoffs, and types of work. It doesn’t matter to Jira whether your version of Agile requires multiple manager sign-offs before it’s done or if your team lives on the edge, skips QA altogether, and goes straight to production. The point is that the software fits your process, not the other way around. Regardless of process, there are several mechanisms for the team to stay in touch along the way. Every issue can be commented on and allows for @-mentions to draw attention quickly. Email notifications are sent out at times decided by the team, not at arbitrarily defined times decided by the tool’s developers. Progress is simple to see on a board, and every user has access to generate reports or build dashboards to collect information relevant to them, reducing the need for repetitive status reports.

Most organizations will purchase a tool, kick it around for a few years, then junk it because it “doesn’t work right” or “doesn’t make sense for us.” Don’t let this happen to your organization. Pick your tools with care and optimize them for your team. And if you need help, talk with the experts, and get great advice!

Topics: jira blog best-practices tools atlassian-products agile
2 min read

Should my Jira Service Management instance be separate from Jira Software?

By Morgan Folsom on Jan 29, 2021 2:04:24 PM

Blogpost-display-image_Should my Jira Service Desk instance be separate from Jira Software-As companies grow either organically or inorganically, many are faced with the decision of whether they should consolidate or keep their Jira instances separate. Today I'm going to address one specific flavor of this conundrum that I am often asked about, specifically with regards to separate instances of Jira Software and Jira Service Management. Some organizations choose to have separate instances for Jira Service Management and Jira Software, but I am here to tell you that is probably not necessary!

Although Jira Software and Jira Service Management are different products, there is no need to keep them separate. The most efficient companies use both in a single instance, so that teams can collaborate much more easily. As organizations adopt DevOps or start to think about it, one of the first things that is looked at is how IT interacts with the development organization. If these two groups are working in separate Jira instances, collaboration and clear understanding of ownership and handoffs is much more difficult. For example, It is much easier to link an incident that was submitted to the service desk to an associated bug if all of those tickets live in the same instance. While you can link to tickets in other instances, that requires users be licensed in both and have a clear understanding of where the work lives. Working in a single instance removes the need for potential duplicate licenses and ensures teams can communicate clearly. 

Occasionally teams use separate instances due to security considerations. However, in almost all situations your security concerns can be addressed by project permissions, application access, and issue security. There are few cases that Jira's native security features won't account for. 

Finally, let's look at this from a user experience perspective. One of the most prominent complaints that we see as organizations undertake their digital transformations are that users have to keep track of too many tools, a pain that I've felt in my career as well. Trying to remember where to log in for a specific subset of your work can be a headache. If your Jira Service Management and Jira Software instances are separate, they'll have two separate URLs that users have to navigate to. Signing into multiple locations and using different URLs adds an extra step where there need not be one.

Since you've already made the great decision to use both Jira Software and Jira Service Management, you might as well reap the benefits of the easy connection between the two so your teams can focus on what matters, rather than managing their tools. 

Are you looking to merge your Jira instances? Contact us, we know all about how to do that, and would love to help.

Topics: jira atlassian blog optimization tips integration project-management jira-core merge jira-service-management
4 min read

The Journey to Atlassian SSO, Part I - What Are the Signs that it's Time for Single Sign On?

By resolution on Jan 28, 2021 12:54:01 PM

Blogpost-display-image_The Journey to Atlassian SSO, Part 1 - What Are the Signs that its Time for Single Sign On--1Praecipio Consulting has partnered with our friends at resolutionan Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security, to bring you a series of blog posts about how to successfully implement single sign-on (SSO) with Atlassian tools. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps.

journey-to-atlassian-sso-eliminate-friction-blog-1

The password syndrome 

Passwords are the weakest link in tech: we use them every hour, we forget them every day and ask for recovery emails constantly. We replace passwords with less complex alternatives so often that we have assumed it's fine to let them degrade: in the end, the only problem I have to deal with as a user is not gaining access to my accounts. Who would ever want to exploit my accounts? 

Single sign-on kills password fatigue by killing passwords- in plural. But oftentimes, many business stakeholders still view SSO as a nice-to-have supplement that eliminates user friction, failing to recognize the web of security risks that it solves.  

An overview of the symptoms of password fatigue for the different corporate ranks can help technical leaders kickstart the journey to onboard a suitable SSO solution. Having a solid case can also make them more persuasive security evangelists.  

Pain points for users 

Many employees will just reuse the same memorable password in order to maintain access to their accounts. Many others will not access certain applications if an unwanted login blocks their way. User fatigue will then result in low tech adoption for applications that are not central to the employee's job description, with compliance and open enrollment software as two front runners in this race to oblivion.  

When business processes are not followed, information will be lost or remain siloed, and business productivity and collaboration will suffer. Employees whose performance relies on the compliance and open enrollment software everybody has dropped will have a very hard time completing their job. Many companies using Jira Core to support these types of processes fail to recognize the threat that login friction poses to the general adoption of the mandated tool. 

Pain points for security officers 

In the long run, poor password hygiene results in infections. How long until someone loses the paper notebook where her passwords are written? How long until it's found by the wrong hands on a plane or at a workshop outside the office? 

Security officers have many reasons to panic in a culture of security last with no SSO. Besides the password leaks, outdated user accounts can easily expose classified information to roles that lack the required clearance. Or disgruntled employees may discover they can still access the company's code repository on Bitbucket. 

Pain points for administrators 

A very revealing symptom that a company is in urgent need of an SSO solution is buried in the recurring tasks of system administrators. Discontinuing accounts of leavers in a timely manner or adjusting the permissions of an employee who has moved to a different department are extremely difficult tasks without a centralized user management function. 

Besides eating up the available seats in your licenses, lacking an automated method for provisioning users into applications has serious repercussions. For starters, new users will have to wait in a queue until an administrator is available. 

Administrators must also enforce security measures when credentials are compromised, often at the cost of major productivity setbacks. Have you ever had to set new credentials for all your accounts? Yes, it feels pretty much like your first day at the job again. 

Pain points for Help Desks 

Password frustration is a more visible phenomenon on the user side. But make the experiment of asking a Help Desk agent working at a large corporation without SSO in place how many password recovery calls he must attend every day. And how that work ranks in his important vs urgent matrix. 

High volumes of password replacement calls are among the key factors associated with low productivity of Help Desks. In ITIL jargon, they are technically requests, but in practice they're just a manifestation of the recurring problem: the dire need for an SSO. With an SSO in place, password recovery requests will be rare. They will still happen, particularly if you still have a password expiration policy (and there's a reason why Microsoft has abandoned that recommendation). But ownership will be much more effective, and you will have a maximum of 1 request per user. 

A single source of truth 

As much as single sign-on solves the password management problem, it's important to remind stakeholders that it also has the important benefit of centralizing employee accounts for all mandated enterprise software.  Admittedly, one immediate effect of that centralization is that users will have only one master key to all their applications. But the other side of the story is even more important: single sign-on connects user management for individual applications to a single source of truth, maintaining tight enforcement over access rights that eliminates the need for IT heroics. 

The good news is that many enterprises already have the necessary infrastructure in place to easily set up an SSO solution. Customers of Office 365, for example, can enable their central directory on Azure AD for free. A continuation to this article will offer a practical overview of your available options. It will detail what kind of identity resources are necessary to set up a single sign-on, what are the most common configurations of centralized user directories for Atlassian applications, and what tricks can get you a leading Identity Provider at an affordable price.

Topics: blog sign standardize security verify resolution
3 min read

Microaggressions in the Workplace

By Rebecca Schwartz on Jan 22, 2021 3:42:46 PM

Blogpost-display-image_ SJ Blog- Microaggressions in the workplaceThroughout the course of this year, we've discussed implicit bias on our internal Social Justice team at Praecipio Consulting. Implicit biases are sub-conscious thoughts or stereotypes we have about a specific group of people based on their race, ethnicity, sexuality, age, appearance, etc. The feelings and thoughts we form based on these biases are ones we may not intentionally form or are aware of, but everyone has them. The team looked further into how these implicit biases affect the workplace and discovered they correlate directly to microaggressions. As we begin a new year, the Praecipio Consulting team is looking for ways to better our company culture, as well as ourselves personally, so addressing microaggressions and their effects on the workplace seemed like a great way to do this as a group, as well as individuals.

What are microaggressions?

According to Derald Wing Sue, microaggressions are the everyday slights, indignities, put-downs, and insults that members of marginalized groups experience in their day-to-day interactions with individuals who are often unaware that they have engaged in an offensive or demeaning way. The perpetrator of the aggression typically does not realize what they said or did toward the victim is offensive, which makes microaggressions even harder to call out or recognize. There are three types of microaggressions: microassaults, microinsults, and microinvalidations.

Three types of microaggressions

First, we have microsassaults. Microassaults are more obvious and are usually purposeful. They are often violent and directly target a victim. In the workplace, an example would be if a male coworker gropes a female coworker and plays it off as a joke.

Next are microinsults. Microinsults are the most common type of microaggressions. They are a bit more subtle and unconscious, especially compared to microassaults. They disrespect or demean another person, even if the perpetrator "meant it as a compliment." In the workplace, an example would be if a non-white co-worker was giving a presentation and an employee commented on how articulate the presenter is. 

Microinvalidations are very similar to gaslighting another person. They are often subtle and unconscious. Microinvalidations cancel the thoughts, feelings, and experiences of marginalized individuals. In the workplace, an example is when an LGBTQ+ employee confides in a straight employee about a microaggression they received, and the straight employee tells them they're overreacting. 

Microaggressions and the workplace

Although at the moment, a microaggression may feel like a joke or a harmless action to the person committing them, they have a large impact on the receiver, especially if the microaggressions occur repeatedly over a long period of time. Psychologists often compare them to death by a thousand cuts. Because of the manner of microaggressions, they are often not reported by employees. It’s important to understand what they are and how they affect others to ensure a safe and inclusive company culture. The first step in addressing microaggressions is to recognize when a microaggression has occurred and what message it may be sending. Think about your actions and your words: you may have positive intentions with your behaviors, but think about the impact they have on others. 

At Praecipio Consulting, the Social Justice team has compiled a Resource Library that the company can use to learn about a range of topics, a few geared toward microaggressions and how we can work to eliminate them from our environments. Below is a list of helpful resources around microaggressions that we have in our library. 

If you have read, watched, or listened to any of these resources, we'd love to hear your thoughts, and if you have any recommendations for other resources we should add to our library to learn more about microaggressions, let us know!

Topics: blog do-good social-justice social-responsibility
3 min read

Last call for new Server Licenses: What you need to do NOW...

By Brian Nye on Jan 20, 2021 10:49:41 AM

Blogpost-display-image_Last call for new Server Licenses, what you need to do nowAtlassian announced last year that its Server products will be sailing off into the sunset in three years (2024) but the first big date is upon us... February 2, 2021. On this date, the following will happen:

What this means is that you will no longer be able to purchase new licenses for Server-based Atlassian products. You may experience a price increase on your Server-based products, Atlassian has outlined them in their Future Server Pricing FAQ. For new instances of the Atlassian stack on or after Feb 2, 2021, you will need to implement either the cloud or Server versions. If you are currently running Server, you have time, however, you need to start thinking about what your long term plans are for your Atlassian technology stack.

So what do you need to do now?

The answer is simple, start to plan for the future. Most of you will not need to take any immediate action as Server is not "going away" and business will proceed as usual. But over the past seven years, I've seen a lot of Atlassian instances and some of you have some work do because what you've done will make it hard to go to Datacenter or Cloud. "Why will it be difficult?" you may ask...well some instances would be a good candidate for "Hoarders, Atlassian edition". Some of you have not seen an app you didn't like while others want to keep every issue and page ever created. Sprinkle in bad practices and untrained administrators, you've got a mess that needs to be untangled. 

Three years will go by quickly. Many of you work for companies that take a long time to make decisions and then want miracles to happen in the 11th hour. My recommendation is you start planning now to figure out what is the best solution for you. With that being said, you should start by looking at the following areas:

Apps: Not all apps are created equal. Many were built with Server in mind and some do not have an equivalent in Cloud or Datacenter. You should start evaluating what this will mean for your user community if the app goes away or the functionality changes. 

Data: Moving a ton of data is never easy, especially if you're moving from Server to Cloud (which most will). Data comes in the form of issues and pages, as well as configurations. You should be questioning if you need to bring it all over. You should also evaluate if you want to bring over all the crud that's associated with the data (poor configuration setups like custom fields and statuses).

Customizations: Outside of apps, many have customized templates and files to control UI behaviors. These are usually not able to be replicated in Cloud or will break the multi-node Datacenter infrastructure.

Every instance is different from the rest and while those are generally the first places to start on your journey. Plus you must factor in the cost of operation with the security stance of your company. There is a lot to think through and this is why you must not wait until 2024 to start down this journey.

Here are the remaining dates that you should be aware of:

  • Feb 2, 2022: End of Server upgrades and downgrades
  • Feb 2, 2023: End of new App sales for existing Server licenses
  • Feb 2, 2024: End of Server support

Need help or don't have time to think about this? Praecipio Consulting can help guide you through this transition by helping you plan and perform the migration when the time is right for you. Our consultants can evaluate your current set-up and provide a path forward customized to your unique situation. 

Topics: atlassian blog plan server licensing
4 min read

What's the deal with Atlassian's Jira Cloud migration tool?

By Bradley Ode on Jan 14, 2021 10:45:00 AM

Blogpost-display-image_Whats the deal with Atlassians Jira Cloud migration tool (1)Atlassian's Jira Cloud is more popular than ever as companies continue to see the benefits in cloud-based technologies. For those of you already on server, the latest announcement from Atlassian might prompt you get to a head start on looking at migration options. I had the opportunity to work with Atlassian's Jira Cloud Migration Assistant (JMCA) earlier this year and now is a more pertinent time than ever to share those findings. 

What is the Jira Cloud Migration Assistant?

Jira Cloud Migration Assistant is an add-on introduced by Atlassian earlier in 2020 to help clients migrate their data from Server to Cloud. It is a migration assistant and should be viewed as such. There are many things that JCMA does well, but it does come with it's limitations and should not be viewed as a one-and-done solution for most organizations. With that being said, companies with small Jira Server footprint will get the most use out of the tool.

At a glance

What can it do?

  • Jira Software and Jira Core Project data
    • Details
    • Roles
    • Screens and Schemes
    • Workflows
      • Most native workflow functions
  • Issue data
    • Most custom fields
    • Issue history
    • Rank
    • Worklogs
    • Attachments
    • Comments
  • Boards linked to projects being migrated
  • Active users and groups from User Directories

What are the limitations?

  • Jira Service Management- no Jira Service Management data can be brought over with JCMA at the time of publishing
  • Third party app data
  • User Avatars/Timezones/Passwords
    • Passwords will need to be reset after migrating unless the client is using SSO
  • Global configuration items
    • Since JCMA operates at the project level no system settings will be brought over
  • Certain custom fields
    • Single and Multi-version picker
    • URL
    • Select List (cascading)
    • Select List (multiple choice)
    • Project picker
  • Certain workflow functions
    • Validator: required field, field changed
    • Condition: user in group, in project role, field value, subtask blocking
    • Post Function: clear field value, update custom field, copy value from other field, delegating
  • Links to entities that are not migrated

I don't have Jira Service Management, but what's this you say about app data?

Unfortunately, Marketplace Apps will need to be handled on a case-by-case basis. The JCMA tool provides a mechanism for assessing which apps can be migrated from server to cloud, but does not migrate the data via the tool itself. Instead, the tool will scan your instance and provide links or paths (i.e. instructions) to external documentation if it exists.

These paths can be a bit confusing as you are taken to the individual app vendors' sites. These can be radically different from app to app. In our case, many apps did not have a path forward and, instead, we are prompted to contact the vendor.

What about users?

JCMA will bring over all active users and groups on each migration initiation (which may or may not be what you want). You have the option of giving the users product access before running the migration, but in my opinion, it is best to wait until after the migration in case things go awry. After running the migration, the users will need to be invited to the Cloud site.

Should I use JCMA? Or perhaps another method like site import?

When the instance to be migrated is small, well managed, and with little complexity, the JCMA tool will handle your data with finesse. The JCMA tool is also more useful in merges when you are trying to merge a small, relatively simple Jira Software Server instance with a larger cloud instance. This is due to the fact that the JCMA tool itself is very project-centric. However, an abundance of app data, complex workflows, and many external integrations can be some of the things that might stop an organization from using this tool. If you are in any way unsure, contact us -- we've got your back.

My Experience

Overall, I found the JCMA tool to be a simple and effective way to transfer small amounts of project data to a cloud instance. It does what it says it will do, with only minor hiccups along the way. My experience a few months back is likely going to be different with yours as Atlassian continues to invest heavily in Cloud offerings. As always, do your own reading and don't be afraid to ask for help.

Further Reading

Topics: jira blog migrations cloud atlassian-products
3 min read

How do I migrate to Cloud if my apps aren't compatible?

By Jerry Bolden on Dec 23, 2020 1:06:11 PM

Blogpost-display-image_How do I migrate to Cloud if my apps arent compatible-

How many people are ready to move to the new hotness: Atlassian Cloud?  While this is becoming a more focused platform for Atlassian, there are some things that each company/team will need to think about as they move to the cloud:

1. What do I do if my current Server/DC apps are not compatible? 

2. What do I need to understand about my current set up within my workflows?

Apps are used to upgrade the out-of-the-box abilities of Jira, Confluence, and Bitbucket and most people not only become reliant on the apps, but may not even know they're using the apps for their day-to-day work. While there are quite a few apps operating on all three platforms (Cloud, Data Center and Server), some apps may not be available for all three platforms. For example, an app may be supported for Cloud-only or Data Center only.

While trying to migrate to Cloud, you need to understand which Apps are also compatible in Cloud and which ones are not. You can navigate to Atlassian Marketplace and set your first filter for Cloud.  Then, simply search the App name and the marketplace will do a good job giving you other options that have some of the same features as your current Data Center/Server app. Look through the recommendations and compare the current features you use with some of the recommended apps features.  The best thing is to also download a trial version of those apps in Cloud, but also if you are still on Data Center/Server, see if they have an app trial for those platforms as well.  

The other side of this will be having apps that exist on Cloud as well as on Data Center/Server but may affect your workflows.  For example, Automation has come included within the cloud, but JSU Automation Suite for Jira Workflows exists as a separate app on Data Center/Server.  While this app is now integrated into the Cloud,  when importing the data, workflows, etc. during the migration, you currently cannot use the Atlassian Cloud Migration tool and the links to the automation can fail. 

Reach out to those specific App vendors for support and open a ticket to understand what the migration path could be from Data Center/Server to Cloud. For example, In JSU's case, you have to redo all the affected workflows and their validators, conditions and post functions.  While some applications will be compatible, others will either require a little manual reconfiguration or finding ones similar in features to your current Apps.

Migrating to Atlassian Cloud is becoming more and more seamless as Atlassian continues to focus on the Cloud platform. But where apps are concerned, you will need to either find apps that already have a Cloud version or look for the Developer to review similar options and features. 

If you need guidance with your Atlassian Cloud migration, Praecipio Consulting is here to help! Contact us and one of our specialists will contact you shortly, and in the meantime, here are some helpful resources that you can start with

Topics: atlassian blog migrations cloud atlassian-solution-partner marketplace-apps
4 min read

How is Confluence Cloud different from Server/Datacenter?

By Morgan Folsom on Dec 18, 2020 1:06:00 PM

Blogpost-display-image_How is Confluence Cloud different from Server-Datacenter-

If you've recently moved from a Confluence instance that was hosted by your organization to one on Atlassian's cloud, you may be noticing some differences in how the tools work! The experience is quite different, and we know that can be a bit overwhelming if you've spent a lot of time getting used to the server UI. The change will require some adjustments, so we've provided a quick overview of things to keep an eye out for so you can get back to expertly collaborating with your team.

Navigation

Let's start with getting to Confluence! You can of course access your instance via the new link provided by your IT team https://yourcompany.atlassian.net. But, if you're looking to get to Confluence from your linked Jira instance, the application switcher looks a little different. The application switcher now lives in the grid icon(Screen Shot 2020-04-17 at 11.09.36 AM). Select that and you can navigate to any linked applications, including Confluence. 

Creating pages

Page creation looks different in the new view - you'll notice that there is now only one option to create pages, the Create button. This functionality has made it a lot more intuitive to create pages from templates! In Server, users need to consciously make the decision to create from a template (selecting the '...') or a blank page. Now when creating pages available templates will appear on the right, allowing you to filter and search through templates. With this new navigation you can even see previews of the templates before you select them. 

Keyboard shortcuts

This is the change that threw me off the most when switching between the products, because I rely very heavily on shortcuts! Here are three that I use a lot that have changed:

Action
Server/Datacenter
Cloud
Insert a Macro { /
Start an ordered list 1. 
Change header level Cmd/Ctrl + 1/2/3... # / ## / ###

 

To see a full list of shortcuts, you can select Cmd/Ctrl + Space while editing a page and a dialog will appear and display all of your options. 

Page layouts

The experience in Confluence Cloud is more mobile friendly, so pages are more narrow by default than previously. However, you can still expand your pages to span full screen if you've got a lot of content. Opening the page layout options hasn't changed - you select the icon in the editor. However, the page layout editing experience has changed so you can work on it within the body of the page, instead of at the top.

Screen Shot 2020-04-17 at 11.24.48 AM

You'll notice the arrows pointing out - those allow you to span full screen for either the entire page (top) or the specific section (bottom). The same options to edit layouts are available but you can see them in-line instead, which makes for easier navigation while working them into your pages. 

Panels

The Panel macro is one of my favorites - I like the ability to break the page up visually, and they are a great way to do that. Atlassian has revamped how panels work in Cloud so that instead of having separate macros for different types of panels: Panel, Info, Warning, Note, Success, etc. they are all just one macro, and you can switch the coloring as needed by selecting different icons. 

Screen Shot 2020-04-17 at 11.28.05 AM

Macros while viewing a page

The last change I want to highlight is perhaps my favorite. When editing Confluence previously, you might've noticed that when you insert macros, many of them appear different while editing vs. viewing the page. In cloud, we now see that macros like the Jira Issues macro pictured below actually shows the content while editing now. 

Screen Shot 2020-04-17 at 11.31.30 AM

Switching between tools or views can be tough, but with Atlassian's cloud platform you'll see a lot of changes that make the user experience run more smoothly. Now you've seen some of the changes, you're ready to hit the ground running!

Thinking about switching to Cloud? Contact us to talk about how we can help!

Topics: jira atlassian blog migrations server cloud data-center confluence-cloud
5 min read

How Your SaaS Provider Contributes to the Customer Experience

By Christopher Pepe on Dec 16, 2020 1:44:00 PM

Blogpost-display-image_SaaS Requires Delightful Customer Service

SaaS Providers & Customer Service

The year 2020 has forced organizations to consider how they service customers and enable staff to do their work by having them reconsider the benefits and value of their current technology practices. 

Look at the fun visual below: most businesses use a combination of managing their own data centers and software or by using cloud-based facilities. Software as a Service (SaaS) allows a provider to perform a service on their technology. You pay for the provider's expertise and convenience to maintain the servers, networks, security, software, and the upgrades or changes. No more cooking as you always eat out!

pizza as a service

SaaS providers now perform almost any main business functions: HR, Accounting, Sales, Finance, Communication, Coding, Marketing, Websites, and more. The cost benefits dazzle the eyes but consider that when you allow someone else to perform a business function that the customer still sees you.

At a restaurant, if the service is terrible, you never return to that restaurant. In the eyes of your customer – you are the restaurant! Therefore, how you interrogate the provider before deciding to use them and how you monitor and respond afterward is paramount to your business's success.

The rest of this article offers insights and tips to ensure that your relationship with a SaaS provider does not ruin the relationships with your staff and customers.

Training

  • Transitioning to SaaS changes your workflow – how will you be trained, and what documentation will you receive?
  • Are any other vendors impacted, which will also require training, and who pays for this?
  • Your products will require integration with the SaaS provider, so how will you train them?
  • How will changes to the SaaS provider service be addressed?
  • Do customers require new FAQs?
  • If someone has a question, do they go to an internal team, the service desk, or the SaaS provider?

Know Your User

Before you move a service to SaaS, you need to define the user of that service. Deep dive:

  • What is the user of this service in terms of ability, technology, the reason to use the service, expected benefits from their view, and dislikes?
  • What is the journey of that user as they use the service? Where will there be issues?
  • How can the SaaS provider mitigate these issues? How will you know that problems are occurring?
  • What messages can you provide the user to help them on their journey or if they get stuck? Can the message be personalized?
  • What can you automate for the users, such as renewals, reminders, or upsells, or anything to make the journey more enjoyable?
  • Can users form part of your test team to improve the journey's flow or provide feedback on proposed changes before go-live or to develop future releases?

IT Service Management

ITSM is the practice of allowing technology to benefit someone. It is a required business set of processes that engender better, faster, safer technology applications that deliver value. Initially the IT domain, Enterprise Service Management (ESM), is now commonplace as organizations take advantage of the cloud, SaaS, or move to digital products.

Not long ago, more technology services supported a single department, with only Finance reaching out across all areas. Now technology services are so integrated into your work that a change in one place impacts the entire organization and could disrupt your customers. ITSM processes and tools can help by:

  • Logging all incidents or requests, no matter who sees them, the SaaS provider or your teams.
  • Merging the incident and request data for performance reporting, improvement actions and decision-making. Daily integration is best practice.
  • Helping to determine how long it takes for incidents or requests to be resolved or some sort of communication is issued to the customer? Lack of service will increase customer churn, and they might disparage you in social media.
  • Creating alerts for monitored services.
  • Obtaining historical information to ensure that improvements are of value.
  • Enabling user support via live chat, AI chat, easy to find widgets, easy to read FAQs, and reporting on these interfaces' satisfaction.
  • Acquiring your customers' level of satisfaction and does this match to the XLAs (Experiences Levels Agreement) with your provider.
  • Informing support staff on offers as refunds or incentives during disruptive events or poor service.
  • To know when to follow up with customers that require special care.

Metrics of SaaS

At some point, your customers will have issues that highlight your value stream or service pipeline's weaknesses. The tools that you use to monitor, alert, investigate, and respond to these issues can be improved by agreed metrics that make sense, such as the ones below:

  • How fast do customers receive a response?
  • What do they feel about that response?
  • How fast are incidents or requests resolved?
  • What is the lifetime value of a customer?
  • What is the cost of servicing a customer?
  • What is the cost of acquiring a customer?
  • What is your customer churn?
  • What is the total investment of SaaS over your customer value or cost?
  • Is there a group of customers that benefit more from a SaaS provider than others allowing you to decide how best to service those customers?

Final thoughts

The economy of tomorrow will be fully customer (user) centered. SaaS, cloud, digital and ESM will enable your products and services to become more individualized. Your SaaS provider has little value to you if the user journey is full of bad service. Your goal is to leverage the provider to retain and attract customers and staff. Thinking about how this will happen, setting clear expectations, expectations, documenting service examples with metrics in the contract, testing and monitoring service delivery, and having active conversation with your SaaS provider will ensure that the customers' experiences are delightful.

If you are looking for ways to improve your customer experience through technology and digital transformation, let's chat!

Topics: atlassian blog saas cloud hosting customer-experience
1 min read

Atlassian Hosting: What are my options?

By Morgan Folsom on Aug 20, 2020 2:15:00 PM

Atlassian Hosting options

One of the most important decisions that your organization has to make with regards to your Atlassian applications is which hosting option you'll use. Not only will you will want to review the differences between Cloud, Server, and Data Center, but unless you are using Atlassian's Cloud platform, you'll also have to make key decisions about infrastructure. Praecipio Consulting offers Cumulus Cloud, our managed hosting solution to help make your decision easier. 

Amanda Babb, our Principal Consultant, was recently invited to chat with the hosts of “CarahCast,” Carahsoft’s new podcast dedicated to bringing listeners the latest in Government IT case studies, technology trends, recent legislation news, and Government IT best practices. 

In the podcast episode titled “Hosting in the Cloud with Atlassian,” Amanda discusses Cumulus Cloud, our comprehensive hosting solution that manages server and data center editions of the Atlassian suite, the value it brings to the enterprise organization, and why it's different from any of the other solutions out there.

Listen to Principal Consultant Amanda Babb outline all of the above and more in this Atlassian Podcast with our partner, Carahsoft. 

Topics: atlassian blog migrations cloud hosting atlassian-products podcast
3 min read

What To Avoid When Building Your Confluence Knowledge Base for JSD

By Rebecca Schwartz on Jun 10, 2020 12:30:00 PM

2020 Blogposts_What’s the difference between Affects Version & Fixed Version- copy 2

Building a successful Jira Service Desk requires a lot of moving parts. It can be difficult to find the perfect balance between ease of use for your agents (those who work on requests) and your customers (those who submit requests). One of the most important ways of achieving that balance is to create a great Confluence Knowledge Base (KB). If your articles are relevant, concise, and easy-to-navigate, your customers can avoid submitting a request, giving time back to both the customer and agent. Below are some common mistakes to avoid as you work towards creating your ideal Confluence Knowledge Base that is a reliable, single source of truth for your agents and customers.

Don't Put Your KB Articles in a Space Used for Internal Documentation/Non-Service Desk Related Content

If you create KB articles in a Space where non-service desk related pages already live, confusing or unwanted information may appear when customers search for help. This may push your customer away from reading the content and make their overall experience less enjoyable. Compiling your Knowledge Base articles in their own separate space is key to ensuring the most relevant articles show up when the customer uses the Service Desk. If you need to centralize documentation for both agents and customers alike, leverage page restrictions in the Space to allow for internal and external content.

Don't Create Lengthy Articles Using Technical Terms

When writing articles for customers, it's important to keep them top of mind. The customer may not understand the technical or team-related verbiage your agents typically use. It can feel daunting for them to look at a wordy article, so we suggest using bullet points, numbered lists, and mixed media (images, videos, etc.) to break up the content. Applying screenshots to your articles can also be useful, as it provides the user with a visual guide on out troubleshoot the issue on their own.

Don't Create Every Single Article From Scratch

Although they may not be useful for all of your articles, Confluence has built-in templates available for you to use when creating most of the content in your Knowledge Base. There are templates specifically for Troubleshooting articles and for How-To articles that have handy macros and formatting already incorporated. You can even customize these templates to better meet the needs of your users. If the out-of-the-box Blueprints aren't the right fit for your requirements, you can create custom templates (although you won't be able to create them from the Jira issue directly in the same way), which will save your agents time when creating articles and allow for a consistent user experience when navigating through the KB. 

Don't Ignore Reports on the Usefulness of your Articles

Jira has several native reports that allow you to see how your Knowledge Base articles are performing. The Requests Deflected report illustrates how often your customers find articles useful. This report shows deflected requested and how often articles are viewed in the portal. The Requests Resolved report displays the number of requests that have been resolved with an article, those that were resolved without an article, and requests deflected in the portal. These reports are key for determining which articles are beneficial to your customers, which allows you to tailor your content to meet customer needs.

 

Now that you know what not to do when building your Confluence Knowledge Base, explore how Praecipio Consulting has answered other Service Desk questions, like How does Jira Service work with ITIL? or Can you really set up an ITIL-based Service Desk in 3 weeks?

Topics: blog confluence knowledge-base jira-service-desk customer-experience
2 min read

How Jira Can Help Your Teams Work Remotely

By Praecipio Consulting on May 8, 2020 9:15:00 AM

According to a recent article published in the Harvard Business Review, one of the common challenges when working from home is a lack of access to information. At Praecipio Consulting, we often see this challenge with many teams, especially they remotely. Here's how Jira can help:

Visualize current work with Kanban boards

A Kanban board (or a similar variant) can be a remote team’s best friend. Instead of emailing, Slacking, texting, or calling a coworker to find out the status of a particular work item, a team member can simply navigate to the Kanban board and find a wealth of information. A well-configured board is easy to read and quickly conveys a brief description of each item the team is currently working on, as well as the status, assignee, and any other team-specific information. This helps cut down on extraneous communications within your organization and provides remote workers with a quicker and easier way to access information.

Reduce the number of emails by commenting on issues

Not only is commenting on issues quicker than typing up an email, but comments also live in publicly visible space and are saved in the issue. This immediately creates two advantages over email. First, commenting makes it much easier for other coworkers to see the progress on the issue, preventing them from having to send an email to ask questions about the issue, who’s working on it, when was it last worked on, and what progress has been made in the past week. Second, users never have to wonder why somebody made a particular decision or repeatedly ask for information because the entire conversation is stored within the issue. Using @ mentions to tag a coworker or manager helps speed up this process and better organize the information, in addition to drawing specific users to the issue and providing context.

Benefit from linking Jira and Confluence together

When Jira and Confluence are linked together, one can simply enter a Jira issue key into a Confluence page, and it will automatically contain a link to the Jira issue. Similarly, it becomes possible to link a Confluence page to a Jira issue by just referencing the title of the page. A few common use cases include: linking a resolution document in Confluence to the incident issue in Jira, displaying the progress of related Jira issues on a requirements document in Confluence, and linking several helpful articles to a service request in Jira. This helps solve similar problems more quickly, reduces time spent searching for that one Confluence article, and eliminates the need for status emails.

Jira was created to help teammates access information, allowing them to visualize and organize complex and hard-to-see work; and that's why Jira is the perfect tool for a remote team.  

 

Struggling with remote work in this time of uncertainty? Praecipio Consulting provides a turnkey implementation of best practices in Jira with an Accelerator. Whether you're supporting SDLC, ITSM, or PPM, we can rapidly deploy Jira to support your team. Reach out to us to learn more about Jira and how it can facilitate remote work. 

Topics: jira blog teams tips atlassian-products work-from-home remote-work
6 min read

Comparing Project Management with American Football

By Nicholas Redwine on Sep 3, 2019 1:43:00 PM

As the summer comes to a close here in America, another season arises upon us that encapsulates the fall and winter seasons for the better part of 6 months. That fun and exciting season is American football ladies and gents! A nationally televised spectacle that brings together all types of people and backgrounds to witness the output from an assembly of individuals striving to capture a "W" or win for their respective team(s) and organization(s).

With the exception of the direct national spotlight, the aforementioned statement sounds a lot like what Project Management entails. If we take into consideration the end-to-end phases of both Football teams and PM teams, we can see there are frameworks and disciplines that run parallel to accomplish the "finished product" (which is ultimately what the end-user or fan actually sees).

Below, is a side by side comparison of the phases and how similar they are in relation to one another:

project-managementScreen Shot 2018-08-09 at 2.17.50 PM

Project Management Framework Phases & Explanations
Football Framework Phases & Explanations

Project Initiation

The first phase of the project lifecycle. This is where the project’s value and feasibility are measured. Project managers typically use two evaluation tools to decide whether or not to pursue a project. Product Owners are key stakeholders and generally have a vision that he/she has to convey to the scrum team.

Talent Assessment & Utilization

This phase is where coaches and internal staff line up and evaluate the current talent (player's) and incoming talent they have for the upcoming season in oder to develop schemes and strategies that will be implemented towards the upcoming season. In relation to Project Management, the Head Coach would serve as the Project Manager defining the team and the direction they should go. Assistant Coaches would be more of the Product Owners with them needing to coach their player's (scrum team) specific techniques and the fine details of the schemes in to fit execution. This will involve many hours of building play-books, film repositories, team drills and sessions to help build examples in order to convey clear, concise messages.

 

 

Project Planning

Once the project receives the green light, it needs a solid plan to guide the team, as well as keep them on time and on budget. A well-written project plan gives guidance for obtaining resources, acquiring financing and procuring required materials. The project plan gives the team direction for producing quality outputs, handling risk, creating acceptance, communicating benefits to stakeholders and managing suppliers.

Offseason Workouts

This phase is the most important as it broken down into smaller meta-phases which put into action team chemistry, focus and preparation that will guide them to the start of the season. Here, many resources are compiled/executed in order to mold them team. This includes strength and conditioning (winter & summer), nutritional diets, film-study and wellness (recovery & massages). All of which are under a close watch with analytics playing a huge role in the development and growth of the athletes. In the NFL, there is a practice period called OTA's (Off-Season Training Activities) where the team has mini-practices that are built for speed and efficiency and in college, Spring Football which essentially is the same concept where development is further evaluated to determine if the team is capable to match the derived schemes with the personnel they have long-term.

Project Execution

This is the phase that is most commonly associated with project management. Execution is all about building deliverables that satisfy the customer. Team leaders make this happen by allocating resources and keeping team members focused on their assigned tasks.

Practice & Game Day

Just like project management, this is the phase where the strategies and playbook installations are put to the test with full-blown practices up to 2x/day to refine and simulate what actual game speed and tempo would be. This allows the coaches and team to have a concrete idea of what they envisioned vs what they're actually able to execute. Furthermore, this is an area that allows coaches to further determine how effective the off-season development was and if the proper adjustments were made from the previous iterative-shortened cycles of the previous practices. This essentially moves to " Game-Day" where the players and coaches are able to showcase to the world and those watching the product that they've come up with for the start of the season.

Project Monitoring and Control

Monitoring and control are sometimes combined with execution because they often occur at the same time. As teams execute their project plan, they must constantly monitor their own progress.

To guarantee delivery of what was promised, teams must monitor tasks to prevent scope creep, calculate key performance indicators and track variations from allotted cost and time. This constant vigilance helps keep the project moving ahead smoothly.

Film Study & Adjustments

Many variables play into the season that are realistically expected but not hoped for. Issues such as injuries, player conduct, chemistry and coaching can contribute to negative/positive outcomes and performances. Being able to monitor this with rigorous film study and culture curation can absolutely help soften the blow of negative outcomes but also serve as a roadmap in the continuation of success. Much like project management, key indicators must be addressed and preventative maintenance must be accomplished in order to keep the momentum towards the end goal. Many bumps may occur but this is where flexibility and team focus are paramount. Usually coaches and players alike will remind themselves and others of the long-road they took to get to this point and the importance of team camaraderie. In a sense, there could be another project spun up in the middle of the season that could be supplemental to the primary project which forces a huge amount of flexibility. Although the odds of executing are high in failure rates, there have been numerous teams that have gone on to conquer and eventually have a winning season and sometimes a season resulting in the ultimate goal of a "championship"

Project Closure

Teams close a project when they deliver the finished project to the customer, communicating completion to stakeholders and releasing resources to other projects. This vital step in the project lifecycle allows the team to evaluate and document the project and move on the next one, using previous project mistakes and successes to build stronger processes and more successful teams.

End of Season

The end of the season marks the end of that particular team. In football, and sports in general, no (1) team is ever the same. Off-Season trades, Retirements, Drafts and coaching changes in the NFL are always a guarantee and the same goes for college with the exception of graduation, transfers and recruiting classes from High School to College. These variables all play into the development of a new team with new goals for the new year.

The summation of the season is literally defined by the W-L (Win-Loss) column. It doesn't matter about what was in between or participant trophies but rather if the team delivered. And that is much like Project Management, " What did you deliver?" A "W" (win) or "L" (loss) for your spectators/customers?

Ready to tackle an Atlassian project? Contact Praecipio Consulting to learn more about our expertise across a wide array of management methodologies, and deep knowledge of the Atlassian toolset. Or take some time to view our webinar Agile Project Management with Atlassian and Tempo to learn how to seamlessly manage projects and portfolios in one place. 

Topics: blog practices project-management
2 min read

Kanban vs. Scrum: Which One and Why?

By Suze Treacy on Jul 23, 2019 1:48:00 PM

Are you looking for ways to make your work more flexible and efficient, but feeling late to the Agile transformation party? Well, fear not! It's OK to be fashionably late to this Agile shindig!

Out of the many Agile Development frameworks out there, Scrum and Kanban are arguably the best known - similarities include their focus on continual improvement, and minimizing waste; breaking down large pieces of work into manageable, bitesize chunks for efficient delivery. However, it's important to understand the differences when looking to choose which style of working is right for you and your team.

What is Kanban?

Kanban, a workflow visualization tool, was first developed in the 1940s by Taiichi Ohno, for Toyota. Faced with a lack of productivity compared to their American rivals, the aim was to find a way to optimize productivity alongside their cost-intensive inventory of raw materials. A continuously improving process, Kanban uses boards with team-determined limitations to limit WIP (work-in-progress), identify and eliminate bottlenecks quickly and improve efficiencies among the team. Formal training is not required for teams to get started in Kanban, and, given that Kanban boards are intended to be used by everyone on the project, there is less need for cross-functional team members - it's easy to get started with Kanban quickly!

What is Scrum?

Although the history of Scrum is not without its controversies, it is widely understood that Scrum was developed in the 90s by Jeff Sutherland and Ken Schwaber, to present at the OOPSLA conference in Austin, Texas. Sutherland and Schwaber borrowed the term "Scrum" from Takeuchi/Nonaka's paper ‘The New New Product Development Game’ - comparing a team sport like rugby with success in the 'game' of product development. Scrum is far more structured than Kanban - with commitments to short iterations of work, team members have designated roles and responsibilities (product owner, scrum master, team members), with clear priorities identified by the product owner. High visibility engages and increases team accountability, while daily meetings enable blockers to be identified and dealt with quickly; sprints (and potentially shippable increments) are generally being delivered every 2 weeks. It is this lithe process which allows Scrum teams to quickly adapt to change, maintaining and building upon team efficiencies in future sprints.

Which method is right for me?

The long and short answer is that there's no right answer for everyone. The best thing you can do for your team is to learn more about each framework and give them both a shot. It isn't always easy to break old habits; the road to a true Agile transformation can be long and daunting - we'd love to help you get on your way and show you how Jira can enable you to optimize your Agile processes; email us at contact@praecipio.com for more information. In the meantime, learn how Praecipio Consulting helps our clients conquer the Agile transformation using Atlassian tools, so they can drive business results, and innovate.

Topics: blog scaled-agile kanban scrum
2 min read

A Review of the State of DevOps Report 2018

By Bryan Robison on Oct 4, 2018 11:00:00 AM

Our partners at Puppet and Splunk recently released the State of DevOps Report 2018 which mirrors many of the same observations that we see when working with our customers. DevOps isn't a sprint, it's a journey, depending on the organization's size, that can take organizations months or years to master. Instead of focusing on statistics like in prior years, this year's report introduces the five stages of a successful DevOps evolution and identifies and describes the practices successful, mature organizations have implemented during their journeys. The report has something to offer to organizations no matter where they are in their process. Even if your organization has employed DevOps for some time, you may be missing a critical component of your implementation.


Five stages in a DevOps evolution

The major takeaway from this year's report is that while there is no single path to a DevOps transformation, there are five foundational practices and five distinct stages of a successful DevOps evolution. Each stage is comprised of a set of practices broken down between "defining practices" and "contributors to success" which are identified and described for each stage of the process in the image below.

(State of DevOps Report 2018)

As organizations evolve from stage to stage, they refine and expand on the practices they implemented in prior stages. The report dives deep into the identification and makeup of each practice and describes how establishing practices identified as contributors to success in earlier stages such as "test infrastructure changes before deploying to production" in Stage 1 become mission critical defining or associated practices in later stages. DevOps is not a sprint, but a marathon, and requires organizations to have effectively executed each stage before advancing to the next one. Quite often we see that even the foundational practices such as monitoring, testing, and configuration management described in Stage 0 are missing from our customer's toolchains.

DevOps starts with a ripple

We frequently hear stories from our customers about how they began using Atlassian tools. These stores often begin with when a single team purchased a Cloud account or installed Jira onto a server sitting under someone's desk. Usage evolves and expands over time and eventually, the whole organization is reliant on the application for mission-critical operations. The report found that the DevOps evolution begins in much the same way: starting with a single team who defines their own practices for DevOps and shares them with other teams within the organization.

Where do I start?

The State of DevOps Report 2018 recommends starting with production by choosing an application with an, especially painful deployment process. We often describe DevOps as breaking down the wall between Development and Operations and deployments are where frictions between the two often occur. By automating deployments teams can improve collaboration and communication while reducing the friction caused when things go wrong. 

Since 2010 (before DevOps was called 'DevOps), Praecipio Consulting has been fortunate to work with customers at all stages of the DevOps evolution and guide them in using Jira, Confluence, Bitbucket, Bamboo, and other tools like Puppet, Splunk, New Relic, xMatters, qTest, and AWS as part of their technology standard. 

To learn more about how Praecipio Consulting can assist you with your DevOps journey, be sure to register for our upcoming webinar "DevOps: An Interpersonal Approach" on October 10!

Topics: blog devops process-consulting
2 min read

Getting to DevOps: Where to start? Where is done?

By Michael Kelly on Sep 25, 2018 11:00:00 AM

As with life, the only constant in DevOps is change. To position your teams to seamlessly flow with the changes and to empower them to innovate, some of the old ideas on Operations and Development practices must be left behind. An integral component of DevOps is culture. An iterative approach to a collective ownership should be taken when planning your move toward a DevOps environment. You can start your DevOps journey by advocating for the adoption of a consolidation of tools designed specifically for DevOps, which provides an environment of transparency and ease of use.


Agile

Adopting Agile development practices, iterative planning and short cycles can alleviate the frustrations that fester as ill-planned deadlines are not met. Developers will be more empowered to meet shorter competitive deadlines while working appropriately planned sprints and have more time to innovate and experiment. Agile development will also be far less likely to produce bugs that are difficult to locate and fix.

Continuous Integration

Adopting the use of CI, you can avoid code that may have to be completely redone when it fails in production. Tests performed on small changes to the code, committed several times a day, have proven to be less prone to failure. Smaller changes lead to higher quality, have less risk, and allow for easier code reviews and locating problems.


Infrastructure as Code to define test, prod, and other environments has proven very successful. Self-service infrastructure for developers to have provisioned, tested against, and disposed of, can bring your team to a place of continuous learning and experimentation and make reactive scrambling to determine what is broken a thing of the past. Utilizing these methods, environments can stay in closer parity with fewer differences and remove the surprises when tests pass on the test environment, but fail in production deployments, as tests are more complete and valid.

Monitoring

Monitoring infrastructure, operating systems, application, and third-party cloud services are crucial in observing trends, understanding the health, and receiving an important feedback loop. Tying all of the monitoring together with a tool specifically designed to do so, and having alerts visible to everyone involved will provide transparency, trends to act proactively on, and ensure that the end user is receiving the highest quality product.

ChatOps

ChatOps is not the same as IM, or instant messaging. ChatOps tools have the capability to integrate with other tools. Seamless integration makes statuses of all the components transparent at all times. Utilizing ChatOps in your DevOps environment provides faster and continuous communication at all phases, from planning to a commit to a production deployment and its effect on the end users.  

Continuous Communication

Select tools that enable continuous communication.

Feedback loops should be real time and visible to teams at all times.

To consider your environment DevOps, you should be in a state of constant and iterative improvementAgile practices, CI, Monitoring, ChatOps, and the flow of Continuous Communication are all necessary steps to reach this goal.

If you're still interested in our approach to DevOps, be sure to register for our upcoming webinar "DevOps: An Interpersonal Approach" on October 10!

Topics: atlassian blog devops process-consulting consulting-services
2 min read

Providing Visibility and Transparency through Atlassian's Dashboards and Gadgets

By Chris Hofbauer on Sep 25, 2018 11:00:00 AM

Leveraging Atlassian's dashboards and gadgets can provide teams within an organization the visibility and transparency into their work they may be lacking. The use of these tools gives greater insight into work in progress and completed work for individual teams or team members as well as providing top-level views of all the work across teams. Dashboards can be configured in many ways and be custom tailored to surface whatever information is desired. Dashboards are made up of gadgets as they are the driving force behind the data. These gadgets are embedded into the Dashboards and the information within them is determined by the JQL in the filters.

Some of the commonly used gadgets are the Pie Chart, Jira Road Map, Average Age Chart, Created vs Resolved, and Issues in Progress. Below is an explanation of these gadgets and their uses.

Pie Chart Gadget: The Pie Chart gadget can display data from many fields. The determination of which field you choose depends on your particular use case. Assignee, Resolution, Status, and Priority are some of the more powerful and frequently chosen fields. The issues are split by these fields and displayed in a manner that is easily digested as a visual. Clicking on any chunk of the pie in the gadget will take you to a more comprehensive list view of those issues. From here the data can be dug into deeper or exported for reporting.

Created vs. Resolved Gadget: The Created vs. Resolved gadget is exactly how it sounds. The data in this gadget will show all the issues that are resolved against those that are not. The use of this help to track how well the team is keeping up with their work items. Team leaders can view this data to determine where they are within a given sprint. If things are going as planned, the later they are in the sprint, the fewer number of issues should be logged. Since the Created vs. Resolved gadget focuses on work submitted and work completed, it is a good choice for Kanban teams to see their workload and progress made within a given timeframe.

Issues in Progress Gadget: The Issues in Progress gadgets provides a more granular view of all the issues within the development cycle that are still being worked by the team. Team leaders can use this information to get a more detailed view and quickly determine if there are some bigger issues in progress that could not be completed before the end of the sprint.

Jira Road Map Gadget: Development teams will get great use from the road map gadget. This gadget shows what has been completed within the sprint and what versions are due to be released at the conclusion of the sprint. Teams leaders can leverage this information to see where they are at in their projects and how their teams are performing.

These are only some of the many gadgets that can be used to provide the desired visibility and transparency into the work in progress. Team leaders will find these gadgets easy to use and customizable to whichever way fits their needs. It is important for teams to leverage these dashboards and gadgets so that their work can be done as efficiently as possible and completed in a timely manner.

Topics: jira atlassian blog
2 min read

What's the real value of Managed Services?

By Chris Hofbauer on Sep 17, 2018 11:00:00 AM

For organizations that use the Atlassian product suite, it's critical to decide whether to administer the products in-house. After all, there are significant considerations with infrastructure, networking, product tuning, let alone the configuration of the products. Choosing to engage in a Managed Services agreement can be extremely beneficial. A great Managed Services team can be a great asset and provide tremendous value to any size organization.

One of the greatest values provided is the administrative relief you get from a Managed Services team. The Atlassian products require devoted attention, especially within organizations that use it for all sources of truth. Having a Managed Services team allows an organization to have fewer full-time employees dedicated to the tools and instead on their primary area of expertise. Depending on the contract, signing onto Managed Services is typically half the cost of hiring on a full-time Atlassian administrator as well.

System monitoring, performance, and upkeep can also become a major burden to bear. Atlassian products and add-ons are frequently updated and if the applications are not well kept, the system can become outdated fairly quickly. With a Managed Services team, we work closely to ensure performance and maintenance doesn't fall behind so teams can continue to leverage the power of the Atlassian toolset.

One of the most valuable aspects of hiring a Managed Services team is the tribal knowledge and best practices that come along with it. When an organization has one or few Atlassian administrators, they are limited to the knowledge of those individuals. With a Managed Services team, you have the entire company to leverage. We have a large team that has seen various installations and configurations (both supported and unsupported) of the Atlassian tools, including those we host in Cumulus, our Atlassian Hybrid environment. By seeing all these variations, we are able to provide the best solutions that have been tested and proven.

The Atlassian product suite requires attention and care from people who are dedicated to the tools. Our Managed Services team helps to relieve administrative overhead for every organization through system performance and monitoring as well as best practices through tribal knowledge, all at less expensive option compared to a full-time employee or team. With this, hiring a Managed Service team provides peace of mind and great value. 

Topics: blog managed-services hosting itsm
2 min read

DevOps + Atlassian = Doing it Right

By Praecipio Consulting on Sep 17, 2018 11:00:00 AM

You've probably heard about a lot of the benefits DevOps teams enjoy - more effective investments, less stressful deployments, increased collaboration and visibility, and a healthier, happier, more empowered team.  With such encouraging results, the choice to take on a DevOps approach becomes an easy one. The trickier question, then, is what products can help your team take on that approach?

Fortunately, there are thousands of applications to help get you there.

Unfortunately, there are thousands of applications to help get you there.

We've worked with hundreds of clients across virtually every industry, and we have encountered untold numbers of applications, tools, and solutions along the way. In our experience, the Atlassian stack is a top choice.

We typically see a lot of added value with each team using an Atlassian stack:

Cost-effective

The overall solution is more cost effective. Atlassian prefers to spend money on product development, rather than supporting a gigantic sales team. This enables them to build best-in-class products while keeping the price tag favorable.

Integrations

Every application in the solution is integrated. Again unlike other companies, Atlassian produces products across the entire DevOps infinity loop, which results in a number of standalone products that integrate extremely well. It's kind of like the days before Apple became a dongle company when all of their products just worked together.

Customizable

Teams can customize the products to meet their needs. Not all teams want to work the same way. Differences as large as Scrum vs. Kanban or as small as where to record Acceptance Criteria can be easily managed.

Numerous applications

The Atlassian marketplace has over 1,700 different add-ons, meaning there are options to extend into nearly any other existing application in the DevOps space. If that somehow doesn't cut it, there's also middleware like Workato to help bring systems together.

Atlassian prefers to focus on building products that people love, and we've seen and confirmed for a dozen years that teams love using the products. And after all, isn't empowering teams what DevOps is all about? 

Topics: blog devops process-consulting consulting-services
2 min read

Stillness in Chaos

By Christopher Pepe on Sep 4, 2018 11:00:00 AM

Walking the halls of Praecipio Consulting you will often hear people talking about the cost of quality. One of the areas that we focus on with our clients is the cost of rework which is due to poor quality and can often be improved with a better process. While there are many reasons for poor quality, a common reason (which permeates all aspects of our lives) is rushing. One of my favorite YouTubers put it as "Never rush that which must be done quickly." You might ask what sitting in snow, or a survival skills/mindfulness youtube channel has to with the quality software, incident management, or any of the other high tech stuff we do. Especially when it comes to high stress, time-sensitive situations there is a lot to learn from other domains.

I was a waiter for about a month. More correctly, I was a terrible waiter for about a month. I never got orders right, I failed to bring second drinks, or really fulfill most customer requests satisfactorily on a busy night. I was ok at serving lunch and slow nights but I was easily overwhelmed by the volume of tasks that waitstaff has to manage. I often look back at that time for insight because I have generally been pretty good at most jobs but failed so completely at waiting tables. My core issue was that I was also rushing because I was in a hurry and that lead to decreased quality of service and longer cycle times. Because I rushed: I delivered the wrong dishes (or accidentally took dishes meant for other tables causing the rest of my team to fall behind too), I forgot that coke, I didn't split your check, I made the wrong change... And with each mistake, I had to stop, correct that problem, and leave my other tables with a worse experience too.

You can go a lot faster if you start with slowing down.

  

Topics: blog
2 min read

Tips, Tricks, and Tools for Time Management

By Praecipio Consulting on Aug 27, 2018 11:00:00 AM

In an age where there’s a tool for every toil, we’re fortunate at Praecipio Consulting to be able to work with the best tools available. As an Executive Assistant who survives on staying organized, ahead of the game, and juggling with an exceptional attitude is just part of the day-to-day. If you hear “How do you do it?” you are not alone. How do I do it? The right tools.

Finding tools with exhaustive capabilities, that are simple enough a non-technical user to navigate, isn't an easy task. So here are my top three tools that help me find the most success in my day-to-day.

Calendars 

I live, eat, sleep, and breathe with my calendar - ok not that extreme. But, our team does use Google calendar, and from your first day, the expectation is that it’s up-to-date and detailed enough that others will have the information needed in order to make scheduling meetings with you a breeze. Establishing this as a best practice will help teams maintain prioritization, eliminate duplicity, and create a more cohesive dynamic.

Task Management 

Jira serves as our task management tool. I will either assign tasks to myself and/or manage tasks for other projects or teams. Jira is an Atlassian workflow management tool that helps teams plan, track, and manage tasks, tasks within larger tasks, and prioritize projects while eliminating the common silos and blockers associated with project management.

Communication

Team chat and collaboration tools are a necessity for productive teams and there are a couple of good options out there to choose from. Our team currently uses Stride, an Atlassian chat platform that facilitates a more communicative environment; however, we will be moving to Slack soon. Stride helps our entire (local and remote) team stay connected, engaged, and informed. Several of our team members are constantly on the road traveling to visit clients, so having a communications tool is very important.

Ultimately, no one wants to drop the ball, fall behind, or be so overwhelmed they have a case of the Mondays every day. So use the tools you have, and make sure you are maximizing the tool's capabilities. If you aren't sure that you have the right tools to be successful, pioneer the charge for change and introduce one of the tools I mentioned. Who knows, it just might work! We all want to get the job done and sometimes the path to completion can be challenging, so why not make that path smoother for the next person or the next trip? Pick a tool, put it in place, and practice good process.

Topics: blog
4 min read

Reporting on Jira in Confluence with the Jira Issues Macro

By Morgan Folsom on Aug 27, 2018 11:00:00 AM

One of the most powerful integrations in the Atlassian ecosystem is the native link between Jira and Confluence. For users working in both tools, the transition can be seamless if you do it right, but clunky if you don't. 

Now, what if I told you there was just one Confluence macro you could start using today that will immediately make reporting in Confluence easier and help you (and your team) keep track of your work? The Jira Issues macro is the go-to when reporting in Confluence.

Here are some tips to get your team to live their Atlassian life-to-the-fullest.

Insert an issue count for a Jira filter

Let's start small. Insert a link to Jira with the number of issues returned from a Jira Query Language (JQL) query.

This is useful to pull up basic metrics for a high-level overview. The macro becomes a link to the filter, so if you want to review the issues in-depth, you can quickly hop over to Jira's issue navigator. The table below is an example of how our marketing team tracks employee blog post submissions.

 

To insert an issue count:

  1. Insert the Jira Macro
    1. Select the  in the top menu bar and select Jira Issue/Filter, OR
    2. Type { on your Confluence page, search and select Jira
  2. Enter in your JQL query
    1. To input an existing filter, type "filter = "Filter name", OR
    2. Type in the JQL directly
    3. Be sure to click on the Magnifying glass to execute the query
  3. Select 'Display Options' at the bottom of the dialog box to expand the options.
  4. Select 'Total issue count'
  5. Click Insert, and Voila!

Insert a single issue into Confluence

This macro can also link to a single Jira issue to a Confluence page. That means not only can you see what issues are important (and what status they're in) in your documentation, but you can also see who's talking about the issue when you're in Jira.

Take, for example, this blog post. My progress is tracked on a Jira issue, linked to this very page in Confluence. Below you can see how it looks on the Confluence page I'm writing in. 

If I click on that link, I'll move over to Jira where I can see all of pages in which the issue has been mentioned under Issue Links. Right off the bat, I can see that the issue has been mentioned on this page as well as another tracking Blog Content. 

To insert one issue:

  1. Insert the Jira Macro and enter in your query (steps 1 and 2 above)
  2. Select one issue from the list
    1. If you know exactly which issue, you can simply type the Issue Key into the search bar and hit enter. 
  3. Expand the Display Options and select 'Single Issue'
  4. Select 'Insert'

Use the Jira macro to insert a list of issues in a page in Confluence

Remember that filter you entered in above? You can insert that filter into your page, too. Filters inserted with this macro are dynamic - that is, as the issues are updated in Jira, the Confluence page will reflect the most up-to-date information. You can customize which columns appear in the macro just like you can in Jira. To head into Jira, you can select the individual issues, or click on the total number at the bottom ('2 issues') to pull up the query in Jira.

To insert a filter:

  1. Insert the Jira Macro and enter in your query (steps 1 and 2 above)
  2. Expand the Display options and select 'Table' 
  3. Edit the maximum issues and columns to display.
  4. Select 'Insert' to add to the page!

Create a Jira Issue from a Confluence page

If your issues don't exist in Jira yet, don't worry. This macro can create new issues in Jira if inspiration hits while you're editing a Confluence page. The issue will be created and you won't even have to leave the page. 

Additionally, you can also create issues from Confluence while viewing a page - simply highlight some text and then click on the Jira icon that appears.

  1. Insert the Jira Issue Macro
  2. Select 'Create New Issue' on the left panel
  3. Complete the form
  4. Select 'Insert'

This one macro can solve many of your reporting needs in Confluence. What's more, you can provide context around the data instead of just straight data. The Jira Macro is a great way to keep team members informed without navigating from Confluence to Jira and back again. 

Interested in learning more tips? Check out our blog Guide to Import Linked Issues into Jira from CSV.

Topics: jira blog confluence optimization process-consulting integration
3 min read

How to Extinguish Fires with Jira Service Desk Automations

By Brian Nye on Aug 27, 2018 11:00:00 AM

While service desk agents do everything they can to avoid firefighting, they are often focused on extinguishing one fire and moving to the next. This usually causes tickets to smolder in some status of "not quite done" until months later when they will finally be closed out (thanks bulk edit!). The good news: there is a way to keep things moving using out-of-the-box functionality. No longer will your metrics be inaccurate because people aren't "moving their tickets through the system." Jira Service Desk can help do the moving for you with automation.

Putting out Smoldering tickets

Many workflows offer customers a chance to review the ticket before closing. But, replying to the work request isn't always the top priority of the customer, which in turn, leaves the ticket to smolder in an almost done state. Instead, Jira Service Desk can help you do a fully extinguish the request by doing a couple of things, messaging the customer on impending closure and auto closing the ticket with no response. Just follow these steps below.

Step 1: Create SLAs

While this may seem odd, SLAs can be used for more than just metrics, they are a great trigger for automations due to the extended functionality SLAs bring in Jira Service Desk. Start by creating two SLAs, call them Time in Resolved - Customer Notification and Time in Resolved. Set Time in Resolved - Customer Notification to the parameters shown in the screenshot below. Note, the SLA time can be changed depending on the amount of time you want to elapse before notifying the customer that their ticket will be closed. The SLA for Time in Resolved will have the same start and stop conditions, but put the goal time to be more than the goal of the notification trigger (for example, if the notification is set to send 120 hours after entering the status, than set the goal for the auto close to be 168 hours as this will give 48 hours for the customer to respond).

Step 2: Create Jira Service Desk Automations

Great, now that these SLAs are in place, let's use them to trigger Jira Service Desk Automations.  

Step 2a: Time in Resolved - Customer Notification

For this Automation, you will want to set the When to trigger off of the Time in Resolved - Customer Notification SLA when the SLA has been breached. Feel free to add an optional If statement should there be situations in which the SLA should not be executed. Lastly use the Public Comment option for the Then statement to send a message that the customer will receive. Included is a screenshot of this automation.

Step 2b: Auto Close Resolved Ticket

For this Automation, you will want to set the When to trigger off of the Time in Resolved SLA when the SLA has been breached. Feel free to add an optional If statement should there be situations in which the SLA should not be executed. Lastly use the Transition Issue option for the Then statement to move the issue to the final status. Note that it is best to use a hidden transition which does not require any fields or info as this is done through an automation. Included is a screenshot of this automation.

Step 3: Find other small fires to put out using automations

This is just one example of how automations can be used to keep customers engaged on the ticket and closing out issues that have been resolved. This same logic can be applied to many different areas in Jira Service Desk and can keep your front line firefighters focused on the hot spots and less time doing clean up!

If you still want to learn more about Jira Service Desk automations in action, join us for our next webinar on September 12, 11 a.m. CST: Automation with Jira Service Desk.

Topics: jira blog optimization process-consulting consulting-services itsm jira-service-desk
8 min read

Praecipio Labs: Control Systems with Neural Networks

By Praecipio Consulting on Aug 15, 2018 11:00:00 AM

What, why?

My favorite class in college was Neural networks for non-linear control systems which was way out of my league but I wanted it, so I powered through. I majored in mechanical engineering and studied computer science and electrical engineering because of a passion for robotics. This class blew my mind. Life being what it is, I went off to build a career which took me away from machine learning until recently. Things have come a long way in the intervening years and I wanted to recreate the approach we used in this class.

The animations that we created were what most captured my imagination because they would show the controller learning and improving.

 

information

 

The animations that we created were what most captured my imagination because they would show the controller learning and improving.

 

My old code is unreadable. Between my decade and a half of improved coding style, and the early NN libraries that we used, I didn't glean much what code I still have. I spent a while trying to untangle that mess before just doing it from memory and filling in the gaps with frog DNA.

The experiment

I created a simple universe in which a rocket that can only move along the Y-axis. It is given the task of moving from its current position to a goal state along a "minimum jerk based trajectory." The rocket has a single engine that can fire downward. Since it has a mass of 1000kg it needs to produce a thrust of 9800N to hover (I think, it has been a while). Anything less than that and the rocket will lose altitude, anything more and it will gain altitude.

This required some serious way back machining to build the physics engine which tracks the current position, velocity, and acceleration of the rocket for a given timestep. Acceleration is calculated and velocity, and position are integrated from there.

def updateState(self):
        self.time += timeStep
        #calculate the current acceleration based on thrust  assuming it is instantaneously applied
        self.accelerationY = (self.thrust/self.mass) + gravity
        #calculate the speed based on acceleration assuming it has instantaneously changes and is constant
        # (we could += here but it makes the physics harder to follow)
        self.speedY = 2*self.accelerationY*timeStep + self.speedY
        #calculate the change in height given our current state assuming everything is constant over the time step
        ##NOTE: oddly self.accelerationY**timeStep creates an imaginary number
        newY = self.accelerationY*timeStep*timeStep + self.speedY*timeStep + self.y
        #the ground is 0
        if newY >=0:
            self.y = newY
        else:
            self.y = 0
            self.speedY = 0


While this approach requires iterating over time, this update method is an easy way to measure the effect of changing the thrust over the timeSteps. Any thrust profile can be plugged in to see what the rocket would do. For example, one could leave the thruster off of 2s and then apply 10,000N of thrust. In that scenario, the rocket would free fall for 2s and then continue to fall before overcoming gravity and gaining altitude.

The code below was used to allow the trained neural network controller to fly the rocket and try to achieve its goal. Given the current state (time to goal, position, distance to goal) the network outputs a thrust to apply for the next time step. Because everything in the neural network is normalized we have to scale the output via hugeify(). My rocket is called dragon too.

thrust_normal = dragon.controller.predict( state )
dragon.thrust = hugeify(float(thrust_normal), thrust_min, thrust_max )
dragon.updateState()
state = dragon.getState()

 

Results

Naturally, I tuned all of the hyperparameters for the best results. I learned a bit about why this network performs well with those parameters. I again found that it took a surprisingly few number of neurons to achieve the goal, and more neurons generally didn't improve things. Increasing the batch size improved the quality of the output (I assume because the network could see more of the time series in each training epoch). The dramatic change in learning takes places around 19 epochs, and beyond 100 epochs there is no real improvement in learning (presumably overfitting at this point).

The path is simple. Starting at a height of 15m, moving at 0 m/s, fly up to 50m over the course of 45s. The minimum jerk trajectory to achieve that goal looks like this

image2018-8-2_16-18-2

and after 100 epochs of training the neural network produced this trajectory like this

image2018-8-2_16-20-8

What I trained on is the thrust for a given state (time to goal, position, distance to goal) and the thrust curve doesn't look as nice (by picking and choosing it can look better). The left is my calculated minimum jerk trajectory, the right is the output of the neural controller.

image2018-8-2_16-23-54

image2018-8-2_16-24-13

 

 

 

 

Here is an overly simplified animation of the resultant trajectories over a number of training epochs. Each path briefly flashes to the screen before the animation plays. Each marker remains at its final position so you can see how each run compares.

 

 

If you are curious, here is the output from the network after 100 epochs. The code is here. This was our approach in the aforementioned class. Generate tons of positional data and then animate it rather than have the simulation and controller working together in real time. I plan to move to a framework like OpenAI's Gym for future work.

 

Improvements

For the animation, I wanted to use an actual rocket looking figure, and scale fire coming out of the nozzle proportional to the magnitude of thrust but will tackle better animation next time.

I really wanted to approach this problem with a recurrent neural network since it is a time series problem as presented. I was unable to figure that out in the time I had for this effort but will revisit it. I think an approach like a text generator would work but need to noodle through some of the challenges unique to this problem.

Finally, I was happy to have a network that output a thrust rather than something like an acceleration or displacement but how I got there was weak. Generating training data requires solving for the physics to determine the "correct" thrust and this is flawed in a few ways:

  • if we can perfectly model the system we don't need a NN controller to try to learn the dynamics
  • this system cannot handle the dynamics changing (e.g. mass changing from burning fuel) or a hundred geese landing on the rockets nose

Another area of interest is replacing the trajectory generator with yet another neural network. My current thinking is that I can use a Generative Adversarial Network (GAN) to train a generator on the trajectory creation skill and feed in actual minimum jerk trajectories to the discriminator. There are still problems with this approach but it will be worth the exercise if only to build a successful GAN.

Anyway, another fun toy project completed.

Topics: blog
3 min read

The Five Things You Should be Automating For More Effective Incident Management

By Praecipio Consulting on Aug 14, 2018 11:00:00 AM

 

Guest blog post by Erin Jones, Partner Manager, xMatters

Access your monitoring platform and find the alert. Export the data report. Create an issue in Jira, then attach the data report. Search assignees and add all necessary parties to the ticket. Spin up a chat room for the incident to facilitate swarming. Log into your StatusPage and let your users know about the incident, at each stage, as you can now finally get around to resolving it.

These are all the things Incident Managers may find themselves doing when a major issue or outage occurs - and all of these put together increase the time to when your teams can actually begin working on fixing the issue. Not to mention, if this incident occurs in the middle of the night - imagine repeating all these steps, under stress, and at 2 a.m.

When the average cost of downtime is $300,000 per hour, doing all these steps manually can easily add six figures to this total - so, why aren’t you leveraging proactive notifications to decrease this time?

We’ve assembled a simple checklist of the top proactive measures you should be automating to decrease time to report and engage for a faster time to incident resolution.

  1. Create a Jira Issue

With the push of a button from the xMatters notification, you can create a Jira issue in your team’s project, including issue type (as you’ve customized it for your use case) and proper assignee. Plus, the data from the incident alert in your monitoring tool (ex. Splunk, Dynatrace, AppDynamics) will automatically be added to the issue - so your assignee and watchers have all the information they need to get started on the issue 

2.              Start a Chat  Room

Swarming is one of the most effective ways to get your team collaborating on incident resolution in real time. From xMatters, you can also push a button to start a chat room in HipChat, Stride, and/or Slack. Then, select from your on-call schedule to pull in the necessary people. And just like with the Jira automation, your monitoring alert data appears in the chat room without any additional work.

3.              Spin up a Conference Bridge

            Need to get the right people on the phone? You guessed it - another button click and you’ve got a Conference Bridge with the right people invited to join. No more logging into your call system, setting up a number, and texting/ emailing folks to share this info. Now, you have more time to get to what matters. 

4.              Notify Stakeholders

At this point, you have stakeholders needing updates - but you probably don’t have the time to stop working and craft an email with all the information. By customizing your Comm Plan[DG3]  in xMatters, all this can be automated too. Simply set up who needs to know what and when (i.e. “Email this list of people only for a P1”) and you have one less thing pulling you away from resolving your incident. 

5.              Post to StatusPage

            Outside of your internal teams, you also have other important stakeholders: your customers. To keep them up to date on the issue and your steps to resolve, click the StatusPage button in xMatters to automatically push updates. Not only does this let your clients know what’s going on (without added time away from incident resolving), but it also significantly decreases the number of new tickets you’ll get from clients who don’t know you’re aware of (and working on fixing) the problem.

Automating any of the five above steps drastically reduces your mean time to resolve - and with xMatters, you can easily accomplish all five. Optimizing your Incident Management process saves your company money and keeps your teams, stakeholders, and clients happy. Plus, it makes those 2 a.m. outages a lot less stressful. 

Ready to implement these 5 steps to faster MTTR?

Contact Praecipio Consulting about licensing and implementing xMatters.

 

Topics: blog itsm
2 min read

What You Need to Know about Page Results Rankings in Confluence

By Praecipio Consulting on Aug 13, 2018 11:00:00 AM

Search engines have the ability to house a plethora of information that helps users find the answers they're looking for. As more information gets pumped into a search engine or knowledge base, the importance of finding what's relevant becomes increasingly important.

Search results and ranking go beyond search engines like Google. Confluence is a wiki tool used for team collaboration in a variety of environments. Businesses utilize Confluence as their knowledge base, making it their go-to documentation and collaboration toolFinding a page with the solution that fits your search criteria in Confluence as quickly as possible reduces the time spent on searching, and increases the time spent doing the task at hand. 

It's important to note that all unrestricted Confluence pages have the same chance to appear in search results. However, there are a few approaches to weighing how Confluence pages are ranked. 

Page popularity

Pages with similar content will rank according to the number of incoming links to the page. The more pages linked to a particular page will tell Confluence that the content on that page is of high importance, resulting in a higher rank for that page. 

Frequency of search term in page title and content

Confluence calculates how many times a search term appears in page titles and content. This is especially true for page titles. Matching terms in page titles based on a search criteria are given the highest priority. For example, if you search "insert example" in the quick navigation search bar, Confluence will return pages with "insert example" in the title as the highest search results. 

Page Weighting

For each piece of content, Confluence applies weights based on:

  • Content type - such as user profile, blog post, etc.
  • The type of field in which the search term was found - such as name, content body, or title
  • Age of the page returned

User profiles are a content type that has the heaviest weight, among all types of content. This results in a higher rank for all user profiles within a Confluence instance. Additionally, newer pages have slightly more weight than older pages. This doesn't confirm whether the page will appear first, rather it will optimize the page to potentially rank higher among other pages.

Having a better understanding of how these variables factor into how Confluence searches items can help you optimize content items and leverage the platform more effectively. 

Topics: blog confluence
3 min read

Metrics that Matter to ITSM Pros

By Praecipio Consulting on Aug 13, 2018 11:00:00 AM

ITSM Metrics 

There's a common saying that you can't manage what you can't (or don't) measure. Often attributed to Peter Drucker, the godfather of Business Management, the thought here is one must clearly define success criteria, establish a benchmark, and track variance in order to realize improvement and/or identify problems. A quick Google search returns articles both lauding and contesting this maxim. In a Forbes article from 2014, Liz Ryan writes, "That's BS... the vast majority of important things we manage at work aren't measurable, from the quality of our new hires to the confidence we instill in a fledgling manager." She continues to explain that by focusing too much on the numbers, companies often miss out on the big picture. 

While it's true there are intangibles in business and IT that are difficult to measure, there are several clearly defined metrics that can be reported on easily in Jira Service Desk. Personally, I'm a fan of measurement. I believe the acts of defining goals, baselines, and tracking variance bring about a shift in psychology that naturally increases the probability of achieving successful outcomes. Listed below are three important IT Service Management (ITSM) Service Level Agreements (SLA) and some links to Atlassian articles explaining how to implement them using Jira Service Desk.

MTTR: Mean Time to Resolution 

The R can stand for Resolution, Restore or Recovery. Whatever the translation, this metric generally measures the cycle time of unresolved issues. This can be measured as an SLA in Jira Service Desk, and reported on in a number of different ways.

Here's an article from Atlassian on how to do this: How to calculate Average Time to Resolution SLA for Service Desk

FCR: First Call Resolution

Also called First Contact Resolution, FCR measures the percentage of issues where the customer's needs are fully addressed within the first call or first contact with support. FCR is closely related to other metrics:

  • FCR and CSAT (Customer Satisfaction): Customers tend to be more satisfied when their issues are resolved within their initial call to support. It makes sense - they don't have to wait and check their email or the portal regularly to see issue updates. They just call support and their issue is resolved as a result.

  • FCR and CPT (Cost per Ticket): When FCR goes up, Cost per Ticket goes down. One of the key reasons for this correlation is that you have the customer on the phone or in the chat session. Capitalize on the opportunity of synchronous communication with the customer. In many cases, the support agent will need more information or will ask the customer to perform troubleshooting steps in order to resolve the issue. Having the customer available shortens the amount of time the agent dedicates to the ticket, lowering the MTTR as well as CPT.

For more information on the importance of FCR, see the Atlassian blog article: Why first-call resolution (FCR) matters.

CSAT: Customer Satisfaction

At the end of the day, it's all about customer satisfaction. Without customers, there would be no services to manage. Jira Service Desk has a built-in CSAT collection functionality that is easy to set up and extremely effective. Jira will send out a questionnaire on issue resolution to collect a score and record comments from the customer. 

Atlassian shares more about Collecting customer satisfaction (CSAT) feedback.

TL;DR

  • Metrics are important and they're here to stay.
  • Keep in mind, however, that they're only a proxy to the real thing. The better you define the success criteria, the goals, and the measurement logic - the closer you'll get to measuring the real thing.
  • The three metrics above are extremely important and there are links to how to set them up in Jira Service Desk
Topics: jira blog itsm
3 min read

The Intranet is Dead!

By Praecipio Consulting on Jul 27, 2018 11:00:00 AM

Over the past few years, we have worked with a variety of organizations to help design and build intranets. The majority of these organizations were moving away from sites that were built on Microsoft’s SharePoint stack, and were looking for custom designs to better meet business needs. From creating intranets from scratch to simply offering a new look and feel, we have seen it all, and we know what works well and what doesn't. And we have noticed commonalities between organizations looking for an intranet solution. Organizations often share the same goals and challenges, and all can agree that the idea of building an intranet can seem daunting. 

Most organizations have common goals that include:

  • Improved collaboration between teams/departments

  • Improved searching for resources within the organization

  • A one-stop-shop for employees to consume relevant company information and applications

  • Corporate identity 

  • A system that's easy to update and maintain

These organizations also have common challenges:

  • Complicated customizations 

  • The need to find experts that work with development after the instance has been running

  • Integration with other tools 

  • Mobile access 

Yes, there is a solution. No, the Intranet is not dead. It is evolving.

Instead of the intranet serving as just a database, it can serve as a social and collaborative platform with the ability to archive information and documents. Having a knowledge base as an intranet can help organize documents and information in a hierarchical structure.

Intranet solutions based on Atlassian's Confluence can help users and employees locate and view information faster and use applications relevant to their roles and responsibilities – allowing businesses to publish information for their employees on a need-to-know basis and allow restricted access that is dependent on groups. An intranet is an efficient way to provide easy access to all authorized users within the organization, even on a global scale.

While Confluence can serve as an intranet and knowledge base for organizations, it falls short in meeting the 'Intranet 1.0' and 'Intranet 2.0' requirements, nor does it try to. Luckily, there is a solution. Linchpin, a fully personalized collaboration hub, focuses on modern team collaboration (Intranet 2.0) as well as the classic intranet (Intranet 1.0), and is based on Atlassian's Confluence.

The Linchpin suite adds modern intranet features at a lower cost on an easy-to-use platform. It was designed for large companies needing to communicate far and wide. Linchpin allows management the ability to distribute important information top-down with customization options for content dissemination. Linchpin turns Confluence into a modern, collaborative, user-friendly intranet.

Why Linchpin?

  • Integrates top-down communication aspects of large companies ("Intranet 1.0").

  • Reduces complexity through personalization based on language, location, department, etc. 

  • Improves social features by adding microblogging and beefed up profile pages. 

  • Integrates other enterprise applications making it the web cockpit for all things digital. 

  • Builds on a system your people already love and makes it the foundation of your intranet. 

  • Saves you tons of license fees compared to the usual intranet suspects (Sharepoint, JIVE, Salesforce, etc.)

With Linchpin Mobile, organizations can now bring the entire intranet to the palm of their employee's hand, no longer requiring them to be at their desk or in the office. The mobile feature allows all employees to stay connected, informed, and up-to-date on the latest company news, no matter where they might be. Employees can even customize the content they receive, search for colleagues, allow notifications, share pages, create collaborative works spaces, and more!

As organizations have the need for employees to collaborate and communicate, the intranet will be alive and well. To learn more about Linchpin and Confluence, check out our upcoming webinar.

Topics: blog confluence implementation consulting-services
4 min read

Save Millions in a Matter of Minutes with Jira Service Desk

By Praecipio Consulting on Jul 23, 2018 11:00:00 AM

Automation saves teams from the monotony of repeatable processes. More importantly, it saves businesses time and money. According to a recent report by our partner Splunk and Quocirca, organizations face an average of 1,200 IT Incidents every month. Using automation to reduce the time it takes to resolve these incidents is a no-brainer. In this article, we'll describe how you can implement time and cost saving business process automation rules in a matter of minutes using Jira Service Desk.

Out-of-the-Box Automation with Jira Service Desk

Many tasks are iterative, time-consuming and potentially prone to error, and are therefore great candidates for automation. Jira Service Desk (JSD) offers out-of-the-box automation functionality that can be configured in the Project Settings of your JSD project. Some of the preconfigured automation blueprints allow teams to set up rules that can do the following:

  • Close resolved issues after a period of inactivity
  • Re-open issues when a customer comments on a resolved issue
  • Transition issues between 'Waiting on customer' and 'Waiting for support' statuses on comment
  • Notify agents when issues are at risk of breaching SLAs
  • Triage email requests based on keywords 
  • Update linked issues when related issues are transitioned or edited

Jira Service Desk also enables Custom Rules to automate business processes that are outside the predefined scenarios. 

 In the Jira Service Desk interface, users can easily add parameters for triggers, conditions, and actions to create custom rules.

The logic follows a WHEN → IF → THEN formula with the following options:

When (triggers):

  • Comment added
  • Comment edited
  • Issue created
  • Issue resolution changed
  • Status changed
  • A linked issue is transitioned
  • Participant added
  • Organizations added to issue 
  • Approval required
  • SLA time remaining

If (conditions):

  • Issue matches (JQL)
  • Comment Visibility (internal/public)
  • User type (customer, not a customer, agent, not an agent)
  • Comment contains (key phrase)

Then (actions):

  • Transition issue
  • Add comment
  • Alert user
  • Edit request type
  • Edit issue
  • Webhook
  • Send email

Automation in Practice

Setting the priority of incoming incidents

The Priority field in Jira can (and should) be used to help triage incoming incidents upon creation. That being said, exposing the field to Service Desk customers is usually not a good idea, as most people tend to over-emphasize the priority of incidents affecting them. One of the best ways to set the Priority field is to use one or more data points to automatically set it while the issue is being created. We helped a Fortune 15 Technology company implement a Prioritization Matrix that calculated (among other things) the custom fields Impact and Severity to set the priority of the issue. 

  • The field Impact can be used to measure the number of users affected with values such as 1, 2-10, 11-50, 51-250, 251-1000, 1001+. These values could also be represented in words such as "I am impacted", "My team is impacted", "My organization is impacted", "The whole company", or for customer-facing incidents, "1 user impacted", "Several users impacted", "All users impacted". 
  • The field Severity can be used to measure the degree of impact. Some standard values that we've seen used for this field are, from least to most severe: "Enhancement", "Inconvenience", "Normal", "Critical", and "Blocking."

A similar solution is described in more detail in this Atlassian Support article: Calculating priority automatically

Save Millions–Really?

“The average cost of IT downtime is $5,600 per minute. Downtime, at the low end, can be as much as $140,000 per hour, $300,000 per hour on average, and as much as $540,000 per hour at the higher end."

Gartner

According to Gartner, “The average cost of IT downtime is $5,600 per minute. Downtime, at the low end, can be as much as $140,000 per hour, $300,000 per hour on average, and as much as $540,000 per hour at the higher end." Using the average downtime cost of $5,600 per minute, the average company hits $1,000,000 in just under 3 hours. So, yes, millions are at stake and the costs can add up very quickly.

Almost any reduction in mean-time-to-recovery (MTTR) can represent a cost savings, and a quality service desk can help achieve those savings. The Jira Service Desk automation functionality is intuitive to use and the short time it takes to implement will pay dividends by saving your employees time and by avoiding lost revenue by resolving IT incidents more quickly. 

Learn more about how Jira Service Desk is the right ITSM solution for you. And if you're already using Jira Service Desk but need to maximize your investment and implement ITIL best practices, we can help.

Topics: jira atlassian blog assessments optimization consulting-services itsm
2 min read

Jira Service Desk: Accelerator vs. Custom Implementation

By Praecipio Consulting on Jul 23, 2018 11:00:00 AM

Once organizations make the decision to adopt Jira Service Desk, they often choose one of two implementation options: they either do it themselves or engage a consultancy for a custom implementation—neither of which is ideal for any but the largest enterprises. Few organizations have the skillsets to do the work in-house, and a custom implementation can be both pricey and time-consuming. Fortunately, there’s a third option: An Accelerator implementation by Praecipio Consulting.

There are distinct differences between a traditional Jira Service Desk implementation and an Accelerator implementation by Praecipio Consulting. To choose the best implementation method for your organization, it’s important to understand how the options differ as well as your organization’s requirements.

Let’s look first at a traditional implementation. Because of the scope of a Jira Service Desk implementation, an experienced consulting firm will work iteratively to ensure your satisfaction throughout the process. The consultant(s) will meet with your stakeholders daily to gather requirements and demonstrate the previous day’s deliverables. With the right consulting firm, this process will result in a top-notch Jira Service Desk deployment that meets your exact needs. However, the deployment will take several months.

A traditional implementation is ideal if your organization requires:

  • Multiple, complex workflows
  • Heavily customized workflows
  • Heavily customized interface
  • Flexibility

A Accelerator implementation is also performed in an iterative manner. However, the scope of the project is much smaller. Instead of building out complex custom workflows, the project provides prescribed configurations based on ITIL best practices. Our team applies its extensive experience to build out industry standard workflows with improvements that we’ve identified over the past decade. As a result, we deliver a Jira Service Desk implementation in just three weeks with workflows that are a step above the textbook recommendation.

An Accelerator implementation is ideal if your organization requires:

  • Rapid delivery
  • Basic workflows such as service request, change management, and incident management
  • Minimal time spent configuring using prescribed methods and schemes
  • Deployment based on industry best practices
  • A solid foundation for future growth and/or customization

The bottom line: An Accelerator implementation allows you to trade customization for speed of delivery and cost. Many small and mid-sized organizations make this trade willingly as they have little need for heavy customizations. If this sounds like you—or even if it doesn’t—our consultants would be happy to discuss our implementation options with you. Check out praecipio.com to learn more about our Accelerator options and other ITSM resources.

Topics: jira blog assessments itsm jira-service-desk
2 min read

Five Signs You Can Forgo A Custom Jira Service Desk Implementation

By Praecipio Consulting on Jul 23, 2018 11:00:00 AM

Implementation

In many walks of life, the word custom is synonymous with time and money. This is particularly true of technical solutions, and Jira Service Desk is no exception. It’s not unusual for a Jira Service Desk implementation to result in an intensive months-long project involving significant resources for the development of custom workflows. If that doesn’t sound ideal, you’ll be relieved to learn that there’s another option: A Quick Start implementation by Praecipio Consulting.

Quick Start implementation is exactly what it sounds like. We get you up and running with Jira Service Desk in weeks rather than months, allowing you to realize a speedy return on your investment and reduced time to value. Instead of reinventing the wheel, we take our baseline best practice implementation and tune it further to fit your organization's needs.

So how do you know if this approach is best for you? Here are five signs that you can safely forgo a fully customized Jira Service Desk implementation and realize the benefits of Quick Start implementation by Praecipio Consulting.

1. You’re not looking for bells and whistles.

Jira Service Desk is touted as an enterprise-grade service desk platform. But the nice thing about it is you don’t have to be a large enterprise to take advantage of its benefits. If you know you don’t need extra customizations, don’t let a large consulting provider tell you otherwise. You can still realize Jira’s value by implementing common workflows that we have developed for other organizations over the last decade under ITIL best practices.

2. Your service organization is small, new or both.

As service desk organizations grow, their workflows tend to become more complex, and Jira’s flexibility is an advantage. However, if your organization is small, new or both, you probably only require basic workflows. Don’t worry—you can always take advantage of Jira’s flexibility later when you have a business need to evolve your workflows.

3. You want to adopt ITIL—but haven’t a clue where to start.

As a framework of best practices for delivering IT services, ITIL aligns IT services with the needs of the business. While Jira Service Desk is ITIL certified, it requires careful oversight and expertise to implement. The out-of-the-box workflows require some tweaking to enable you to fully realize ITIL’s benefits—but there’s not a lot of variation from one implementation to another. A well-experienced consultancy can implement ITIL-compliant workflows without significantly increasing your implementation time or cost.

4. Your organization has a low-risk tolerance.

Every project has some risk associated with it. It stands to reason that the longer, more complex the project, the higher the level of risk. If you can’t afford to wait months to use Jira Service Desk “in the field” and demonstrate success, then you need a Quick Start. Once you realize a quick win with an industry standard implementation, then you can go back and expand your implementation. 

5. Your organization lacks the necessary resources.

A custom implementation is great if you lack the necessary skills in-house, but it won’t necessarily remove the burden from your staff. Their input will be needed to determine what workflows are needed and how they should be customized. Relying on these resources for several months can have quite an impact on productivity and morale.

If any of the above are true for your organization, then we encourage you to consider a Quick Start implementation. Our number one goal is your success and we are committed to helping you realize your goals. Contact us and we’ll help you determine if a Quick Start is right for you.

Topics: jira atlassian blog assessments implementation optimization process-consulting consulting-services itsm
3 min read

Five Things to Love about Jira Service Desk

By Praecipio Consulting on Jul 17, 2018 11:00:00 AM

Over the years, Praecipio Consulting has developed and implemented service desk solutions for a range of clients using Jira's powerful out-of-the-box capabilities and a few key add-ons; however, there was always something missing. When Jira Service Desk was first introduced, we were excited to see Atlassian embracing their customer (and partner) feedback. Over the few short years it has been in the market, Jira Service Desk has revolutionized the way teams serve their customers both internal and external. If you couldn't tell, we're in love with Jira Service Desk. Here are five things to make you fall in love with it too. 

Customer Portals make requesting help easy

Jira Service Desk provides customer-friendly portals to assist your customers in creating Requests. The portal can be configured to speak your customer's language while providing Agents pre-set information describing the customers' issues. Give your request types custom names and icons while mapping them to existing Jira issues. Add your company's branding, color schemes, and flair to personalize your Portals. These customizations look great and are a great way to automatically triage and resolve your customers' requests.

Approval tracking and visibility

Visibility is key when it comes to approvals. By assigning an Approver to an issue, Agents can see who needs to approve Requests at each step. Approvers will be listed on the Agent view as well as the Portal along with the details of what they're approving. Once the Request has been approved, this decision will be recorded with the ticket and can be referenced at any point during the lifecycle of the work. This helps everyone keep track of the official stamp of approval.

Handy Automation

Jira Service Desk has many out-of-the-box automations to trigger different steps in your workflows. Using automation to facilitate interaction between Customers and Agents stops support Requests from getting lost. Since a Request can almost always be 'Waiting on Customer' or 'Waiting on Support', you can use automation to transition between these two statuses when someone comments on the Request. When the ticket is 'Waiting on Support' and the support team asks a question in a comment, this Request can automatically move to 'Waiting on Customer'. Never worry about tickets being forgotten again! If you don't see what you need, create a custom automation rule using simple When, If, Else, Then logic to automate everything from a Notification to a Workflow Transition. 

SLAs that work for you

Service Level Agreements (SLAs) should help increase visibility into how a team can best work together, not something that adds pressure to situations outside of your control. Configure SLAs so that they are paused when a ticket is 'Waiting on Customer' or 'Blocked'. This lets you understand how your team is working while measuring performance in a fair, practical way. Using Jira Query Language (JQL), tune your SLAs to a specific Customer, Request type, even Priority or Severity to ensure your team meets or exceeds your Customer agreements. 

Confluence Knowledge-Base Integration

Integrate your Confluence knowledge base to help your customers fix their problems before they're submitted to the team. While a customer is typing in a request name, Confluence uses SmartGraph (tm) to suggest articles that relate to the request. The suggestions could be articles with similar words in the title or articles that other Customers have clicked on while submitting similar requests. Customers can self-serve and ultimately finish what might have gone through the entire support process. This saves the support team time and helps the customer get their problem fixed right away.

While there are many more reasons we love Jira Service Desk, these five things make us here at Praecipio Consulting fall in love with it even more every day. If you haven't experienced this for yourself, contact us for a demo or visit our collection of ITSM with Jira Service Desk Webinars here. We're more than happy to share the love. 

Topics: jira atlassian blog itsm jira-service-desk
4 min read

Five Ways to Make a Collaborative Team Space in Confluence

By Morgan Folsom on Jul 16, 2018 11:00:00 AM

While creating a space for your team in Confluence may seem like a simple undertaking, creating one that users actually want to interact is far from easy. We know what can happen when you miss the mark: you've got a team space, but it's a mess - nobody knows where to find anything, there's no consistent structure, and nobody actually uses it. It’s not hard for a space to become a documentation black hole - documents enter, never to be seen again.

Here’s the good news: creating a team space doesn’t have to be difficult or time-consuming. With the right structure and out-of-the-box Confluence tools, you can easily create a space for your team that you don't have to bribe them to use.

5 Steps to a Collaborative Confluence Team Space

1. Create a landing page

The first page that you see when you go to your team space needs to be clear and appealing. If the space’s landing page is too cluttered, your user's eyes will glaze over before they get any useful information out of it. On the other hand, if the page is sparse with no useful information, why would they keep going?

For your landing page, you want to include information about the space: this is where you can throw in a bit of basic information about the team and its members, but you ultimately want to focus on what will be useful for your team. Using a Children Display macro on this page can give users a better understanding of where they can find information in the space as a whole. You can determine how many layers to show, and even include excerpts of the pages below. Similarly, you can link to commonly used pages or provide some navigation hints customized to your space. Now that you’ve got users in the space, you want to make the rest of the experience just as clear.

2. Establish a hierarchy

We recommend thinking about setting up the space as people will look at it - what do they see first? The top-level pages - so start there. They could be anything (and everything) from projects or training to team building. You’ll want to make sure you include any information you want your team to know, without flooding them with a ton of first-level pages. 

You can empower users to build this space with you by using the Create from template macro to help enforce your hierarchy. Including the macro on a high-level page allows your team to click a button to create the right page in the right location (if you customize your space templates, these pages can even include the correct macros and labels you need to report on them in other places). Once you've got an idea of how you want the space to be structured, you'll want to address the ever-important content that lives within the space (that's why we're here, isn't it!). 

3. Make it easy to find information

There are several things you can do right off the bat to keep users engaged and ensure they have what they need to do their jobs. Using the space shortcuts on the sidebar can call out commonly used pages - either in Confluence or external pages. Confluence also has some built-in macros that can improve your content with little effort:

Your pages look great, but who do you want to see them?

4. Restrict what you have to

Confluence allows permissions to be set by space and by page. This means you can lock down individual pages that may be more sensitive, and open up the important ones for viewing and/or editing by the team. Be careful not to lock the space down more than you need to - space and page permissions are great for security, but don't let them be a barrier to collaboration.

Once your space is set up, the next step is about keeping it simple.

5. Cut out unnecessary information

Knowing what doesn't belong in your team space is as important as knowing what does. We've all seen the overflowing wikis, filled with personal user notes or docs that have been around longer than you have. Personal spaces in Confluence are there for a reason - users can track information that isn't relevant to the team in their own space, without filling your space with irrelevant information. Archive information that isn't relevant anymore - Confluence pages track when they were last updated, and using the Attachment macro lets you track that for all of your space attachments as well.

Now you're ready to build out an awesome Confluence team space. Say goodbye to documentation black holes and e-mails from your team asking where to find information and hello to easy collaboration!

Still have questions? Let us know.

Topics: blog confluence consulting-services
4 min read

DevOps ROI: Streamline Processes, Improve Outcomes

By Praecipio Consulting on Jul 3, 2018 11:00:00 AM

Investing in technology should be exactly that: an investment. Technology should accelerate your business and allow you to deliver products and services to your customers more quickly. In a word, DevOps. At Praecipio Consulting, not only do we help organizations adopt DevOps best practices, but we work in it every day with our products and even within our services organization. Investing in the right technology to drive your DevOps initiatives should net you a significant ROI, but why?

At Praecipio Consulting, here's why we believe in DevOps:

  • Deliver value faster and more efficiently
  • Deploy more frequently, fail less, and recover faster
  • Unleash the power of high performing employees

But how do you measure the ROI of that investment? Start by measuring the bottom line of your employee's impact.

You can measure the potential impact of savings and value by calculating the Cost of Downtime and Cost of Excess Rework happening in your organization. DevOps helps companies reduce waste by eliminating costly hand-offs and rework. The best way to measure this impact is to calculate these costs and establish a Key Performance Indicator (KPI) that focuses on reducing these costs. First, let's look at how these two are calculated:

Cost of Excess Rework

Cost of Excess Rework = Technical staff size × Average salary × Benefits multiplier × Percentage of technical staff time spent on excess rework

At a moderately performing small- to medium-sized business with 250 engineering staff, times $105,000 average salary, times an average benefits multiplier of 1.5, times 22% of technical staff time spent on excess work equals $8.66M (cost of excess rework) *

250 * 105,000 * 1.5 * 22% = $8,662,500

Rework can come in many forms: Defects, missed requirements, unused or poorly written tests or test cases, repetitive manual actions, etc.. While there is no way to completely eliminate rework, there are ways to reduce it through the automation of processes in key points of your DevOps lifecycle. Assuming the Technical Staff size, average salary, and benefits multiplier are fixed, the reduction in the Percentage of technical staff time spent on excess rework will have the greatest impact in moving the KPI to reduce this cost. Review your current manual or repetitive processes and automate them. Even small changes can make a big impact. If we reduce the rework percentage by five percent: 

250 * 105,000 * 1.5 * 17% = $6,693,750

That's a reduction in cost of $1,968,750! 

Cost of Downtime

Cost of Downtime = Deployment frequency × Change failure rate × Mean time to recover × Hourly cost of outage

At a moderately performing organization that features 32 deploys per year, times 38% in change failure rate, times 2 hours mean time to recover, times $500,000/hr cost of the outage, equals $12.16M. (cost of downtime) *

32 * 38% * 2 * $500,000 = $12,160,000

While you instinctively know that downtime is expensive, you also know that downtime is inevitable. Instead of implementing complicated or burdensome change control processes to eliminate this risk, focus on the change failure rate. While there are other ways to reduce costs by reducing the mean-time-to-recovery, which we address here, allowing teams to continuously deploy to production-like environments automatically means a reduction in the change failure rate. As we saw above, even a small change can make a big impact. If we reduce the change failure rate by five percent: 

32 * 33% * 2 * $500,000 = $10,560.000

That's a reduction of $1,600,000!

Keep in mind, the examples above are based on a moderately performing organization. These are ‘on average’ numbers, and it is important to take the costs of your organization and apply them to these formulas. The costs will only go down as performance increases when you streamline processes and adopt DevOps.  Also, remember that every organization is different, and every organization has its own business model, but you get the idea.

Knowing these formulas will help you establish a greater cost savings and a higher value proposition to your organization and customers. You need to start looking for the right tools and training to make your technology transformation a reality.

What could your organization do by recovering this lost time and resources?

  • Allow additional brainpower to be dedicated to innovation? DevOps training, with proper implementation, will increase your organization’s productivity and create a culture of high-performing, innovative teams.
  • Purchase tools that allow for tighter integration and automation? DevOps tools, when using agile methodology, work best to track planning, building, continuous integration, deployments, operations, continuous feedback and team collaboration. Giving a better view of the Big Picture. 
  • Deploy quality products and/or services quicker, with fewer bugs? High performing DevOps teams deploy 200 times more frequently with 2,555x faster lead times.
  • And the list goes on…

Knowing how to determine the cost of downtime and excess rework are two key factors in calculating your DevOps ROI. Add this to the right tools and training and you have a formula to streamline processes and improve outcomes while saving on cost.

The Praecipio Consulting formulas:

Tools + training = process improvement

Process improvement = cost savings and increased value (goal)

Our knowledge and expertise of DevOps processes and the Atlassian Suite can help our clients operate more efficiently, at a lower cost, and with greater results. Our time-tested delivery model ensures you see measurable ROI from your Atlassian tools.

Looking to make a DevOps transformation? Contact us today.

* = 2016 DevOps Data Report

Topics: blog devops optimization consulting-services
4 min read

Reduce the Pain of Outages with Jira Service Desk

By Praecipio Consulting on Jul 3, 2018 11:00:00 AM

During an outage, if you feel like your computer is on fire, chaos is abounding, and the world is coming to an end, it's typically a good sign that your incident management process could use a bit of tuning. Gartner indicated in a now-famous blog post that an outage typically costs an organization $5,600 per minute of downtime. An hour-long outage at that rate can cost an organization nearly $350,000. As Amazon or Knight Capital will tell you, that number can be significantly increased if it occurs in a revenue-generating system. 

IT teams must find a smart, stable response and resolution to these incidents, usually very quickly in hopes of calming down a manager doing his best Vernon Dursley impression. With the myriad of tools available, at Praecipio Consulting, we've seen IT teams develop creative solutions to acknowledge, respond, and ultimately resolve downed services and systems. But like most processes, we've also seen overly-complicated procedures requiring messy integrations that are unreliable, at best. The key to managing an outage gracefully is to understand not only that the system is down, but ownership, recovery procedures, and communication. 

At Praecipio Consulting, we typically see three big inhibitors IT teams face in reducing downtime:

  • working in multiple systems 
  • alert overload 
  • lack of communication and visibility

Working in Multiple Systems

As microservices become more prevalent in IT organizations, ops engineers are frequently required to work in several disparate systems, resulting in costly context switches that impact productivity. In addition to the (very expensive) wasted time that this incurs, information can be lost in the transition. An effective solution is a single system with several integration points, where information can flow into and be actioned on. Reducing the need for context switches helps users retain information and provides a single source of truth. As a bonus, after the incident is triaged and resolved, the information on how the incident was resolved is all in one location.

This is just one of the many reasons we love the Atlassian products. Jira Service Desk, in combination with Confluence as a knowledge base, can serve as the central location for all things outage. Whether or not the creation of a request is triggered automatically or manually, the creation of a central ticket where the team can swarm, communicate, and collaborate is essential in dealing with the outage quickly. Coupled with the knowledge base filled with Standard Operating Procedures, the IT team can reduce the chaos and confusion of an outage and move toward resolution. Notifications can be sent automatically through Jira Service Desk to any interested parties using Filter Subscriptions and the root cause analysis can be shared via a page in Confluence. 

Alert Overload

There are a plethora of wonderful monitoring tools in the market today providing a wealth of information to system engineers. The problem is that during an outage, we don't want to wade through a mountain of data to figure out what happened. Instead, we need a way to reduce the noise and get straight to the source of the incident.

Enter companies like Moogsoft, who specialize in aggregating all of that data and sifting through it to identify cause and effect. Building out timelines of when certain alerts were triggered and applying machine learning to identify patterns can greatly reduce the time it takes to get to a root cause.

Of course, an integration into your single system for work is critical. The information should funnel in automatically, thus enhancing the system instead of pulling users away from it. Integrating alert systems into Jira Service Desk to trigger the creation of an Outage, running out of disk space, or even access alerts is invaluable to an IT team looking to respond and resolve as quickly as possible. 

Lack of Communication and Visibility

We spoke with a client recently who was reminiscing on 70-person emergency bridges, recalling how chaotic and comical they were. After a good laugh, we were glad he was able to reminisce on those times, as for many IT teams this is still an all-too-real part of the job. 

We prefer systems that provide an integration with a collaboration tool and enable a user to proactively reach out to the right support. Ideally, once we're in the communication and collaboration stage, relevant information has already been gathered to a single ticket. Spinning up a chat room from that ticket, and then using an application like xMatters to proactively alert the on-call members of the right support group, enables us to quickly and effectively get the right people looking at the issue. When integrated with Jira Service Desk, the chat room is created via the click of a button and if integrated with an asset management tool such as Insight by Riada, the right people are automatically notified and can join the conversation. 

Connecting the right people with the right process in the right tools empowers IT teams to quickly and effectively address incidents. While we all know incidents are painful, the process to identify, work on, and resolve them doesn't have to be. Having a mission control system that intelligently handles alerts, allows for proactive notifications, and promotes collaboration can drastically reduce the time spent working incidents. 

How we can help

If you're interested in learning more about how you can establish your own mission control system, give us a call. We can assess your current toolchain configuration and provide next steps on how you can move forward with the technology you have, or help you find the tools that work best for your team. 

Topics: jira atlassian blog assessments process-consulting consulting-services itsm
2 min read

Less Meetings, More Collaboration

By Praecipio Consulting on Jun 26, 2018 11:00:00 AM

https://www.atlassian.com/blog/teamwork/types-of-meetings

Have you ever been in a meeting and thought, "Why am I even here?" and then started daydreaming or doing other work on your laptop? After meetings that drudge on and on, it's easy to leave them more confused than when you started.

Meetings are the worst! Of course, there are tons of tips on how to run an efficient and productive meeting, but how about being more efficient and productive by NOT scheduling meetings. Skip them! Well, not really. There are situations where a meeting is necessary, but many of our daily meetings are pointless, calendar-eating blocks of time that we will never get back. 

Atlassian tools offer so many different ways to facilitate collaboration without sitting around a table at a specific time of day, requiring people to be engaged. Everyone's workloads are scattered throughout the day, and asking them to align priorities during a very specific block of time is not necessarily the best way to get people to collaborate effectively. Instead, creating a Confluence page focused on a specific topic - providing an outline of the work items that need to be addressed.  'Mentioning' your colleagues with the @mention feature notifies them about changes to the page, and they can collaborate when it works best for them. If a specific approval is needed from management, or if you need a colleague's feedback, you can leave an inline comment, which will notify them of your request or comment. If more discussion is needed, any team member can create a Stride room, that references the Confluence page. This will allow team members to actively collaborate on the topic. The communications can happen at a faster rate, allowing for more depth conversation (without a meeting).

This method will encourage and promote engagement with your remote employees and give them a seat at the table (so to speak). If the topic requires inputs from others not originally part of the conversation, it's easy to add them to the Confluence page or Stride room. They can quickly read the conversation and get up to speed.

Many people have a tendency to conclude meetings with no structured outcomes, deliverables, or expectations of team members. When you are using Confluence as your collaboration tool, it's easy to create tasks directly on the page. Since all Atlassian tools can be very transparent, team members are more accountable for completing the follow-up on time. In this example of a Confluence template for meeting notes, you can quickly add team members to a page, capture goals and discussion items and assign tasks:

Ditch the meetings – let those calendars breath – give people their time back, and do it all while accomplishing more, in less time. 

Topics: stride blog
3 min read

Mitigate Risk with Secure Content for Confluence

By Praecipio Consulting on Jun 26, 2018 11:00:00 AM

Sensitive information and the security of that information is becoming increasingly critical for organizations across the globe. GDPR, PHI, HIPAA, PCI, and other sensitive information legislation has had a profound effect on what information can be stored where and who can access this information. At the same time, the need for centralization and collaboration for disparate teams has also increased. At Praecipio Consulting, we believe balancing the need for security with collaboration is a critical concept in content management. Secure Content for Confluence Server and Data Center helps users store and manage sensitive information while balancing Confluence's powerful content collaboration. 

As the number of users and amount of content begins to grow in Confluence, security becomes almost impossible to manage. As teams are encouraged to collaborate, the need to protect sensitive information such as passwords, data, reports, etc. also grows. While restricting pages can be a solution to protecting sensitive information, the ability to scale Space or Page content restrictions becomes impossible. Manual intervention from a Confluence or Space Administrator is required or, in the worst case scenario, sensitive information is unintentionally exposed putting the organization at risk. The more the users use Confluence, the more challenging content organization becomes. Without the use of the Secure Content macro, we've seen teams use page restrictions, complex page trees, page or excerpt include macros to manage confidential information. The downside to this approach is the lack of structure it creates inside of Confluence. If there are several restricted pages created separately from the page discussing the primary topic, not only does this make the content severely disorganized, it introduces an unnecessary risk of accidental exposure of sensitive information. In order to prevent clutter inside Confluence spaces and mitigate risk, Secure Content protects sensitive information inside the relevant page eliminating the need to create or reference additional pages. 

Secure Content for Confluence Server and Data Center can mitigate this risk with its inline content encryption and robust, yet flexible, permissions. To ensure content is only visible to authenticated users, Secure Content blocks are encrypted before being stored in the database and are only decrypted when an authorized user provides their Confluence credentials. The Secure Content block evaluates the password and if it matches the user's Confluence password, it will authorize the user to either read or read and edit the content inside the block. Additionally, Secure Content uses symmetric AES encryption with a key that is determined when the plugin is first installed. This key is inaccessible even if a user has access to the Confluence Database itself. 

In addition to the encryption functionality, assigning permissions for a Secure Content block helps the owner of the block manage the visibility of each user or user group. There are two conditions that must be met before content is decrypted and displayed for a user or group. First, the user/group must successfully be authenticated using their Confluence password to access the block. Second, the user/group must have permission to read/edit content in the block. Aside from the owner of the block, who will always have read/edit permissions, both conditions must be met to give users entry into the protected content. 

Every Secure Content block is assigned a key. A Secure Content key is a self-made unique identifier that allows users to add the block on different pages with the same properties as the original block. This is especially useful for organizations that have hand-offs between teams. For example, an operations team may provide 24/7 support for their internal or external customers. During an incident, credentials to access or reboot a system can be easily shared in a central location and perpetuated to both business-hours operations personnel and off-hours operations personnel. This prevents sharing of credentials through unencrypted channels such as text message or email. It also prevents duplication of effort, allowing users to spend more time troubleshooting and resolving the issue. 

Combining security and collaboration, Secure Content for Confluence Server and Data Center is the perfect solution to managing sensitive information while leveraging the powerful collaboration abilities in Confluence. It relieves the administrative burden of managing Space and Page restrictions and mitigates the risk of exposure of sensitive information. It allows organizations to maintain an organized content structure without compromising the security of critical systems or personnel. Secure Content makes managing sensitive content inside Confluence organized and protected. Try it free from the Atlassian Marketplace here

If you run into issues with your Secure Content macro, please contact support@praecipio.com for troubleshooting help or information on Secure Content. 

Topics: atlassian blog secure-content-macro consulting-services
2 min read

Three Weeks to an ITIL-based Service Desk—No, Really

By Praecipio Consulting on Jun 12, 2018 11:00:00 AM

If you’ve attempted a Jira Service Desk (JSD) implementation on your own or reviewed proposals from consulting firms offering to do the work, chances are a three-week implementation sounds pretty far-fetched. But I assure you, not only is it possible—it’s something we do regularly.

Jira Service Desk is a highly regarded service desk platform. When an organization decides to implement the platform, they’re often eager to leverage its flexibility and enterprise-grade capabilities to increase team productivity, meet demanding service-level agreements, and improve customer satisfaction. Just one thing stands in the way: implementation.

Most organizations consider two options for implementing Jira Service Desk. They either do it themselves—provided they have the proper skillsets—or they hire a consulting firm to do the work. For some, implementing Jira Service Desk is not always as simple as it looks, and organizations that choose the do-it-yourself option are often disappointed several months later when they aren’t realizing the platform’s full benefits.

Engaging with a consulting firm may seem to be the logical choice then. However, this isn’t the best option if you hope to see a return on your investment sooner rather than later. An experienced consulting firm will work iteratively, meeting with stakeholders daily to gather requirements and demonstrate the previous day’s deliverables. With the right consulting firm, this process will result in a top-notch, custom-built Jira Service Desk deployment—but it will take several months.

If you do not have the time and/or budget for a customized implementation, then you might consider a Quick Start implementation by Praecipio Consulting. We have over a decade of experience with successful service desk implementations using Jira, and we have taken this experience to build schemes that deliver a faster implementation based on ITIL best practices. With a Quick Start implementation, we get you up and running with a functional Jira Service Desk implementation in just a few short weeks.

Come On. Three Weeks?

Yes! Two critical factors make a Quick Start implementation possible. The first is the fact that most ITSM organizations don’t need heavily customized workflows. In fact, what most service organizations need is a properly configured service desk that meets ITIL best practices. By forgoing unnecessary customizations and implementing Praecipio Consulting's Quick Start, we can significantly reduce deployment time and, subsequently, the costs associated with it.

The other piece of this, of course, is expertise. Based on our 10+ year, varied and extensive experience working with companies of all sizes, we can give you exactly what you need and nothing you don’t. We have taken real-world application and experience with industry-leaders to implement JSD and ITSM/ITIL based on best practices to provide companies with processes that are a step above the textbook recommendation. As a provider that knows ITIL, Praecipio Consulting can deliver an industry-standard implementation of Jira Service Desk—with lighter customizations to make it yours—in half the time it takes for a traditional deployment.

Some organizations, unfortunately, never realize the benefits of a Jira Service Desk adoption because they get stuck in the implementation phase. Don’t let that be your fate.

Download our white paper to learn more about our Quick Start implementations or give us a call at (512) 266-8271.

Topics: jira blog implementation process-consulting consulting-services itsm jira-software
4 min read

Using Scrum and Kanban Boards to Improve Communication

By Praecipio Consulting on Jun 12, 2018 11:00:00 AM

The ability to 'see the big picture' and have a clear understanding of the work teams complete is something our clients ask for often. With a product like Jira Software, anything is possible; however, there are tools within the project management software platform that are built specifically to help users stay in the know and track project statuses. 

Out-of-the-box, Jira comes equipped with three powerful task boards that teams and managers can use to manage projects and gain better visibility into the work being done: Scrum board, Kanban board, and Agility board.

Tracking issues on a board will open up views into the work that you're looking for and they are simple to set up.

Step 1: What do you want to see?

Step 2: Board Selection

Step 3: Share and Use 

Step 1: What do you want to see?

It's common for organizations have a lot of issues in Jira, but do you need to see all of them, every day? Probably not. The first step in setting up a board is to understand what it is you want to see. Boards can be built to import every issue from every project, or by a JQL filter, which can display a very specific set of results. Using a filter is traditionally more useful and manageable. Either way, it's important to understand the scope of your board to make sure that when you're looking at it, you are only seeing the items that are important to you. You can use one, or a combination of these approaches. Keep in mind that an issue can live in multiple boards, and any updates that are made to an issue will appear on any board where the issue is displayed.

Step 2: Board selection

Jira offers three boards that you can choose from (assuming that you are on Jira Software): Agility, Kanban, and Scrum. Even though they seem very methodology-specific, choose the board that works best for you and/or your team - and it's not just for software or development teams.

Kanban Board

Kanban is all about continuous flow. With this in mind, there are a lot of different uses for this board such as a team that is not practicing scrum or a project manager who wants to visualize the work happening on their project. Recently, Atlassian added the ability to have a backlog option for Kanban boards which will allow you to specify a status that would represent work that it's quite ready for prime time.

Pro tip: Define your swim lanes to organize your work. By default the swim lanes will be set to look at priority but there are a variety of options to split your work into meaningful views.

Scrum Board

Scrum promotes commitment to a subset of work for a specified time period. The Scrum Board focuses on looking at your backlog of work and pulling issues into sprints which the team will focus on completing in a specified period of time. If your team has a sizable task that they are trying to parse into manageable chunks of work, this may be the board for you as it allows users to focus only on the subset that you've committed to for that period of time.

Pro tip: Check the "Days in Column" option found in the "Card Layout" section of the board configuration to ensure your work flows appropriately. 

Agility Board

Agility boards are the newest boards in Jira Software. They're perfect for teams that want to quickly jump in and get started and don't require any complicated configuration. This is a great board selection for projects that may be looking at a single issue type or if all issues follow the same workflow. 

Pro tip: If your Jira Project is for simple task tracking, use a business project and use an Agility board. Its simplistic design is perfect for the Executive with too little time and no "technical" skills.

Step 3: Share and Use

Now that you've chosen (and hopefully created) your board, make sure to use it as a communication tool. Too often we see boards created but not used during meetings with team members. There is a lot of power in seeing the work displayed for the team so everyone can have a complete understanding of what the progress looks like on a continuous basis. The more you use the boards to communicate progress, the better the information will be as its submitted to the board.

Pro tip: It's important to note that when you share the board with others, you need to make sure that your filter is shared with those who will need to view the board. 

Now that you have a better understanding of what the boards can do for you, go out and create a few for your teams. Experiment with different board views to see what works best. If you're still not sure, contact us! We help teams in every industry make the most of their Atlassian tools and business processes.

Topics: jira blog scaled-agile process-consulting consulting-services jira-software
4 min read

How Our Marketing Team uses Jira and Confluence to Stay Agile

By Praecipio Consulting on Jun 12, 2018 11:00:00 AM

As a marketing professional, I had a limited exposure to Jira before I joined Praecipio Consulting. Praecipio Consulting is an Atlassian solutions partner, and now, I eat, sleep, and breathe the Atlassian toolset. But before I really knew what it was, I used Jira Software to collaborate with a distributed team on a project. It was an interesting experience using Jira, because this was a ticketing system for 'IT guys and coders,' not for precious marketing professionals - right? I had been happy - or at least at peace - with using Microsoft Project, Sharepoint, One Note and Excel spreadsheets, along with Customer Relationship Management (CRM) and marketing automation software. But when I saw my first kanban board, and how easy it was to create, organize and visualize work in process, I thought this was a great way to begin an agile marketing shift.

While I'm still getting used to an all Atlassian world, I'm excited to share with you how ticketing software, originally designed to track software bugs, along with other Atlassian tools, have shown me a path towards an agile marketing future. So, here's my 101-level guide to using agile methodologies and tools to manage marketing projects.

Marketing Tasks = Jira Issues/Tickets

Think of your marketing activities as Jira Issues. For example, say you're hosting a webinar next month. Login to Jira, create a new epic for the webinar, give it a name, provide some additional details (the sky is the limit, you can customize the kind of information you want to capture) and click save. 

But wait. A webinar has a lot of subtasks within it: you also need to set-up a landing page, attach a form, create thank you emails and internal notifications, schedule the speakers, write a script, create the presentation, setup dial-in info, and a lot more. You can add all of those tasks, too, under the webinar ticket and create a nice, tidy place to track all activities. And, just like marketing automation tools that let you automate repetitive actions, you can create a Webinar Issue template that generates all of these recurring tasks each time you plan a new webinar, saving a lot of time and repetitive work.

There's a lot of work up-front to set up your tasking, but once you've done it you can continuously improve and become increasingly efficient and fast only making small adjustments.

Tracking Assets and Tasks 

Now that you have a task list of marketing activities, you have to create the actual assets. You write email and web page copy. Your designer creates beautiful graphics. Your digital folks create tracking links and create a home for all this precious content to live. Confluence gives you a place to create or simply store these assets in a single repository. And you can link the individual tasks from Jira to these pages in Confluence, giving you immediate, bidirectional access between tasks and the actual work product. This is pretty handy and makes team collaboration a breeze.

Again, you have to do some advance planning and preparation to make this work seamlessly. But it's worth the effort in the long run.

Using a Kanban Board

With marketing activities and their related subtasks entered into Jira, and a place to house your marketing assets, you can start managing a project. What should the team be working on first? Where are we on the case study copy? Is Elaine finished with the banner ad artwork? A Kanban Board lets you see where these tasks are in their lifecycle, from "Backlog" to "In Progress" to "Complete" (you can customize these labels, as well). At a glance, you can see how much work is done, how much is in flight, and what's coming up. Do you think the white paper project is more important than the brand guidelines update? Move the brand guidelines to the backlog and focus on the white paper.

With a Kanban board (and even other boards, like Scrum and Agile), you can adjust your work priorities instantly, making it easy to see who is doing what and when it will be done. Ultimately, agile boards help teams improve communication and collaboration.

Plan Alignment

Kanban boards are super cool, as are scrum boards. Portfolio for Jira, too, can help you create a marketing roadmap to visualize all your projects over time and track resource availability and capacity. Once you've got your marketing ducks in a row, Portfolio will allow you to not only visualize a plan the way you've designed it but also create variations. That's pretty dang neat! Admittedly, there's a lot of work required to make the best use of this tool. But again, once your organization is actually organized, your project management can become amazingly powerful and useful.

Now what?

Now, we've learned that Jira is a powerful tool that welcomes all - not just software and IT teams. And if you didn't know about Confluence or any of these awesome planning tools, you owe it to yourself to consider them for organizing your marketing plan. If you're interested, start by checking in with your IT or software development teams. Chances are, they are using Jira and possibly Confluence right now. There's your starting point. And if you want a demo, or to purchase licenses, or need help getting started, let us know!

Topics: jira blog scaled-agile confluence
4 min read

Agile Batch Size: An Ode to Laundry

By Praecipio Consulting on Jun 4, 2018 11:00:00 AM

One of the most difficult concepts to explain in agile is the concept of Batch Size. It's a principal tenet of Lean Product Development and is an ACTUAL principle in SAFe (# 6 to be precise). However, when we work with our clients to evaluate their practices and processes, we see product backlogs in the scrum boards of hundreds of items. In one case, a client used the concept of a Groomed Sprint to define what part of the Backlog had been groomed and prioritized by the Product Owner, Scrum Master, and Team.

What we have here, folks, is a failure to right-size Batch Size. 

I've been thinking about this for a while. What is the best non-Agile example of Batch Size? It wasn't until I discussed it with my husband for the 4th time in two days that it clicked: laundry. 

Laundry is something we all need to do, but don't enjoy. And work is that way too. Sometimes we have a great laundry day: it's not on the floor, it's not stinking up the bedroom(s), it's moving through without being the only thing we accomplish that day. It's a good laundry day. Sometimes, though, it's a horrible laundry day. It's been put off so long that it's almost overwhelming: it's everywhere and is likely the only thing that's accomplished that day. Picture this: it's laundry day at your house. Individual piles are consolidated into a Big Pile. The Big Pile is sorted into smaller piles according to color, fabric, and cleaning products. The smaller piles begin to make their way through the system one at a time. 

I know what you're thinking: Amanda, we all know how laundry works. Bear with me. 

A smaller load of laundry requires less time per batch to both wash and dry. If you've ever flown into a blind panic when realizing you need clothing for the next day and have washed a single set of clothes, you know what I'm talking about. It takes less time for the washer to fill, agitate, rinse, and spin than the extra large load. In addition, it takes much less time to dry a single set of clothes than a whole dryer full of jeans. However, this is wasteful. It wastes energy and water and time because you still have that Big Pile you have to deal with at some point. And you know you do and you will. At some point. Before your husband decides to drag three laundry baskets across the house. And they're full of jeans and work shirts. <sigh>

Thinking about the above scenario another way, instead of lumping everything together into the Big Pile, why don't we pre-sort? Doesn't that make a smaller batch size and make it easier to flow through the system? Yes, but also no. Pre-sorting does take some of the handling out of consolidating laundry into the Big Pile by making smaller batches. However, those small batches can add up to a Big Pile if not adequately moved through the system when they're ready. 

What if, instead, we right-sized the batch? What if, based on the color, fabric, and cleaning products, we put the batch through the system when it was determined to be the right size? Not so big that the Big Pile must be broken into smaller batches to flow through the system, but not so small that we're wasting resources including, the most precious resource of all, time? It's time to right-size your laundry. Just as it's time to right-size your work. 

Within any agile framework, this is the essence of throughput. When requirements come to the Team in a Big Pile, the Team must break the Big Pile into consumable smaller batches. These batches must also be prioritized: clothing needed in the next day, versus clothing needed next week, versus something you've worn once and likely won't wear again for a few weeks or until a special occasion. Just as we prioritize our laundry, so too must we prioritize the backlog. What is the immediate need? What can wait a few weeks? What is a nice-to-have? Note: in the extended metaphor, nice-to-have is dry cleaning. Not something you need, but sits on a hangar in your closet, is reassessed as an outfit every three months, and ultimately placed back in the closet in favor of the clean laundry. So too should those nice-to-haves be removed from the backlog to be addressed every once in a while to see if there's a current need. Either put them back in the closet or donate them. Deprioritize items in the backlog or remove them altogether. 

How can you tell the batch is the right size to move through the system? Much like laundry, it's trial and error and feedback into the system. You didn't come into this world knowing how to do laundry. And there have been plenty of times that you've accidentally thrown a red sock into a load of whites or bleached something in your darks or even shoved too much into the washer only to have to run the dryer three times to get it adequately dried. So what did you do with this information? You learned from it. In fact, you retrospected on what you did and learned from it. I see what you did there, Amanda. So too will the Team learn from each batch of work that flows through the system. Within a retrospective, the Team should look at their batch size estimates and make adjustments for future work. This allows the Team to establish a predictable velocity with which to plan future work. Much like you've figured out how to do laundry efficiently over time (hopefully). Either way, it all comes out in the wash. 

Topics: blog scaled-agile process-consulting consulting-services
3 min read

Achieve GDPR Compliance with the Atlassian Stack

By Praecipio Consulting on May 25, 2018 11:00:00 AM

What is GDPR?

If any of your partners, employees or customers are citizens or businesses in the EU, its time to review your company's compliance strategy. The General Data Protection Regulation (GDPR) is a new European Union privacy standard that mandates the ability for someone to have access to their personally identifying information (PII) and have the ability to change the information or "be forgotten" by requesting the removal of that data. These requirements can make achieving backward compliance standards very difficult. This new privacy law will impact everyone, from C-level executives to new hires and likely every department to include Human Resources, Information Security, Compliance and more. Regulations surrounding GDPR will affect most organizations, large and small, regardless of whether your business does business directly in the EU.

With the right tools and know-how, companies using Atlassian products like Jira and Confluence can not only achieve forward compliance by the May 25, 2018 deadline but also attain assurance that pre-existing content is compliant as well.

Why GDPR?

GDPR was designed to strengthen and unify data for European Union residents, regardless of where their data is used, processed, or stored. GDPR essentially legislates a lot of common sense data security ideas, like minimizing the collection of personal data, deleting personal data when no longer necessary, restricting access, and securing data through its entire lifecycle. But compliance violations can have costly consequences including Fines and penalties Your organization can face damaging penalties of 4% of annual global annually or 20 mil. euros. 

The GDPR Checklist

Backward compliance

Praecipio Consulting has over 11 years of expertise in Atlassian products alone. As an Atlassian Platinum Partner, we have full-service solutions ready to go to get your organization's pre-existing Atlassian application data within GDPR compliance quickly and confidently.

Praecipio's Solutions Consultants come armed with the tools to identify, review, and address the content that may not be in compliance throughout your Atlassian stack. We will conduct a thorough scan of your application's existing data to include all version histories. We produce reports that help your teams identify violations, use that feedback to improve and refine our search algorithms to ensure the highest level of coverage possible.

  • Identify: we use tools and techniques developed in-house to locate potentially non-compliant data within JIRA, Confluence and other Atlassian applications.
  • Review: We then provide a detailed analysis and report of our findings and conduct a thorough review of potential violations with your team.
  • Address: Praecipio then incorporates findings from the review into further refinement of identification and generates an execution plan to redact pre-existing content to ensure compliance of your legacy data.

Maintaining Compliance in Confluence with Secure Content 2.0

Once your data is fully reviewed and in compliance, you'll need solutions to keep it that way. After all that effort and expense, you don't want to be one Confluence page edit away from a violation. For Confluence, Praecipio Software offers Secure Content 2.0 to easily secure and limit access to sensitive page content. We use 256-bit encryption to ensure any new content will not expose your organization to penalties in the future.

Your organization can invest considerable time and expense to get your Atlassian data GDPR compliant, but you'll need the tools to keep it that way. Praecipio Software's Secure Content Confluence App, available on the Atlassian Marketplace, gives your team an easy and safe way to store content securely that is both encrypted and with granular-level access control. This means sensitive data is securely encrypted on your database and access set by the author at the group or even individual level.

Secure Content is designed for robust security and ease of use. Ideal for shared, sensitive content such as passwords, data, reports - anything you need to restrict access to; anything that would likely fall under the 'identify and remove' GDPR regulation requirements.

Features Include:

  • Owner Report macro: See all your Secure Content in one place. Drop it on any page and be a click away from all of your Secure Content across the entire Confluence instance for time-saving administration and editing.
  • Transferable ownership: Control of Secure Content blocks can be optionally transferred by the Confluence administrator if needed. Or the owner can lock it down to make sure they maintain complete privacy and control, even from Confluence administrators.
  • Implicit rendering: Less sensitive but still protected data can be optionally made to render automatically with the rest of the page content but only to Authorized users.
  • Access request: Non-Authorized users can request access with a single click, alerting the content owner immediately for action via Confluence notifications.

Custom Compliance Solutions

Praecipio Software's custom development solutions can be engaged as well to address your organization's unique GDPR data security and compliance concerns.

Topics: atlassian blog assessments confluence process-consulting secure-content-macro consulting-services
2 min read

Turbo Kit for Jira and the Case of the Missing Millions

By Praecipio Consulting on May 21, 2018 11:00:00 AM

https://www.praecipio.com/jira-jql-turbo-kitSmall errors can cause big problems. In 2007, a car dealership hired a promotions firm to mail 50,000 scratch-off tickets to potential customers, with one lucky winner designated to receive a $1,000 prize. However, the first 30,000 tickets were all mistakenly printed as winners, adding up to a $30 million mistake. Obviously, the dealership was unable to honor the pay-out, and instead offered $5 gift cards to the numerous lucky winners.

Perhaps a comma in the wrong place caused the prize value to skyrocket? Whatever the reason, this error was caused by inaccurate data.

Data Accuracy is Important

Data accuracy is important, and while Jira provides a solid foundation for data collection, Turbo Kit for Jira can enhance your data with field validation

As agents and customers are entering information into a Jira issue, key data points will need to be stored correctly for future retrieval.  For anyone working directly with customer issues that refer to a specific item number (e.g. policy, product, part, account) it's necessary to be able to lookup the ID of the specified item. Collecting the ID, however, isn’t always a straightforward task, and often involves multiple conversations with the customer. People will often leave fields blank, enter the wrong type of ID reference, or enter a number with a typo, and many other errors that contribute to data inaccuracies. 

Turbo Kit for Jira offers field validation ensures that people provide the right information. Organizations typically have standardized formats for their ID numbers, often consisting of a string of letters and numbers with a specific number of characters. By checking the count of numbers and letters entered into the field, Turbo Kit for Jira can validate that the ID is formatted correctly before it's submitted.

Validated Data Will Show You the Patterns You Care About

Reporting is huge. Identifying trends in the information that's reported on can help your organization recognize what is and isn't working and where energies are being focused.

If you're curious about what type of insurance policies have the most associated issues, you can filter issues based on the insurance policy field. Maybe you'd like to see how many open tickets related to the newest insurance policy 'NEW1234'. But if half of the tickets had 'NEW-1234' written in the Policy custom field, the extra dash could prevent these tickets from showing up in a search. If all of these ticket policy numbers are written in the same way, you'll be able to query the entire set in a search. Turbo Kit for JIRA and its field validation enables these reporting conditions so you can get a more accurate picture of what's happening in your organization.

Mystery Solved, Case Closed

Is your company able to survive a $30 million mistake? Do you want to end up a cautionary tale because you didn't enforce data validation and other data best practices in your Jira instance? It's elementary, my dear Watson. With Turbo Kit for Jira on the scene, the data mystery is solved and this case can be closed.   

Download a free trial today to see how Turbo Kit for Jira can help protect your organization. 

Topics: blog process-consulting turbokit consulting-services
5 min read

Project Estimation - Story Points vs. Hours Estimation

By Praecipio Consulting on May 21, 2018 11:00:00 AM

Work smarter, not harder. Easier said than done.

However, in agile software development, there are some things teams can do to begin working smarter and more efficiently. 

Many companies still estimate the amount of time a project will take in hours. But this approach, typical of the waterfall methodology, can lead to cost overruns and missed deadlines. "(Humans are) terrible at estimating how long something is going to take. We're just not good at it," said Christopher Pepe, Chief Technology Officer at Praecipio Consulting. "But what we are good at is estimating the relative sizes of things." And so he makes this point in his story above on story points vs. hours, and why companies should adopt this agile concept of planning and managing development projects.

But first, what is a story point? According to Dan Radigan in his article The secrets behind story points and agile estimation, "Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100." Story points provide an abstract way of understanding how complex a project is, and how much work a project will take. 

In a comparison between agile and waterfall time estimates, Steve Cooke at Swarm Online writes "The reasoning behind using points rather than hours, is that it might be difficult to estimate in units of time at speed. Also, the speed at which the team can deliver points of effort will depend on the skills of the individuals in the team. Team A might not be as fast as Team B but the relative size of the stories remains the same."

If you want to know more about how using story points could help your team with project estimation, reach out to us today. 

 
 
 
Video Thumbnail
Video Thumbnail
 
 
 
 
 
 
 
 
 
 
 
 
 
Topics: blog scaled-agile process-consulting
2 min read

How ChatOps Can Connect Your Remote & Traveling Workers

By Praecipio Consulting on May 3, 2018 11:00:00 AM

Have you ever missed a deadline because your team couldn’t get aligned? Maybe a key team member was traveling, or you spent too much time discussing the plan instead of implementing it. Have you ever tried to “rally” through email? It starts out with good intentions; but 43 messages later, someone was left off the thread, and you’re trying to determine action items by sifting through a lengthy email chain.

Connecting the dots in email is one thing, but working with distributed teams adds to the complication. According to The State of the Remote Job Marketplace report, 3.9 million (2.9%) of the US workforce works remotely at least half the time. Historically, employers required workers to be local or work in the office 5 days a week. This requirement has shifted over time, as employers have taken advantage of new communication technologies to connect their workforce. But with a geographically dispersed team, how do you ensure they are working together effectively and efficiently? The answer is ChatOps!

So, what is ChatOps? And how can it help your organization collaborate effectively and efficiently?

ChatOps is a “collaboration model that connects people, tools, process, and automation into a transparent workflow.” Using a chat application like Atlassian’s Stride will centralize and streamline your discussions, planning, and action items; while improving the following areas:  

  1. Swarm on an Issue – Instantly connect with team members in chat rooms to discuss needs and action items. Include your traveling teammates in the discussion by using the Stride mobile app.
  2. Decide on a Clear Path Forward – Real-time decisions can be implemented and assigned in Stride using the Decisions and Actions functionality.
  3. Resolve Issues Faster – Centralizing your discussion in Stride will quickly determine objectives, cutting down on unnecessary cycles.
  4. Ensure transparency – Tasks (Actions) are tracked in Stride and visible to others. Team members can view what tasks are pending or completed, and how it impacts current workflows.

No matter where your teams are located, you can increase your productivity by embracing the ChatOps philosophy and using Stride. If for no other reason, do it for the Giphy App.

Interested in learning more about ChatOps? Contact us today.

Topics: stride blog implementation process-consulting
2 min read

It's About People...

By Amanda Babb on Apr 3, 2018 11:00:00 AM

Clients and potential clients ask us what sets us apart from other Atlassian Solution Partners. While I hate answering this question as I have good relationships with people from other Solutions Partners, I love the answer we have at Praecipio Consulting. 

We're people people. The relationship is the most important thing to our success. While we're working on the cutting edge of technology every day with every client, at the end of every day and every engagement, we're still focused on the people. The goal of every engagement is to make life just a little easier on the people through good process, well practiced. 

We're officially wrapping a nine-week engagement this week with a long-term client. This particular client has come back to us several times throughout my career here at Praecipio Consulting. The relationship and trust we've built with these folks have gone a long way to establishing both business and personal relationships around not only mutual interests but genuine caring about each other as people. 

This week, though, I was humbled by the other people I appreciate, but often overlook. When you stay at the same hotel for ~ two months, you get to know the staff as well. In particular, two employees stood out to me, not only for their excellent customer service, but their own openness and willingness to have conversations, debates, asking how the project team is doing, accommodating last minute changes, and making sure we were taken care of in whichever small ways they could. It's about the people and these two people showed us that what we drive with our clients is the right thing to do. 

Today was particularly poignant as this was my last night at this hotel. As a small gesture of my appreciation, I bought a simple bouquet and split it to give each of them a thank you for taking care of the project team. Not only taking care of the project team, but during a particularly arduous week, taking goofy pictures, discussing Netflix series, sharing their excitement of going to a Cavs game for the first time, or the excitement of the premiere of Black Panther. To put it plainly, they treated us like people...not consultants. 

At the end of the day, it's about people. It's about our day-to-day interactions with people that make what we do so amazing. Good days or bad days, people are people: interacting as a person and not as a title can bring great things to clients and friends. I, for one, am super proud to know these two amazing gentlemen and sincerely thank them for all they do!

Topics: praecipio-consulting blog teams human-resource
1 min read

Praecipio Consulting is First Atlassian Solution Partner in New Relic Navigator Program

By Praecipio Consulting on Mar 19, 2018 11:00:00 AM

Praecipio Consulting was recently named one of the first New Relic Navigators in New Relic's Partners Program. As an Atlassian Enterprise Platinum Solutions Partner, Praecipio Consulting has also developed strong partnerships and expertise with a variety of complementary technologies, like New Relic, to ensure its customers are implementing the most effective solutions.

The New Relic Navigators Program was designed to help organizations interested in using New Relic to drive speed and visibility for joint customers with cloud migration best practices.

The program required Praecipio Consulting sales, delivery, and support team members to become trained and certified as New Relic Certified Performance Pros, learning all there is to know regarding the New Relic platform and how to build its capabilities around services for cloud migration and application performance monitoring.

Praecipio Consulting, founded in 2006, is a business process management and technology consulting firm leveraging the Atlassian toolset to deliver first-class solutions for DevOps, Agile, and IT Ops practices. Praecipio Consulting services include process and technology consulting, managed services/hosting, and product and software development. As an Atlassian Platinum Solutions Partner and process expert, Praecipio Consulting leverages the best technologies and methodologies to enable true DevOps transformations.

Topics: blog new-relic process-consulting itsm
12 min read

Custom Macro Parameters with JavaScript

By Praecipio Consulting on Mar 12, 2018 11:00:00 AM

Introduction 

Custom macros are a popular, supported, and versatile addition to any confluence page. Confluence users are able to use macros by making their own, searching the macro library, or by getting access to additional macros through add-ons. If you are making your own macro through an add-on, you will know that the parameter types, aka fields, are limited to the following: 

    • boolean - displays a check box.
    • enum - displays a select field.
    • string - displays an input field (this is the default if unknown type).
    • spacekey - displays an autocomplete field for search on space names.
    • attachment - displays an autocomplete field for search on attachment filenames.
    • username - displays an autocomplete field for search on username and full name.
    • confluence-content - displays an autocomplete field for search on page and blog titles.

Using JavaScript and Soy templates, you are able to inject custom parameters into a macro. The following tutorial is an example of a custom field injected into a basic macro form. The goal is to create a multi-select drop down menu comprised of static predetermined menu items. Note- JS functionality to create a multi-select list and the CSS are not included. 

 

Steps for injecting an element into a macro 

Building the macro

Example code of plugin.xml 

<xhtml-macro name="macro-list" key="macro-list" class="your.class.name"  documentation-url="#"
             icon="/path/to/yourPic.jpg">
    <category name="external-content"/>
    <parameters>
        <parameter name="User" type="username"/>
        <parameter name="Page" type="confluence-content"/>
        <parameter name="StatusSelect" type="string"/>
        <parameter name="Status" type="string"/>
        <parameter name="Width" type="percentage" default="100%"/>
        <parameter name="Max Results" type="int" default="30"/>
    </parameters>
</xhtml-macro>

 

Macro prior to injecting content

*Note: The "Status" parameter is not visible in this image. That is because the element is hidden with CSS. More on why the element is hidden in the JavaScript section. 

 

Configuring the Soy template multi-select code

{template .multiSelect}
    <div class="status-container">
        <div class="closed-status-margin status-selected-container macro-input-fields text">
            <span class="aui-icon aui-icon-small aui-iconfont-arrow-down select-icon" onclick="toggleStatuses()"></span>
        </div>
        <ul class="status-list hide-statuses">
            <li value="created" onclick="statusSelect(this)">Created</li>
            <li value="deleted" onclick="statusSelect(this)">Deleted</li>
            <li value="sent" onclick="statusSelect(this)">Sent</li>
            <li value="correct" onclick="statusSelect(this)">Correct</li>
        </ul>
    </div>
{/template}


JavaScript injection

JS code with explanation

//Run function on ajaxComplete to capture edit macro view.
$(document).ajaxComplete(function() {
    //looking for the macro-list macro to start running
    if( AJS.$("table[data-macro-name = 'macro-list']")){
            //must verify that the MacroBrowser is available to prevent errors
            if (AJS.MacroBrowser) {
            //override command that selectes the ds macro and the field/s selected
            AJS.MacroBrowser.setMacroJsOverride("macro-list", {
                fields: {
                    //calls anonymous function on string fields
                    "string": function (param) {
                        //checks specifically for the string input we want to inject to
                        if (param.name == "StatusSelect") {
                            //calls our function with the input's selected string param
                            return handleSpacesLookup(param);
                        }
                    }
                }
            });
        }
    }
});
//globally available but only called if the above criteria is met
function handleSpacesLookup() {
    //grabbing the div that surrounds our selected input/param
    var paramDiv = AJS.$(Confluence.Templates.MacroBrowser.macroParameterSelect());
     
    //create a variable for our desired template
    var docStatus = path.to.your.template.multiSelect();
     
    //setting a variable to the paramDiv that corresponds to our desired input area via ID
    var select = AJS.$("#macro-param-div-StatusSelect", paramDiv);
     
    //adding our docStatus element to the selected div
    paramDiv.append(docStatus);
 
    //return the selected/created element to the macro
    return AJS.MacroBrowser.Field(paramDiv, select);
};
  
//Functional logic for the multiselect not included.
 

Completed front-end example with JavaScript

Why is the Status Parameter Gone? 

The drop down multi-select captures the user's selection on the front end. When passing the macro form information back to the server via the preview or the save button, the Status Select format is not readable. To make sure that your information is able to be parsed, you may insert relevant information into another macro field. In this case, the user's responses are sent to the hidden Status parameter each time he/she makes a change to the StatusSelect. On save or on preview, only the hidden information is sent to be parsed. 

 

Potential Issues 

  • I only see an empty field when opening the edit macro, I can only see my field when reloading the page with the editable macro, OR I am getting null variable errors. 

    This may be a JS async error, which could explain some inconsistencies. Make sure that this JS file is accessible to the page, that functions are properly nested, and that the initial if clause is triggered as expected. The edit screen and dialog boxes are not connected to a page reload so queries done "on load" of the page will not be caught at this point. Use .ajaxComplete or an event trigger to re-run necessary functions. 

  • My new element works but now I am missing functionality from other parts of my page.

    Make sure that your selectors are unique and as specific as possible. Try to limit using css and JS selectors by the AUI class names as these are repeated through out Confluence. 

  • I am appending my element but only see a blank input box. 

    Your parameter type may limit the content that can be appended to it. For example, select lists cannot have non-option items added to it and will instead render a broken input box. Confirm that your template has the appropriate wrappers if any. You may need to append your template to the container instead of the parameter. 

Topics: blog confluence javascript macros bespoke
3 min read

A Holiday Recipe for Planning Success with Portfolio for Jira

By Praecipio Consulting on Nov 22, 2017 11:00:00 AM

https://www.praecipio.com/webinars/portfolio-for-jira-best-practicesIn our last blog post, we shared with you how Portfolio for Jira can be used to plan and visualize work for any department or line of business. Now that everyone has a seat at the table, let's make sure the meal is excellent by following a trusted recipe for Jira Portfolio best practices.  

There are only two simple ingredients for a successful Portfolio implementation: Jira configuration and data integrity. 

Jira Configuration

It's important to make sure your Jira entities  workflows, projects, boards and filters  are configured correctly. While this may seem like common knowledge, some organizations overlook even the simplest mistakes when configuring their Jira instance - it's important to make sure you cover all the basics early on.

 In addition, Portfolio entities must also be determined, such as hierarchy and parent links, dependencies, and permissions. Portfolio is customizable to fit your organization's needs, and like the importance of making sure your Jira instance is configured correctly, the same goes for Portfolio - its imperative that the time is taken to set up your instance that best serves your organizations needs. 

To start, you should determine a level of organization that is larger than an Epic. If an Epic is 3-5 Sprints, this larger concept should represent a longer timeline: perhaps 6 months. You can call it anything you want, but we commonly use 'Initiative,' which is Portfolio for Jira's native language. With the Epic Parent created, Portfolio's configuration needs to know you're adding a level, and then have it mapped appropriately to the issue type. The next issue type to be created is called a 'Story,' which will include all other standard issue types, and will live between an epic and a sub-task. You can use whatever taxonomy works best for your organization; however, we have one recommendation - keep it simple! 

Adding the 'initiative' level allows your team to not only get a birds-eye view of your entire plan, but also how it aligns with overall business goals

Also part of your configuration recipe is the creation of a scrum board. Boards in Jira Software are driven by filters, and you should group them into a project or project category.  A word to the wise: Don't append your query with clauses that would remove workflow statuses or remove a specific tag of work. Let the board drive what your plan would display. Keep in mind if it's on your board, it's going to be in your plan.

Now that your Jira configuration is cooking with gas, let's dig into data integrity.

Data Integrity

Portfolio brings projects and plans to life; however, its powered by the data inputted into Jira. You've heard the saying 'garbage in, garbage out', right?' Avoid bad data at all costs and follow these simple steps to keep you Jira data clean.

You can start with keeping your backlog groomed by simply resolving and closing your issues. Closed issues will disappear from your backlog and will no longer show on your board, which means the Portfolio won't display them in the plan, either. Not only is this good practice in general for Jira Software, but it will keep your Portfolio plan accurate. If you have a task or issue that has been sitting in your backlog for a year or two, it's time to clean the pantry.

Maintaining hierarchy in Jira software is critical when using Portfolio. You must close out lower-level items before closing the parent - if you complete sub-tasks and close them out, it doesn't mean you're 'in progress' in the hierarchy. No progress will be seen on the story, epic or initiative just because you close or resolve a sub-task. You should be focusing on story completion and story throughput, instead of progress at the sub-task level. Make sure you are closing and completing story level to show progress in your plan overall - again, this will maintain accuracy in planning and forecasting.

Closing your story-level tasks will show your plan's overall progress

This blog post is full, but you can come back for tasty seconds and thirds in the Portfolio for Jira: Best Practices webinar coming up on November 30 at 11 a.m. CST.

Topics: jira blog devops process-consulting jira-software marketplace-apps
2 min read

Thanks to Portfolio for Jira, Everyone Has a Seat at the Table

By Praecipio Consulting on Nov 21, 2017 11:00:00 AM

Thanksgiving is right around the corner, we can't help but think about our favorite things this time of year. We have opportunities to see family, friends and relatives, enjoy good food, and talk about everything that happened throughout the year. It is great to catch up and visit about what's happened, and what's going to happen. It's a time when families and friends reflect, collaborate, and even begin planning for the next year (because all families get along perfectly, right?).

What if you had a holiday table year-round for your organization?

If a project is delayed, or a change needs to be made, wouldn't it be nice to update the entire plan and everyone on the team at once?

Atlassian's Portfolio for Jira is the solution. 

The core of Jira Software is a workflow engine. It allows you to track issues and tasks in a predefined, customizable workflow. Now, take this awesome workflow capability, and lay a forecasting and visualization tool on top of it - that's Portfolio for Jira. Atlassian’s Portfolio for Jira is the road mapping and visibility tool used to forecast and track long-term plans, increasing visibility and business alignment. Portfolio provides a living, breathing plan for teams and leadership to stay up-to-date on existing plans, all while forecasting new long-term plans.

The best part? It's not just for software teams. 

Portfolio for Jira organized existing marketing tasks (entered as issues) into releases and themes, giving our entire team the visibility we needed to stay on track.

Teams that can benefit from Jira Software: 

  • Human Resources
  • Operations
  • Marketing
  • Procurement
  • Legal
  • Sales
  • And more 

Because we track just about everything we do - including marketing activities - in Jira, the marketing team at Praecipio Consulting was able to use Portfolio for campaign planning and execution. As a test case, we launched a product marketing campaign for our newest add-on in the Atlassian Marketplace, Turbo Kit for Jira. Portfolio for Jira helped our team plan, forecast, manage, analyze, track and report on our campaign efforts. 

Change happens – all the time. Portfolio can help you, your team, and leadership stay well-informed on project and planning statuses, and it can also help you see the big picture and track business goals (not just your team or department!). It is the ultimate visibility tool. 

We'll dig into this a little more in our upcoming webinar Portfolio for Jira: Best Practices. Be sure to grab a seat at our table to learn more!

Learn more about Portfolio for Jira in the Atlassian marketplace.

 

Topics: jira atlassian blog marketing plan release training jira-software marketplace-apps
2 min read

Seeking Validation? Turbo Kit for Jira Takes Care of That

By Praecipio Consulting on Oct 27, 2017 11:00:00 AM

Customizing workflows in Jira means taking control of your organization's transactions, but that also means quality assurance becomes critical. Fortunately, Turbo Kit for Jira not only provides the deep customization capabilities for workflow creation and customizing conditions, but also has a variety of validators needed to ensure transitions operate correctly and smoothly.

"The main purpose of a validator is to validate any info before performing any transition, such as moving a ticket/issue in Jira from 'in progress' to 'in review' or 'closed'," said Renuka Joshi, Software Engineer at Praecipio Consulting. "After creating validator in the workflow for specific transition, Turbo Kit checks to see if the value is correct and if the value is present on transition." Jira admins and power users can customize this kind of transition easily with Turbo Kit's JQL validator, comment validator, and modified field evaluator." 

Within Jira Service Desk, when a user transitions a workflow to "In Progress", Turbo Kit is enforcing data entry in the Comments field and Approval Notes custom field. Turbo Kit also enables the custom error message.

Turbo Kit's built-in JQL validator checks for specific conditions on custom fields and other supported fields for a ticket before performing a transition to ensure it works correctly before saving your workflow. For example, if a user writes a JQL function to check that the priority of the ticket equals 'medium', then before performing that particular transition, the function confirm that if the priority is not in that state,  the transition will be blocked. With a test issue key available in Turbo Kit, users can test the validators to make sure the JQL function is correct. "That kind of checking is performed automatically, which helps teams improve their quality assurance efforts," said Joshi. The JQL Validator is also capable of performing RegEx validation with the combination of Regex JQL Function, to ensure format validation on specific fields prior to transition.

Turbo Kit can also help enforce compliance with the capture of required data. For example, when creating a ticket, a user may not always know the required information to collect, such as story points, assignee, priority, etc. Validators built-in to Turbo Kit, however, can help ensure those critical data points are entered prior to the ticket closing by blocking issue transitions when required fields are empty. Error messaging related to these transition blocks can also be modified with Turbo Kit, giving your team full ability to enforce compliance and enhance usability. Examples of this type of validation include the comment field validator, where a comment must be entered into the long text field before the issue is allowed to transition in the workflow.

For more information about Turbo Kit for Jira, register for the in-depth product demonstration webinar on Wednesday, November 8 at 11 a.m. CT. 

Ready to take Turbo Kit for a test drive? Download it today from the Atlassian Marketplace.  

Topics: blog product-services turbokit jira-software
3 min read

Turbo Kit for Jira Makes Workflow Automation (and your life) Easier

By Praecipio Consulting on Oct 27, 2017 11:00:00 AM

Automation is a popular theme for developers, consultants and everyday users of the Atlassian suite, especially within Jira, because it makes your life much easier. There's no shortage of ways to automate processes within Jira, including custom development and the Atlassian marketplace. Even we at Praecipio Consulting have used most or all of these add-ons. That is until we created our own automation tool: Turbo Kit for Jira.

One of Turbo Kit's most powerful functions is the create and set post function. With Turbo Kit installed, an option in the workflow editor allows the user to select the relevant transition. For example, the 'calculate set field values' function enables you to choose “to do,” and then move to “In progress”, and then add a post function. The target field can be a pre-existing custom field or a default Atlassian field, such as description or summary. The target field can be a string, drop-down field, or number field. When selecting a number field – this could be story points or a custom field - the user is able to select from a set of operators to format mathematical calculations. If your business need includes increasing story points on a transition, or increasing the severity of an issue, or decreasing the severity of an issue on transition, all of these (and more) can be automated in advance with Turbo Kit. This can be done to all workflows, projects or issues.

There are many potential uses for the calculate set field values function in Turbo Kit. In this example, a Jira admin is determining a repair cost by performing a calculation using data from the hourly rate, hours and discount fields.

The string feature in Turbo Kit enables the concatenation of strings to facilitate changes to the description field on transition. Turbo Kit users can also add and create a new description field based on content from a different field in a Jira ticket. This lozenge format, familiar to Atlassian users, is leveraged to form a calculation or a string concatenation. In certain examples, users can add their own custom content to that calculation field. 

In addition to number and string fields, Turbo Kit also provides post functions within the workflow for single select field options that recognize the contexts associated with that field. "Here's how Turbo Kit can make life a little bit easier! A Jira administrator needs to change an assignee or a number value associated with an issue on transition," explained Jillian Flook, Developer at Praecipio Consulting. "In some cases, this could be on an importance level or a more nuanced priority level that isn't available within the traditional priority drop-down list. And because the priority list is another field available for transitions with Turbo Kit, a user is able to move up one or down one." Turbo Kit for Jira offers a variety of supported fields, as well as custom fields. And don't worry about your custom fields. They will not be supported by Turbo Kit initially, but you can enter a custom field ID, and quickly view a list supported fields in a drop-down list. By using the custom field's ID, a user can select the sources in the calculation.  

Out of the box, Turbo Kit's supported fields and custom fields provide an enormous range of enhanced opportunities to leverage post functions and making your workflows much more powerful and easier to build. For more information about Turbo Kit for Jira and a closer look at is powerful new features, register for the product demonstration webinar on Wednesday, November 8 at 11 a.m. CT.

 
Topics: blog product-services turbokit jira-software
3 min read

Say Hello to Turbo Kit for Jira (and Goodbye to Unnecessary Add-ons)

By Praecipio Consulting on Oct 25, 2017 11:00:00 AM

We’re excited to announce our newest add-on in the Atlassian marketplace, Turbo Kit for Jira.

Turbo Kit consolidates the features of multiple other marketplace products into a single add-on that provides enhanced search capabilities, additional post functions, and many other features to enhance your Jira instance.

The product's inception was informed by 10 years of field experience directly from our consultants who have implemented, customized and supported numerous, distinct add-ons to achieve the power that Turbo Kit for Jira now provides in one application. Turbo Kit for Jira not only simplifies the implementation and maintenance of a Jira enhancement, but also potentially at a significantly lower investment.

Powerful New Features

Turbo Kit’s key features include JQL-powered issue auto create, JQL functions, a Graphical field calculator and Special input fields, which are described below. 

Validators

Turbo Kit offers a powerful set of validators, conditions, and post functions. The auto create allows users to create new issues on transition based on JQL conditions. No scripting language is required to make this happen, which developers will appreciate.

Functions

Turbo Kit also adds new functions in the JQL function library, including a RegEx evaluator, date comparisons, time in status, status compare, issue link types, members of roles, and epic memberships, just to name a few. These functions not only can help users and administrator create more effective filters to drive dashboards, but can also be used with workflow post functions, conditions and validators.

"My favorite feature is the graphical field calculator and one that I call the most powerful post function ever," said Steve Kling, Principal of Development at Praecipio Consulting. "I’ve been developing in the Atlassian environment more than five years, and I’ve never seen anything quite like this. Turbo Kit for Jira enables selecting a target field, based on either number or string, and providing real arithmetic calculations to create and calculate a field or the ability to string together a new value. And no knowledge of scripting languages, like Groovy, is required."

Special Input Fields

Jira doesn’t ship with any of the masks users might expect, such as SSN, phone number, zip code, or email address fields. Similarly, Jira does not offer out-of-the-box a Regex-based field where formats can be defined. But Turbo Kit for Jira, and its special input fields, enables reinforcement for that type of data entry. This mask provides an additional check to ensure that data entered into a field meets the field's data requirements, ensuring data compliance.

For more information about Turbo Kit for Jira and a closer look at is powerful new features, register for the product demonstration webinar on Wednesday, November 8 at 11 a.m. CT.

Designed for Atlassian Jira 7.0.0. - 7.5.1, Turbo Kit is available for download in the Atlassian marketplace for Server only. In the Turbo Kit for Jira marketplace location, you will find licensing options and pricing information as well as detailed user documentation. Give Turbo Kit for Jira a test drive today!

Topics: blog product-services turbokit jira-software
4 min read

How Samsung does lean ITIL® with Jira Service Desk

By Praecipio Consulting on Oct 13, 2017 11:00:00 AM

October 12, 2017

This is a guest blog written on behalf of Jack Harding, IT Consultant at Praecipio Consulting and Larry Brock, IT Chief of Staff at Samsung Austin R&D Center and Austin AUG Leader. Based on their presentation “The Power of Process: How Samsung Implemented ITIL” at Summit San Jose 2017.


The IT team at Samsung’s Austin R&D Center had the talent to be successful. Yet, there were bottlenecks getting in the way of their efficiency and productivity. Poor communication, lack of visibility, bad process, and unorganized tools were hampering their ability to support the rest of the organization and realize their full potential. Sound familiar?

As an IT organization within a very successful processor design business unit, they realized they needed to do better or they could potentially cost their business unit speed and design quality – the things their reputation was built upon.

 

Samsung’s Austin R&D Center, with the help of Praecipio Consulting, decided to go lean and set up a simple ITIL®  implementation of Jira Service Desk for Incident, Problem, and Change Management processes. Over the course of only 3 weeks, they were able to mitigate those pitfalls and ultimately increase productivity across their IT organization.

What exactly is ITIL and how should my team use it?

ITIL®  (Information Technology Infrastructure Library) is the most widely-used IT service management framework in the world. It’s essential for organizations to align the assets and functions of IT to the overall business. As the de-facto standard for ITSM, ITIL places your organization on the path to deliver the best, customer-centric service management.

The ITIL framework has been developed over the course of 25+ years and the entire library consists of numerous volumes containing thousands of pages of prescriptive process definition. While there is much to be gained from the specification as a whole, sometimes a lighter touch is needed – maybe even necessary. In Samsung’s case, they needed core ITIL processes but also needed to prove ROI quickly.

Before you even decide to implement a framework like ITIL, you should identify your team’s pain points and think about what processes are critical for your IT team. Most teams start with the four key ITIL disciplines, Incident ManagementProblem Management,  Change ManagementService Request Management, and decide which are the highest priority.

Find your pain points

Start by assessing your team. How do they communicate with each other, customers and other teams? Do they have the right processes? Are those processes being followed? Do customers have visibility into their request status? Some of the most common ITSM pain points that IT teams experience are:

  • Process: Processes are often poorly defined or not implemented properly within the tools

  • Communication: Teams work independently of one another and don’t focus on communication outside of their silo

  • Transparency: Customer or partner teams are often unable to see into pertinent processes and work items

Identifying these pain points will help you prioritize which ITIL processes to implement first and how to structure them for your team.

Samsung’s lean ITIL processes

Samsung’s Austin R&D Center had similar challenges. They didn’t have a process for incident, problem or change management, no single source of truth, disjointed communication and a total lack of transparency.

We realized, we have got to do this better than what we’re doing now. – Larry Brock, IT Chief of Staff, Samsung Austin R&D

They already had a clear process in Jira Service Desk for service request management, but none of the other core ITIL processes. They knew they needed structure for incident, problem and change management but needed help to implement them in a lean way. So, Praecipio Consulting helped them take these processes from just theory, to practice in order to see ROI quickly.

Process

The team began to define, publish and follow processes built from their own experience in addition to input and feedback from customers. They also built a multi-faceted workflow allowing for easy escalation of an event into an incident, while automatically generating and linking problem and change issues.

Communication

Praecipio Consulting helped the team create notification templates in order to build comprehensive and consistent messaging into their process. Using queues, they built an attractive change review dashboard with automated removal of stale and abandoned requests. Now, change issues have become the single source of truth regarding what IT has planned, in progress, and completed regarding infrastructure or computing environment.

Transparency

Because changes are now all documented, customers are finding creative ways to access and use this information, including in their own dashboards. The IT change calendar now shows when changes are scheduled and they’ve even seen it layered into Team and Department calendars outside of the IT team.

Evaluating their pain points and creating lean processes to improve productivity has helped them be more transparent within the team, with customers and key business stakeholders and has allowed them to provide better and more timely reporting. The ITIL framework is just that: a framework. It’s up to your team to determine what matters most and how robust or lean you want your processes to be.

Topics: atlassian blog implementation consulting-services itsm jira-service-desk jira-software
3 min read

The Good Place: Dysfunction in the Agile Organization

By Praecipio Consulting on Oct 13, 2017 11:00:00 AM

By Amanda Babb, principal of Process Delivery

It’s been a great first week of the fall season of television. Some of my favorites have been rebooted, my alma mater was featured on a t-shirt,