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
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_4512Both 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_4507This 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_4509HA! 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.

AdminsWe’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
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

Do 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

 

In 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
2 min read

Using Jira Service Management's email functionality for ticket intake

By Jerry Bolden on Feb 8, 2021 12:04:00 PM

Blogpost-display-image_Using JSDs email functionality for ticket intake

Setting up an email account within Jira Service Management (JSM) allows different clients to provide extensive information without using the Portal every time they have a question.  While this is a great functionality within JSM, and quite easy to set up, there are some key items to remember to ensure all works well: things that can be required, setting up the queue, and email addresses do's and don'ts.  

As you set this up, not only will you need an email address tied to an inbox, but it's just as important to have a request type set up in your JSM project. The request type should be hidden from the portal; this way it cannot be selected as an option if someone accesses the portal to create requests. This will give you control and the ability to clearly separate emailed requests from ones created through the portal by other users/customers. Once the request type is set up, you can only require the Summary and/or Description to be set.  These two fields will be pulled directly from the email, with the subject becoming the summary and body of the email becoming the description.  If you try and require any other fields, the request type will fail and the emails will not be processed into requests automatically. 

In conjunction with setting up the request type for the email is setting up the queue for this specific request type.  Remember, you are able to reference the name of a request type in JQL searches. This allows your agents to quickly identify which requests were created via email and not just lumped into the other queues.  Due to some of your requests being created through email, the communication back to the customers is critical to make them feel like the request is being seen. The queue will alert the team when there are incoming email requests, and coupling them with SLAs correctly, will focus the proper communication and solving of these issues consistently. 

Lastly, think critically about the email address you select.  First, the email needs to be specifically used to receive issues from customers; this means it should not be used for mass communication where you also get NoReply email addresses, or mass communication that will cause false tickets to be created.  While you can add certain automation into JSM to look for specific emails and not respond to them, the point of JSM is to allow for ease of administration of a Service Desk of which customer communication is the most critical item. 

Overall, the email request creation for JSM is a great option, which is at times easier for users/customers to use versus going onto a portal.  With the proper configuration and use of the recommendations in this article, the email will function and you can maximize the effectiveness of JSM email requests.  Always keep in mind it is better to have a purposed email address than to reuse one and wonder why some emails work, some do not, and there are loops of comment(s) being sent due to NoReply. 

For any help with this issue, or anything else Atlassian, drop us a line, we live and breathe Atlassian, and would love to help!

Topics: atlassian jira-software email-notifications atlassian-solution-partner jira-service-management
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

"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 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

Why does it seem like only developers have to estimate their time and effort?

By Michael Knight on Jan 21, 2021 10:20:00 AM

Blogpost-display-image_Why does it seem like only developers have to estimate their time and effort-

Nearly a decade ago, as an intern at a now-defunct startup in Austin, Texas, I got a question from a developer that haunted me for years after because I didn’t have a clue how to answer it:

“Michael, why is it that only the developers have to jump through the hoops of estimating our work, spending hours in sprint planning and retrospective meetings and making sure every hour of our day is accounted for and attached to a work item?”

After incredulously wondering how anyone could possibly question the divine and holy agile methodology that I had been zealously learning and implementing that summer, I realized that the developer had posed a wonderful question. Why was it that we only had these requirements for developers? Why didn’t we impose this same process on sales or HR or accountants or any other part of the business? Why wasn’t anyone asking upper management for a timesheet that said exactly what they had worked on every hour that day? I’ve thought about this question for a long time and have built up an answer, or rather a few answers and some capitulations, over the past several years of agile work.

First, development work is hard to understand. Even for developers it’s hard to understand, but for those without computer engineering degrees or years of experience, it’s nearly impossible. How do you explain to someone that developing a section of code that does something seemingly trivial is actually exceedingly difficult and can take several hours?

Second, the work is invisible. You can see code, sure (even if you can’t understand it), but you can’t really see data fetching, processing, rendering, or anything else going on behind the scenes. Coupled with the difficulty of understanding development work in the first place, this poses a serious issue for people trying to understand what’s going on in that bullpen. In contrast, people can see a sales call, an HR training meeting, or an accountant’s spreadsheet and understand quickly and intuitively the value that it brings to the business.

Which brings us to our third and perhaps most important point: it’s important for the business to know what development projects cost. Part of what product managers should be doing is understanding the economics of a given feature, bug fix, or other development effort: how many hours did the team spend writing, testing, rewriting, and deploying this code, and how does that translate to cost?

In my mind, these three reasons sufficiently answered why the business typically loves these processes and imposes them on development teams. But, they didn’t do a good job answering why other teams didn’t tend to have the same processes, often seen as restrictions, imposed on them. After all, isn’t some sales and accounting work invisible and hard to understand? Isn’t it important for the business to understand the cost of HR work? 

Because of this, I’ve come to firmly believe that there are several processes, standards, actions, and overall contributions, usually all attributed to the amorphous “agile”, that every team and business could benefit from. Stand-up meetings, among teams of 15 or less, can be a great way for the team to understand what everyone is working on, reduce duplicate work, and quickly squash problems. Kanban boards (or any similar variants) are wonderful for seeing all of the work in progress, matching different team members to their respective strengths, and prioritizing and organizing ongoing projects. Sprints, or at the very least increments of time which demand continuous planning and feedback, will certainly expose problems and bring about process improvements for a given team. 

It turns out the developer who asked me that question years ago was on to something. The business tends to pick on development teams because their work, in most offices, is the hardest to understand, the least visible, costly, and they’d like to get a better understanding of what’s going on. However, many agile practices would clearly benefit teams across the firm, including and especially those outside of development. Here’s to hoping we see businesses move in that direction in the coming years.

Topics: developers agile
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
2 min read

Using SLAs + Automation to set customer expectations in JSM

By Rebecca Schwartz on Jan 19, 2021 9:51:00 AM

Blogpost-display-image_Using SLAs + Automation to set customer expectations in JSMWhen using Jira Service Management to manage your team's service desk, it's extremely important to ensure that your end-users have a good experience. Otherwise, they may become frustrated with the tool and stop using it to submit requests. With the broad range of clients we serve at Praecipio Consulting, we've found one of the biggest keys to a successful service desk is clearly setting customer expectations and meeting those expectations consistently. Jira Service Management comes with Service-Level Agreements (SLAs) that teams can use to set those expectations and give customers transparency around them. It's important to set reasonable goals for your SLAs, and with automation you can make it easier for your agents to stay on top of those goals so your customers are satisfied.

Here's how:

Automate alerts to agents when SLAs are about to be breached

For your SLAs, it's important to be consistent with meeting the expected goals assigned to them. This allows your agents to build trust with customers and encourages customers to continuously use the service desk for their requests. With automation, agents can be alerted when time is running out on an SLA. For the automation rule, there's a trigger titled "SLA Threshold Breached" that works perfectly in this scenario. This trigger allows you to set when an alert should send to the assignee of the request based on how much time is left on the particular SLA. The assignee is then made aware that they need to make progress on the issue and can stay on top of the SLA goal. This, in turn, leads to a happier customer and an increased sense of trust in your agents. 

Automate alerts to customers if a ticket is pending their response 

It's good practice in a service desk to configure so that if a ticket is pending a response from the customer, a "Waiting for Customer SLA" is set to give them time to respond. If the time passes on that SLA (we don't receive a response from the customer after a certain amount of days), the ticket is automatically resolved. Before we automate this though, it can be helpful to send out an alert to the customer to remind them that the ticket is waiting on their response. I've seen customers become frustrated when a ticket is resolved without alerting them that it was waiting on their response, as they simply forgot about their pending request. Sending out reminders sets clear expectations with the customer that the ticket has not made further progress due to inaction on their end and gives them the chance to interact with the request before it's automatically resolved. Other times, you may not receive a response from the customer because they no longer need your assistance. In these situations, the automation to resolve tickets pending customer action after the "Waiting for Customer SLA" is breached can save your agents time and effort, as they don't have to keep track of the time pending a customer response and manually resolve the ticket themselves.

We've seen so many clients reap the benefits of using automation to help their teams stay on top of their SLAs. Not only does it build trust with customers and in your organization; it also fortifies your service desk and improves your the experiences of your end users and agents! If you need help with SLAs, or anything else Atlassian, reach out and one of our experts will contact you ASAP!

Topics: automation service-level-agreement jira-service-management
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
2 min read

Jira Service Management for HR

By Courtney Pool on Jan 13, 2021 12:58:15 PM

Blogpost-display-image_Jira Service Management for HRIn November of 2020, Atlassian rebranded Jira Service Desk to Jira Service Management. With this rebranding, Atlassian sought to make one thing clear: JSM isn’t just for IT. In fact, any team who receives requests from others, whether from external or internal customers, can utilize JSM.

Similarly, IT Service Management (ITSM) doesn’t have to be just for IT either. IT organizations around the world benefit daily from applying ITSM principles and processes to their own organizations. Enterprise Service Management (ESM) sees this success and seeks to take it a step further, contending that ITSM practices can be applied even outside of IT teams, which allows for similar successes in other departments. JSM agrees, and it even has quick-starts in Atlassian Cloud for some business teams, including HR.

By now, you may have already read about the ITSM capabilities that can be leveraged by your HR department. You may even already have a few use cases in mind. At Praecipio Consulting, one of the most frequent JSM use cases that we encounter for HR is onboarding and offboarding. 

To start, you’ll want to be sure that you have one request form for onboarding and another for offboarding. One of the things that makes JSM great for non-tech teams is the ability to change display names for fields and add help text to forms, making it even easier for people who aren’t familiar with Jira to submit requests.

As onboarding and offboarding are typically handled by multiple teams and individuals, you can also utilize an app to auto-generate subtasks for each Request or Issue Type on issue creation. This is also possible in Jira Core and Jira Software, of course, but having this driven by a request created through the portal means that a user can set it in motion with more ease than they would be able to otherwise.

Queues are another JSM feature that will be helpful for your HR team once a request is submitted. You could set queues up for just onboarding and offboarding, or you could even go deeper, having queues that differentiate between full-time employees, part-time employees, and contractors, as an example. Queues can be set to run on anything you’re collecting in your form.

Once a request comes in, you’ll benefit from the Service Level Agreements, or SLAs, that JSM can apply. SLAs can be set based on any number of criteria, so your HR team can easily track if they’re meeting expected targets, as well as have another way to prioritize their work. For example, a high-priority offboarding will need more attention than onboarding that’s more than a week out, so the SLAs can be set accordingly, with more time afforded to less pressing tasks.

Onboarding and offboarding are common needs in every HR department, but these same features can be applied to most HR tasks you can think of, like PTO requests, asking for assistance with benefits, or even recognizing a colleague.

The rebranding of JSM is a message to all teams, in all companies, that service tools are not just for IT. They can be a huge benefit to many teams, and HR is a great place to start. 

At Praecipio Consulting, we offer a wide range of services for HR teams (or any team, for that matter) looking to use best-in-class ITSM tools. Reach out today and let us know how we can help you make the most out of JSM

Topics: human-resource itsm jira-service-management
2 min read

Confluence Spaces: Rightsizing for Maximum Effectivity

By Brian Nye on Jan 11, 2021 3:45:00 PM

Blogpost-display-image_Confluence Spaces- Rightsizing for maximum effectivity

Your company has decided to make Confluence your collaboration platform, and you've been asked to get this thing going. Where do you start? Don't worry, you are not alone. Trying to figure out what makes up a Confluence space is a struggle that many people have when getting started with Confluence (and even for those who've had it for years). There are two questions that should be asked to help make the decision: What's the purpose of the space and who will be using the content? Once you get the answers, you'll be on your way to setting up the perfect space for you.

What's the purpose of the Space?

Confluence and Jira will be working hand-in-hand to get work done. Because the two applications work so closely together, it is important for the information to be organized in a way that will allow users to draw parallels between the two applications. The best practice is to create a Confluence Space for each Jira Project. By doing this, users are able to create and find information quickly and easily. This mapping will allow users to first create the ideas in Confluence that will relate to Jira Issues as the ideas mature. Confluence can then be the home to the reports of the products or process as the issues are worked and closed. This prevents guesswork from trying to figure out where content should live or where to find information in the future. 

This is not a hard and fast rule, as there may be reasons for having multiple spaces for a single Jira Project, but those should be edge-case scenarios and not the norm. It is highly recommended that users do not create a space based on a single user or group's access permissions. Confluence Space permissions, along with page restrictions, can often satisfy the need to keep information segregated. There may be times that one Confluence Space represents multiple Jira Projects when the projects are closely related. If this is is the case, be sure that the structure is clear so users can find the information quickly.

Who will be using the content?

Spaces don't always need to have a related Jira Project in order to created. Sometimes, a Space needs to be there to coordinate the thoughts of other entities like a Team or Department. For example, my Team may want to document how we are going to improve our Agile process. This is not something that others will care about when they are looking at the Space of the product that team happens to be building. So rather than having one large space that contains all the things the Team is doing, split the space with a clear distinction based on who will use the content. 

Last but not least, socialize the decision

Don't forget that you are not alone in your Confluence instance; others in your organization are likely feeling the same! Be sure to take action by clearly naming Spaces based on what their purpose is to the business. Feel free to add Space Categories and Descriptions to help other navigate more easily to your content. Following these simple rules, Praecipio Consulting has helped other companies organize their Confluence into a more productive and manageable application.

If you have questions on Confluence, Jira, and how these two amazing Atlassian tools can work together in your organization, contact us and one of our experts will get in touch with you.

Topics: jira confluence
3 min read

Jira Align Jumpstart: What to expect

By Brian Nye on Dec 31, 2020 10:30:00 AM

Blogpost-display-image_Jira Align Jumpstart- What to expect

Do you want to roll out Jira Align in your organization but are not sure where to start? The answer is simple, use our Jira Align Jumpstart solution. This solution will give you access to a Solutions Architect who will walk you and your core team of Jira Align practitioners on the setup of your first Program in Jira Align. 

As part of a Jumpstart, there are five phases that you will go through:
  1. Discovery
  2. Set-up
  3. Implementation
  4. Training
  5. Launch

Discovery

The first phase of a Jumpstart is Discovery. During the discovery phase, your Jira Align Solutions Architect will get to know your company. The goal of this is to understand where you are in the scaling process and to get your leadership engaged in communicating the reasons that you are implementing Jira Align. A large part of this will be driven through the value drivers exercise. In this exercise, the team identifies common goals for the organization's agile journey. The output of this exercise will give the whole team a better understanding of the functionality that will need to be configured inside Jira Align and identify how your Solutions Architect can help guide you through that journey. 

Set-up

Following discovery is the setup phase. The setup phase will establish all the connections and settings needed to support your business. The Solutions Architect digs into the integration between Jira and Jira Align, making sure the two systems can pass information between one another. During this phase, there will be a lot of toggling on and off the various features and permissions for each of the user roles. This is based on the goals of the value driver exercise and the roles and responsibilities of the various levels of management using the tool. At the end of the set up phase, Jira and Jira Align will be connected.

Implementation

Connecting the two systems isn't all you have to do! To have the tool set up for your teams, you need to have some base data present to make sure it's working as expected. During the implementation phase, the Solutions Architect will work with Program Management to configure the initial teams and program data. This includes setting up initial strategic snapshots, goals, themes, epics, and features. The Jumpstart focuses on Program-level implementation, but basic configuration for some high level roll up is also included. Based on this data, we will see the flow from the work in Jira pushed up to Jira Align and changes in Jira Align, pushed down to Jira. Although this sounds like a simple task, it usually involves fine tuning some processes to ensure that reports and structure align to the goals established from the project onset.

Training

As the saying goes, a fool with a tool is still a fool. To avoid this, training is done with the teams who will be using the system. There are various types of training that are done with the team. One is for program management so they know how to use the tool from a day-to-day basis. Other training targets Jira Align Administrators so that they understand how the back end is configured and how to maintain the system following the Jumpstart. Both trainings help establish the fundamentals needed for working in the system.

Launch

Now that everyone is prepped and ready to go, all you need to do is launch the program officially. This is targeted to align to a PI Planning session. Now that your having these "Big Room" meetings virtually, you have a tool that will help facilitate the overall direction for your next Program Increment. 

What's next? 

If you want to know more about Jira Align Jumpstart and how to launch the product successfully, contact us here at Praecipio Consulting. We would love to chat with you about your situation to make sure that you are set up for success. Many clients are looking for better ways of scaling with Atlassian, and we would love to understand your current processes so you make the decision that is best for your business. 

Topics: jira digital-transformation atlassian-solution-partner jira-align
4 min read

Use Self-Service to Transform Your Legal Operations and Outcomes

By Joseph Lane on Dec 30, 2020 1:41:00 PM

Blogpost-display-image_How to Use Self-Service to Transform Your Legal Operations and OutcomesYour Legal Services team plays an important role in your organization, not only by ensuring that its traditional legal needs are met but also playing a part in its corporate digital transformation activities. This is true especially in light of the acceleration of digital transformation that many organizations have experienced on the back of the COVID-19 crisis – which highlighted the many failure points and inefficiencies of traditional, manually-reliant processes.

However, it’s also important to recognize that there’s a need for your legal operations to digitally transform too. Because any reliance on manual activities and processes – especially where there’s now a mix of office-based and remote working – is likely to slow down operations at a time when the effective handling of increased demand and the need for speed are paramount.

Digital transformation and Legal Services

Much of the discussion around digital transformation over the last half-decade has been focused on two “front-office” elements:

  1. The creation of new products and services that exploit technology and data to create new revenue streams.
  2. The improvement of customer engagement mechanisms, throughout the customer lifecycle, that again exploit technology and data.

Your Legal Services team is also playing its part in both transformations. 

However, there’s also a third – and critical – element that shouldn’t be overlooked: the need to improve business operations such that they’re fit to support the delivery of the new products and services and the improved customer engagement mechanisms.

This “back-office digital transformation” is generally replacing antiquated, manually-reliant business practices with improved, technology-enabled ways of working. It’s very much in line with a proven IT approach called “Enterprise Service Management” where IT service management (ITSM) principles, best practices, and technology are used by other business functions to improve their services, performance, and business outcomes.

A good example of this is the provision of self-service capabilities to customers (employees) to provide them with a single, simple route to legal assistance and a better service experience – including self-help when appropriate.

Employing self-service capabilities to improve legal services and support

On the one hand, it’s easy to view self-service as something that’s now expected by employees based on their often-superior, consumer-world service and support experiences. On the other, there are many benefits available to your Legal Services team and the people it supports.

Done right, self-service provides a “better, faster, and cheaper” way to deal with the corporate demand for legal services. Everyone wins! For example:

  • Customers (employees) get an easier way to engage with your Legal Services team. Plus, quicker access to information and resolutions, especially when self-help can be used.
  • Legal staff can firstly benefit from the “deflection” of a high proportion of demand thanks to self-help. Second, automated workflows ensure that work is efficiently passed to the right people, and back-end capabilities such as notifications, approvals, and alerts further enhance the flow of work and outcome delivery. Third, there’s improved insight into demand, workloads, and performance that can be used to further enhance the self-service capability and other areas of your legal operations.
  • The business as a whole benefits from the lower costs of legal assistance and increases in capacity and speed.

Ultimately, a Legal Services self-service capability will be the most efficient and effective way of handling corporate requests for legal assistance – from their receipt (through a single channel), through their handling and management, to delivering the desired outcomes. With this capability readily available to your Legal Services team through the use of the corporate ITSM tool – such as Jira Service Management – and service management principles via an enterprise service management approach.

Learning from the self-service experiences of IT

While self-service adoption is prevalent in the consumer world, the use of self-service capabilities by IT departments – as an ITSM best practice – has brought with it a number of common issues and associated insight into the factors that cause them.

These can all be learned from so that your Legal Services team can offer a self-service capability that will not only be actively used by employees but will also deliver a better service experience, speed up work and outcomes, and reduce the effort required of lawyers and paralegals. Freeing up your legal experts to focus their time on the most important things.

So, when planning and implementing a legal self-service capability, ensure that those involved:

  • Understand that the successful introduction of self-service capabilities is more about the need to effectively manage people change – using organizational change management capabilities – than it is the implementation of new technology. This is because it’s a change to the traditional ways of working for both the service requester and the service provider.
  • Design the self-service capability around the wants, needs, and expectations of employees rather than those of the Legal Services (or the IT) team. Failing to do this will simply cause employees to remain fixed to the use of the existing telephone, email, and walk-up routes.
  • Provide a sufficient level of knowledge articles for the capability’s launch. This is because the ability to self-help, with an immediate resolution, is a key factor in creating repeat users of the self-service capability.
  • Automate the backend. If this isn’t done, then the shiny new self-service capability is nothing more than a web-based request submission system – that’s little different to email – and the potential speed and cost benefits of self-service are forgone.

Got questions? We got answers! Contact us and find out how Praecipio Consulting can help your Legal Services team.

Topics: legal self-service itsm digital-transformation covid-19
8 min read

Transitioning to SaaS: Pizzas and Pitfalls

By Christopher Pepe on Dec 29, 2020 1:14:00 PM

Blogpost-display-image_The Gotchas of SaaS blog

What is SaaS (Software as a Service)?

COVID-19 has changed the world in many ways, accelerating the pace in which the digital transformation has upended traditional modes of working and living. Whatever your organization was planning to do in 2020, whatever 5-year plan you had, is no longer valid. No matter what sort of business you are, your dependence on technology has escalated. You have probably built the services in the table below or at least run them on your infrastructure, managed by your IT teams.  COVID-19 has forced you to ask the question: do I still need to run and manage this service internally, or can I save money and time by letting someone else perform this service for me?

Traditionally in-house Managed Services

Human Resources and Payroll

Web-based services

Customer support

Internal communications

Finance reporting, accounting, and invoicing

News and knowledge sharing

Project Management

Enterprise Data and Service management

Security

Sales and Marketing

 

The definition of SaaS by the East Sussex Council highlights what software is achieving today as businesses move towards a digital future: "SaaS is the focus for innovation and investment for major system providers and is specifically designed to meet the needs of an agile and mobile workforce, enhancing self-service business processes and significantly improving the use of management information. (Cabinet Office report for East Sussex council)".

Another view to help the discussion comes from Albert Barron using pizza as a stand in for software, with this fun visual of how the transition to SaaS changes from "You do IT" to "They do IT for you". 

Screen Shot 2020-12-05 at 10.03.18 AM

There are caveats that you need to be aware of such that your experience with a SaaS provide is valuable to your organization and customers: it's vital to go through these with your team before making decisions.  The rest of this article explores these and if you have any questions, please let us know.

1: Security, Risk and Data

Your data is now their responsibility!

  • Who in their organization has access to it?
  • How is it backed up and does that comply with your regulatory bodies?
  • Where is the data stored and does that contravene any local laws?
  • If they have an issue, what is their business continuity plan and how does that align to yours?
  • If they are compromised, what processes will they enable to let you know, but more importantly, protect your customers?
  • Will they agree to participate in your business continuity tests and decide on their role in a business continuity event?
  • Will the transference of data from you to them be exchanged safely and securely?
  • What will it cost to perform the data transfers and tests?
  • What level of access will your staff receive? Even if they assume responsibility for an activity, you are still accountable to require some level of access over time.
  • What defense does the vendor offer against hackers, and is this an extra-tiered service or part of the basic package? If extra, you might want to look elsewhere.
  • What processes need to change within your organization to enter, use, modify, delete, backup or restore information and have you been trained by the vendor appropriately?
  • Your data is now their responsibility. How portable is it if you want to switch?
  • Does the vendor support MFA
  • Do they allow penetration tests?
  • What policies have you introduced to manage your data in the SaaS provider cloud?
  • If the SaaS vendor changes the schema or worse-cancels it, what impact will that have and are you contractually protected?

2: SaaS Vendor Performance

The perception and experience of your staff and customers are now based on the SaaS provider's performance.

  • Did you create a clearly defined view of expectations supported by metrics and examples? Do you know bad from good from great service?
  • How did you explain to your customers and staff that you were now going to use a SaaS provider? What was the reaction?
  • What happens if your customers complain? What happens if your customers leave you because of a SaaS performance?
  • Is it contractually clear under what circumstances a complaint can be made, the timeframe it must be addressed and any penalties that could be applied for non-conformance?
  • Who does the customer or staff call if there is an issue? Your teams or the SaaS provider?
  • What level of support do they provide and how will you test that the service is delivered as expected?
  • What messages do you receive in case of a data entry issue or general performance issue?
  • Do you have regular performance and improvement meetings with the vendor?
  • If you want a new feature based on customer feedback, is the SaaS provider responsive?
  • If the SaaS provider changes their product procedures, what will be the impact on your customers? Can you pilot the changes? If you do not want the new procedures, can you leave the SaaS provider?

3: Vendor lock-in

SaaS vendors bet that once you let them perform an activity, that you will remain a customer for several years. In other words, you are locked-in to their practices, processes, support, improvements and remediation and so are your staff and customers.

  • How does the SaaS vendor recruit, train and keep their staff? You do not want a constantly changing workforce and there are examples where 30% of a SaaS workforce changes every 90 days.
  • You might have saved money by not having to hire or train your staff, but what will you do with the knowledge they possess?
  • Contractually obligating certain staff to remain until the transition is complete is best practice.
  • Your IT is now their IT. If you want to benefit from the latest technology and they do not support that product then you are stuck. Make sure your contract allows for changes or even cancellation if needed.
  • If the vendor changes their price, what protections have you contractually initiated to ensure that you should remain with that vendor? How will you prove value over time?
  • COVID-19 has seen a number of vendors have issues causing them to default on a service or even go out of business. How will you protect yourself in case this happens to your provider? 
  • SaaS vendors price in three main ways: by user license, by use, by feature. Make sure that you have chosen the model most appropriate for your needs and that if your work model changes, then you can move to another tier without penalty.

4: SaaS requires an internet connection and belief the cloud is secure

  • What if something terrible happens to your web servers? Do you have backups of your metadata? You might want to consider using third party backup services such as SpanningBarracuda, and Backupify.
  • If you have communication issues from your office, what is your backup to ensure that the SaaS service remains accessible?
  • If your staff are working from home and they have issues, then how will they continue to work until normal service is restored?
  • Can your staff download data to their home office? If so, this is a security and perhaps even a compliance risk. How will you know?
  • If they invoke contingency, does this place your business in a location where you
  • What is the web page loading time? How complicated is the page to read or use?
  • If data is transferred to other applications to complete the journey, can this be monitored for security and improvement?
  • Is the SaaS service usable across a variety of mobile devices or internet browsers?

5: Integration into your other software

SaaS implies that all of the technology required to perform a service is now under the control and management of the vendor.

  • How easy is it to transfer their data into your systems such as corporate finance?
  • What happens if they make a change to a schema that you were unaware of and this damages your data or causes you lost time to introduce new ways of addressing their change?
  • Everyone performs regular maintenance activities and how will this be coordinated?
  • If you use multiple SaaS vendors (Accounting and Sales for example), how will you keep them in sync with each other and any internal applications you maintain?
  • How do you test that interoperability remains as expected?
  • What is the impact to your business continuity of multiple SaaS providers?
  • If a vendor has an issue, how will that impact other vendors you rely upon?
  • Will you require 3rd party to help you integrate their software with yours? This can be costly.
  • Not every vendor follows standard APIs, protocols, and tools, so the impact to your business practices should be piloted prior to accepting the SaaS provider.

6: You may have to change your business practices to use the SaaS

  • This is a culture change for your staff. How will you prepare them?
  • What training and documentation will you receive and is it sufficient?
  • If something requires customization, is that even possible or practical? Many SaaS vendors will only allow this if a significant number of customers also request that feature.
  • How will you ensure that other business practices can pivot based on competition, compliance or performance needs?
  • How will you ensure that the SaaS provider supports all of the ways your customers want to interact with you? Browsers, mobile technology, VPN, etc.?
  • What and when is their maintenance window? How does that impact your business customers? What happens if a change goes awry?
  • What information do you receive on incidents related to you? Is it in a format that your ITSM tools can read and archive?

SaaS is a brilliant technology capability that can benefit your organization. You must closely manage them if you are to remain in business, service customers safely, and receive the expected cost benefits. Ensuring that you have a way to mitigate this list of caveats will ensure that your experience is as valuable as possible. Letting go of services you have built in-house can be hard, and moving to a SaaS model can be intimidating: have no fear, Praecipio Consulting is here to help. Contact us for any questions you might have of successfully transition to a faster, more efficient way of doing business.

Topics: plan saas digital-transformation
4 min read

Provide the Digital Transformation Your HR Department Needs

By Joseph Lane on Dec 28, 2020 1:56:00 PM

Blogpost-display-image_It’s Time to Provide the Digital Transformation Your HR Department NeedsThe COVID-19 crisis has changed the world forever, from how we interact with others in our personal lives to the more complicated requirements of business operations. These changes have evidenced the need to accelerate the corporate digital transformation strategies that have previously been slow in execution.

Now, as your human resources (HR) department assists your organization in rebounding from the adverse impact of the crisis on operations and revenues, there’s much that needs to be done to ensure that your traditional practices can quickly evolve to the higher needs of the “new normal.”

Surviving the long tail of the COVID-19 crisis

At the height of the crisis, with people working from home or perhaps not working at all, there was an immediate need for new IT services and support practices to ensure that working employees could still work effectively and remain safe. For many organizations, “mountains were moved” in quickly creating the technology-based ways of working needed to keep things going. And employees hopefully appreciated the potentially new IT capabilities that enabled their remote working – both in terms of their personal productivity and the need to collaborate with others when working within business processes.

Now, with some employees returning to offices and others continuing to work remotely – at least in the short term – there’s a need to formalize and improve upon the “emergency” capabilities that helped your organization through the crisis. There’s also likely a need to respond to the mandated budget cuts that come as a result of the initial and ongoing effect of the crisis on company sales and revenues. Plus, the move to homeworking, in particular, has further increased the importance of employee experience and the need for organizations to maximize employee productivity.

In light of all these needs, and potential pressures, your HR department likely needs new ways of working that remove – or at least minimize – the reliance on manual practices, that while always potentially inefficient, are now difficult to operate in a distributed working environment.

Leveraging technology and service management principles to digitally transform

While digital transformation might seem like something that’s focused on technology and data, it’s ultimately about new ways of working and driving successful people change. So, while this blog covers the improvement possibilities available through the greater use of technology and IT service management (ITSM) best practices, there’s still the need to apply organizational change management tools and techniques to what might feel like a daunting change to many.

In terms of quickly transforming your manually-reliant operations, your organization’s IT department might already have the necessary ingredients for improvement at its fingertips. Through an approach it calls “Enterprise Service Management” – “the use of proven ITSM capabilities to improve other business function operations, services, and outcomes” – with this providing a backbone for the required back-office digital transformation in HR and other business functions. In fact, at a business-level, “back-office digital transformation” is a better term for this approach to leveraging technology and service management principles outside of IT.

Even before the crisis highlighted the many failure points of the traditional reliance on manual operations, IT organizations had already bought into the business benefits of enterprise service management – with the 2019 ITSM.tools Future of ITSM Survey finding that two-thirds of organizations either had or were planning to develop an ESM strategy.

How digital transformation will help your HR department

Whether it’s through the adoption of an enterprise service management approach or via another route to organizational improvement, the use of service management principles and the associated enabling technology will make your HR department all three of “better, faster, and cheaper.”

Examples of the ITSM capabilities that can be leveraged by your HR department include:

  • Automated workflows for issue handling and request fulfillment – saving time and costs, and providing a better employee experience.
  • Knowledge management – augmenting the knowledge of HR staff and providing the foundation for employee self-help, making for better, faster, and cheaper HR services.
  • Self-service and self-help – empowering employees to help themselves via a now-expected, consumer-like capability. It also reduces the demand-based pressures on your HR support capability.
  • Problem management for repeat issue minimization – preventing common issues altogether rather than simply trying to remedy them more swiftly.
  • Greater insight into performance and improvement – with it easier to gain the visibility required for better decision making when work is no longer trapped inside personal email accounts and spreadsheets.
  • The use of newer technologies such as artificial intelligence (AI) to improve across all three of better, faster, and cheaper.

Common HR digital transformation use-case scenarios

All of these proven ITSM capabilities, and others, can be successfully employed by HR departments to improve their service and support capabilities, the employee experience, and business outcomes.

Common examples of HR practices that are already benefitting from service management and digital transformation – perhaps via an enterprise service management approach – include:

  • Employee query and case handling
  • Recruitment
  • Employee on-boarding and off-boarding
  • Learning and development
  • Payroll and employee benefit administration
  • Demand planning.

Using service management best practices and an ITSM tools, there’s no limit to how your HR practices can be improved to deliver the better, faster, and cheaper ways of working that are needed in the “new normal.”

At Preacipio Consulting, we can help your organization take advantage of the opportunities of digital transformation and enterprise service management to HR: Reach out, we'd love to help.

Topics: service-management human-resource itsm digital-transformation covid-19
5 min read

Your Finance Department Needs to Digitally Transform Too!

By Joseph Lane on Dec 23, 2020 2:07:00 PM

Blogpost-display-image_Your Finance Department Needs to Digitally Transform Too“Digital transformation? We already have lots of technology employed in Finance.” And you’re not wrong – whether it’s an enterprise resource management (ERP) system or finance-focused systems or tools.  But the corporate requirement for digital transformation isn’t simply the addition or increased exploitation of technology and data but is, instead, a mechanism for improvement and better business outcomes that just happens to be using technology to greater effect.

Your Finance Department needs digital transformation: here's what this entails.

The “why” and “what” of digital transformation

A common misconception is that technology keeps getting added to organizations simply because it’s available – and sometimes this does happen. But digital transformation is different. It’s a corporate, not an IT, strategy that’s aimed at delivering better business operations and outcomes not merely the increased use of technology. Importantly, it covers far more ground than you might expect.

So, it’s not simply the use of technology and data to create new products and services, plus the associated new revenue streams. Nor is it only the use of technology to improve customer engagement mechanisms too – something that you might have experienced in your personal life.

There’s also a third part to digital transformation – and this is what’s relevant to your Finance Department and its operations: the use of technology and data to improve back-office operations across your organization, within its many business functions. From the introduction of digital workflows, through the use of self-service and self-help capabilities, to the many benefits of gaining greater insight into business function workloads, operations, service performance, outcomes, and improvements. Importantly, this back-office digital transformation is a vital enabler of the more prominent front-office improvements.

Think of it as making your operations and outcomes all three of “better, faster, cheaper.” It's using technology to make your Finance personnel the best possible versions of themselves, especially in light of the current and ongoing need for remote and distanced working, including effective communication and collaboration. With no organization or business function immune to the need to change traditional, often manually intensive, ways of working to better reflect the physically disconnected nature of modern work.

It’s a need that's likely to continue, because organizations have realized that the required operational resilience can’t be met by their traditional, manually intensive processes that rely too heavily on face-to-face interactions, email exchanges, and spreadsheets.

The “how” of digital transformation

In enabling the required new ways of working, there’s a need for greater technology exploitation that provides not only the ability for work to flow better between individuals and teams but also:

  • Speeds up that work and the decision points needed within it. For example, some work tasks can be automated, and alerts and notifications employed to ensure that the work keeps moving swiftly through to the desired endpoint and outcome.
  • Facilitates interactions with those requesting service and support from your Finance team(s) – with self-service, via a self-service portal, a better way of managing incoming requests on the supplier side. And, on the demand side, a more effective route to access finance-related assistance for your department’s internal customers.
  • Self-help capabilities that deflect both emails and telephone calls from your busy Finance personnel. With the inquiring employee instead self-accessing what they need to know, and likely getting a quicker solution in doing so. For example, something as simple as checking whether an expenses claim has been approved and when it will be paid.
  • Knowledge management capabilities that, on the one hand, help Finance staff to collectively know more than they individually know – which is especially helpful for new starters. And, on the other, the captured knowledge can be employed to help defect emails and telephone requests through self-help.
  • Greater insight into past, present, and future operations. From how well work has been handled and whether service promises met (perhaps versus agreed service level targets), through managing the current workloads across teams and individuals and the likelihood of delays, to future projections of how things will continue based on trends or simulations modeled on proposed changes to the status quo. This greater insight also provides the platform for improvement identification and actions across all of operations, service quality, employee experience, and business outcomes.

In addition to the above, the growing use of artificial intelligence (AI), in the form of machine learning, adds even greater opportunity to leverage the new digital capabilities to speed up operations, provide a better service experience, and to allow Finance staff to focus on what they do best (and prevent them from wasting time and costs on high-volume, low-value tasks).

These digital-transformation-enabling capabilities might already be available in your organization

While digital transformation can feel like a relatively new concept, it has been on corporate radars for at least a decade. And for those organizations that have already taken steps to digitally transform part or all of their back-office operations, including Finance operations, many have taken an “enterprise service management” approach. This is where the proven corporate IT service management (ITSM) capabilities – processes and the associated technology-enablement – are applied to other business functions to improve their operations, service and support, and outcomes.

In many ways, enterprise service management and the use of the corporate ITSM tool are seen as a platform for delivering the technology and data elements of back-office digital transformation needs, from digital workflow enablement, through self-service capabilities, to the introduction of new machine-learning-based capabilities.

From an employee perspective, an additional benefit from Finance’s digital transformation is that they’ll be using similar service and support methods to those employed in other business functions such as human resources (HR) and IT. This not only offers a guaranteed level of service experience, but it also provides a level of enterprise-wide consistency that makes interacting with the Finance Department (and other business functions) so much easier.

Examples of how your corporate ITSM tool can help your Finance Department

There are many Finance-related opportunities to leverage digital workflows and the other capabilities outlined above. For example, for:

  • Receiving new finance-related requests, and allowing employees to check request status, via self-service
  • Using automation rules or machine learning to route new requests to the right work groups, with some requests responded to automatically using intelligent automation
  • Handling queries and requests for information, help, and change more efficiently
  • Budget, invoice, and employee expense management
  • The automation of high-volume, low-risk requests for Finance approval
  • Escalation handling
  • Business case reviews.

These opportunities will, of course, be dependent on your organization’s current ITSM tool being deemed suitable for the many possible enterprise service management and back-office digital transformation use cases.

The need for digital transformation within your Finance Department is clear, and here at Praecipio Consulting, we can help you with the process.

Topics: automation finance itsm digital-transformation
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 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 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 saas cloud hosting customer-experience
3 min read

Community-driven Pollinator Garden at Bristol Elementary School

By Christopher Pepe on Dec 15, 2020 4:33:00 PM

Blogpost-display-image_Pollinator Garden for Elementary school

It took a village to create this natural space for children to explore.

garden

Parents discussed the joy of the Bristol Elementary School's (BES) Forest Fridays and how our kids thrived outdoors (the year before one student formed a petition, gathered signatures, and lobbied the administration for more outdoor recess time). Parents and school administration began meeting to remove hurdles to students being outdoors. The focus of the effort became:

  1. Outdoor classroom space to facilitate classroom based learning outdoors
  2. Natural playscape to encourage engaging with and observing the natural world
  3. Water management during the spring thaw and freeze cycles

During a training session, Four Winds, a community-based natural science education organization, announced a mini-grant program to improve area schools. We felt a pollinator garden was the most achievable project to increase the diversity of the playground landscape without adding much maintenance overhead. Four Winds agreed and BES was awarded the grant.

Four Winds Nature Institute is a non-profit organization advancing the understanding, appreciation, and protection of the environment through community-based natural science education and research. 

While the beloved playground boasts a vast flat area with many play structures there is not much natural diversity. Our goal has been to rewild the playground and celebrate seasonality with an ever-changing display of flowers and foliage made of native plants. This project would establish a naturalized island that will promote native plants and pollinators, as well as cultivate creative play. The students can watch the garden evolve, watch the insects, birds, and other life that thrives there, and to be a part of it themselves.

I would like to thank our vendors, who were easy to work with, generous with their time, gave us favorable pricing, and donations. All of our plants came from Full Circle Gardens. Sarah helped build our plant list, added in several plants as donations, and delivered them for free. Great communication and coordination made working through the pandemic a non-issue. Our mulch and top soil came from Livingston Farm, nearly half of which was donated to this project. Without the generosity of our vendors we could not have built the garden that we had envisioned. Thank you.

I would also like to thank the school administration for their support and commitment to our community. This effort began with principal Kevin Robinson who was an enthusiastic supporter of our parent driven efforts. That was handed off to Thomas Buzzell who is a strong advocate for outdoor play and its many benefits on behavior and development of children. With the community, he is building a collective vision of the future of play at BES. No job too small, Tom has even offered to hand water the fledgling garden. Joel Fitzgerald has also been a strong advocate for this project and playground improvements including a student driven project to build an outdoor classroom. Sheila Gebo was kind and patient while shepherding me through vendor management and financial operations. And of course thank you to Four Winds for funding this project and encouraging us along the way. I would also like to thank the other parents that have given their time and energy at every phase of this project. Finally, a special thank you to the Urban girls for their hard work in installing the garden on a sweltering summer day. Thank you all, and those that were not named. Without your help we would not have completed this project.

IMG_6516

There were a lot of hot dry days between delivery and installation. Sam was a big help in keeping the plants happy.

IMG_6687

The Urbans came out in force for installation day!

Topics: environment do-good social-responsibility education
7 min read

SaaS can be SAFe®

By Christopher Pepe on Dec 11, 2020 2:30:00 PM

Blogpost-display-image_SaaS can be SAFe Blog

SaaS is the future

2020 has caused the world to work from the internet. Whatever you used to do in your own data centers can now be performed by vendors, be they cloud or software service providers, better, faster, more securely, and at less cost than you.

The diagram below indicates the trajectory of change from traditional to SaaS (software as a service). Learning how to manage SaaS providers is the new skill that must be learned and introduced into your strategy.

Screen Shot 2020-12-05 at 10.03.18 AM

The hardships of this year have also proven that you need agility in your 5 year plan so that you can change along the way.  The capability to pivot based on circumstances is the other new capability of an organization moving towards a digital and VUCA (Volatility, Uncertainty, Complexity, Ambiguity) future. You have to be agile, not just in IT, but the way you think, act, and react. Leadership has to manage and accelerate this change in culture and behavior, which means scaling new ways of working enabled by technology is the new management paradigm.

Allowing a SaaS provider to manage a core function such as Marketing, HR, or Sales is the norm, freeing you to concentrate on creating unique services that benefit your customers and save time for your staff. 

Scaled Agile Framework SAFe®

No matter what blend of Agile that you are using (Scrum, Kanban, DevOps, AgileITSM, XP, TDD, BDD, etc.), you will need to spread these practices across your business. New ways of working, constant improvement, collaboration, and the elimination of siloes, benefitting from technology, be it your own or others, is the only way to survive. 

Accomplishing this change means a dramatic, and in some cases, drastic, alteration to how things are currently performed:

  • You keep your program office but lose your project mentality
  • Product and Service Owners are the new organizational role with accountable budgets and teams
  • Agile Budgeting replaces annual budgets, and the same occurs to annual reviews as constant and consistent feedback is provided top-down
  • Multi-year contracts are swapped for partners that facilitate your agility
  • The use of technology to keep you in business enables every aspect of your business
  • Staff are not made redundant but instead acquire t-shaped skills
  • Customer focus and shifting left from their request or needs drives your product strategy

Organizations need guidance to make these types of change successfully. Enter Scaled Agile Framework (SAFe®).  The diagram on their website visualizes the breadth of their philosophy and impact on an organization. 

SAFe® is a continually changing set of practices that has blended the technology, people, and business practices into a competency-based model: 

  • Leadership based on agile and lean: empowerment, self-organization
  • Team and Technical Agility: No defects, use of cloud & internet, open-source, SaaS
  • Behavior-Driven Development (BDD): products based on the people use them
  • Test-Driven Development: code, infrastructure, people feedback in short cycles
  • Agile Product Delivery: small changes made often, usually daily
  • Lean Portfolio Management: if it is not helping someone, then you don’t do it, constant improvement, reduced technical and cultural debt
  • Lean Governance: common or standard data models, budgets are based on the value of outcomes and funded accordingly, guardrails guidelines both corporate and regulatory, business continuity and sustainability is a daily way of acting 
  • Organizational Agility: long-term goals but very short-cycle plans capable of pivoting based on breaching a KPI or OKR (Outcome based vital indicators)
  • Continuous Learning Culture: effort is rewarded, management changes to a coaching model from a telling model, relentless improvement is mentored, innovation is the goal

SAFe® is the most ambitious version of this framework's scaling technology, leadership, financial, and organizational practices. It supplies examples, training, templates, and a worldwide community of practitioners. It is not for everyone. It is not a program of introducing Safe® that will make it successful for you but instead a multi-year effort of scaling the way your business does things at every level into a new model. 

SAFe® helps you avoid and overcome these engrained practices:

  • Budgets by department or project become funding for products and services
  • Prioritization of new features or services is based on value of delivery and cost of delay
  • Creating your own software is replaced by using open source or SaaS
  • Data used and kept by your business is standardized for ease of maintenance and change to new services as needed
  • Mapping the way you work end-to-end and ensuring any changes are not localized but instead improve the flow of work and data is the new program office structure.
  • Change Approval Boards or freezes are stopped because you trust the testing and release process that has been enhanced and automated. 
  • Design thinking is encouraged to solve problems
  • Design thinking underpins making things as small and as standard as possible such that any part of your business can use it or improve it
  • Everyone is thinking about what can I do to make things better, do things faster and safer, and how can I save effort or time or money

SAFe® Benefits

  • Increase the velocity of change: ways people work and the software that supports these changes
  • The software lifecycle of Demand-Approve-Develop-Integrate with other code-Unit Test-Performance Test-Submit to Live Approval-Go live is replaced with Experiment-Develop-Test-Go live
  • SaaS + Cloud + Digital is the technology trilogy whereby owning your own technology is discouraged (still allowed where regulatory mandates leave no other option)
  • Complex projects requiring months or effort are replaced by an understanding of what a new service or feature or technical update will provide a customer or staff member and therefore, this is what is created and deployed
  • Technical stability is more critical than new service introductions (think of your customers and how angry they get when things go wrong)
  • Feedback, monitoring, alerting are the trilogy of information collaboration and coordination (no silos)
  • Legacy infrastructure or technical debt is mitigated by using cloud services aligned with your work and customer practices. Technology underpins the way you do things and not just there because!
  • Training on SAFe® culture and practices is top-down and extends to your external suppliers
  • Project Management is now Agile Product Management, coordinated across products and services instead of merely helping a department or team
  • Prioritization based on what it fixes, how it meets a regulatory demand, what outcomes it being in terms of value and customer satisfaction, or how it helps staff perform a function

Doing SAFe® means:

  • You are willing to release small chunks of change daily versus large pieces that might wait months before going live
  • You can monitor the impact of that change in terms of issued caused or customer satisfaction
  • If an issue ensues or satisfaction is not as expected, then you can easily roll-back the change with minimal effort or impact (go back to the way things were before)
  • New skills of negotiating or always thinking of enhancing products via technology are taught in a variety of formats such as hackathons, formal training, a partner working, and management coaching
  • Operating and Strategy long-term plans are replaced by short-term vision plans that are customer and market-centric
  • Centers of Excellence or Software Factories are created aligning how people working based on data and technology mapping exercises with the approved practices of the organization, which encourages:
    • Standard tooling for Enterprise Application/Service Lifecycle Management 
    • Standard data and artifact repositories
    • Use of SaaS providers for core activities
    • Always on testing, monitoring, and alerting across the value chains

A train yard is a frequent analogy to explain software factories and centers of excellence. You need a standard gauge rail for all trains to use, and an aligned place for trains to be monitored and dispatched. This allows trains to move safely across the landscape, delivering people to their locations. Your organization needs to establish the same kind of software delivery practice. This model is what SAFe® uses to foster the fast and safe distribution of technology via an engineered flow of work.

SaaS Safe® tips

  • Create a vision of why SaaS and Safe® are being adopted, underpinned by training
  • Change the language used top-down from project to product
  • Have metrics that make innovation for customers or staff the prime target
  • Developers develop and operations keep things up is the most prominent IT silo. Break this by making product teams that own their product or service.
  • Technology metrics of Defect Rejected Ratio, Detected Defects, Change Time compared to Market release, Value of Delivery versus Effort are viewed on product boards
  • Create fun programs of change such as Kill the CAB, which force the introduction of standard technology components for use by any aspect of the business
  • DevSecOps is not an option but a mandatory requirement: you have to test at every opportunity and use security practices and tools to keep your business safe and compliant
  • Automate what you can as often as you can, but only if this improves the quality and speed of work

SaaS is the way of allowing someone else to perform a function via the use of their technology. Carefully avoiding vendor lock-in will make SaaS a credible option for your business. The transition to remote working has opened up a world linked by technology, and your organization needs to do the same by scaling the thinking and practices of technology to everything you do. SAFe® is a framework proving your business a set of rules that promotes scaling Agile, Lean, and DevOps across your organization. It is a radical alteration of your culture that will take time and leadership to embed successfully.

Whether implementing SaaS, SAFe® , or just generally digitally transforming your company, Praecipio Consulting can help!

Note: SAFe® is a Registered Trademark via ©Scaled Agile, Inc.

Topics: scaled-agile saas safe agile
5 min read

7 Non-Negotiables When Choosing an Atlassian Business Partner

By Katie Thomas on Dec 8, 2020 2:25:00 PM

Blogpost-display-image_7 Non-Negotiables When Choosing an Atlassian Business Partner2 (1)

Ask any project manager what the number one contributor to a successful project result is, and they will tell you that it’s having the right people on the team. That goes for vendors too. Because behind every consulting gig are people making decisions that influence your company’s future. 


The decision to select an Atlassian Business Partner is a big one. The stakes are high, with perhaps millions of dollars and people’s careers hanging in the balance. A bad vendor decision could haunt you for a decade or longer. 

The process to choose a vendor usually starts with a referral or by viewing the Atlassian Partner Directory. However, with over 50 Platinum Partners distributed across the globe, it can be overwhelming. After visiting a few of the partner websites, you may be no closer to a decision.

Christian_Lane

Christian Lane, CEO of Praecipio Consulting, an Atlassian Platinum Partner, offers his thoughts on how to approach the partner selection process to ensure your project is delivered on time and within budget. 

 

He starts by sharing his recommended list of “must-haves.” In his opinion, any vendors not having these should be immediately disqualified. 

Look for relevant experience

To be approved as an Atlassian Partner, you must have smart people. All companies can easily add up the years experience among their people and come up with an impressive number. But that’s not the differentiator between firms. Don’t accept a general numerical answer. Dig deeper and ask for specific experience in your industry and what the scope of those projects were. 

Executive involvement

There is nothing more frustrating than dealing with a person that isn’t empowered to make decisions. You want top levels of management to be familiar with your project and understand its strategic value. This way they can apply their leadership and senior experience to add value. You want them to ask questions about workflow, reporting, integrations, and how it relates to the overall goal of the project.  

Rate of repeat business

As the saying goes, “The best predictor of future success is past behavior.”  Ask the vendor about their rate of return business. It’s perhaps the clearest indicator of a company's performance and customer satisfaction. Lane adds, “72% of our business last year was from repeat clients. Any competent firm should be able to tell you their number. If they don’t know it, that's a red flag in itself.” 

Percentage of revenue from change orders

Avoid the bait and switch. Managers want to deal in absolutes when it comes to money and time required to get the job done. You don’t want to fall in a trap of working with a vendor only to be told that your request wasn’t included in the original scope. For example, at Praecipio Consulting, we have a defined process to expose any and all needs of a project. By clearly defining the work from the start, you avoid missed expectations and expensive changes. For our team, this process starts with defining the problem in the sales process and includes engineers and other technical people. If there are any limitations or features to add for the solution, they contribute to the conversation. All parties move in lockstep, and a delivery commitment is made. The process has proven to work, as only 2% of our revenue last year came from change orders. Lastly, pay attention to how much value is delivered before the signed contract. 

Listed in the Atlassian Partner Directory

Only choose a partner from the official Atlassian Partner Directory. These companies have demonstrated their expertise and willingness to dedicate themselves to the software. They have to make an investment to be included, and their business model revolves around partner support. Using any other firm not vetted by Atlassian should be approached with extreme caution and is not recommended. 

Platinum Partners have the most experience and have been doing this type of work the longest. They have been recognized as the best and have inside knowledge about new products, features, and beta testing. For example, our leadership team members have participated in panels, councils, and have had an influence in building the software and program itself. 

What do they stand for? 

Commonly referred to as mission, vision, and values, look for what drives the vendor beyond earning revenue. Do they share your same morals and values? Besides words on a website, do they walk the walk on issues like social justice and environmentalism? Lane says he has seen more customers comment recently on their social injustice stance and Praecipio Consulting's commitment to the 1% pledge initiative. “We’ve always been socially aware and decided to build a company that leaves the world better than we found it. I’m proud of our ideals. As part of our hiring process, we want to make sure employees can get behind our causes and work toward the greater good. When clients recognize our efforts, it fuels our fire to want to do more.”  

Net Promoter Score

Ask vendors what their Net Promoter Score (NPS) is. NPS is a commonly accepted simple score of how likely customers are to refer you to their peers.

  • 0-6 are detractors, meaning they will tell people to stay away from your firm and NOT hire you.
  • 7-8 are passive promoters, meaning they will praise you when asked
  • 9-10 are active promoters, meaning they will go out of their way to tell peers about your good work 

Praecipio Consulting holds a lifetime NPS score of 71 (for context, the industry benchmark for software and tech companies is 28). Our team is proud of this score because they put so much heart into every project and seeing their clients' delight with their work is the ultimate payoff. 

Lane adds that the less quantifiable metric is “Ease to do business with.” Entering an agreement to work with an Atlassian Partner is a big commitment in terms of time. Are they responsive and U.S. based? Are they flexible and adaptable? And do you enjoy working with them? There has to be good chemistry to get the best result. Lane concludes, “Business is hard enough as it is sometimes. Don’t spend your valuable time working with difficult people. Control all the variables you can and make the most informed partner choice you can.”

 

Topics: do-good pledge-1% nps atlassian-solution-partner social-justice
4 min read

How to Have a Stress Free Holiday

By Katie Thomas on Dec 4, 2020 2:01:00 PM

Blogpost-display-image_How to Have a Stress Free Holiday Vacation (1)

In just a few weeks, the holidays will be here. Your partner may be already making needed plans to enjoy the much-needed downtime at home. But inside, you may have an uneasy feeling about work projects. Can you afford to take off and not fall woefully behind? Will important software-based projects stall? Or worse, crash and burn?

If the thought of taking PTO comes with mixed feelings, this article is for you. 

At Praecipio Consulting, we’re business process experts. Every day we work with executives from the world’s most respected companies. We surveyed our partners to learn their advice on how you can take time off to recharge your batteries and have your team keep projects moving at the same time. 

Christian_LaneChristian Lane, our CEO, begins the conversation. “I love taking time off. It’s essential for my well being, and we require everyone in the company to do the same. It’s a non-negotiable. But when we do have key team members out, we have set expectations.”

 

 

Announce your plans and block off your schedule

Let your coworkers know not to schedule anything for you during this time, and be aware of these dates when you are discussing project deliverables. 

Bust your tail for 3 weeks prior

Put in extra hours if you have to, but I prefer to better use the time already allocated for work. Staying focused and being productive now will help you have peace of mind later. 

Empower your #2

For executives in senior management, there may be time-sensitive decisions that need to be made in your absence. It’s important to have a second-in-command that has full authority to make most decisions while you are gone. Have a meeting with this person about the parameters of this responsibility and make sure the other players on your team are aware of who you have delegated to. In addition to leaving decision authority in capable hands, you’ll likely see this person respond well and appreciate the trust. Understand that mistakes may happen, but it’s also a learning opportunity. 

Joseph Lane, Atlassian automation expert and one of our partners at Praecipio Consulting, takes a more tactile approach. He stresses that in the Agile mindset, effective managers must use the right tools that are purpose-built and customizable to keep critical business functions working effectively. If any project relies on any one person for completion, this potential single point of failure is problematic for the organization and stressful for the employee. When this key person needs rest and relaxation, business stops, and that’s expensive. 

joseph_lane selfieMore specifically, Lane is referring to the Atlassian suite of products: Jira, Confluence, Trello, and others. When used to their fullest potential, team members can work independently if needed and collaborate following a quality assurance process the company developed. Users and managers can almost instantly view the progress on a project and comment. Lane recommends having a clear system for accountability and escalation when challenges arise. If this is clearly defined before a manager goes on vacation, team members can bring in more people, access more resources, or find vendor partners to solve problems. Failure to have these processes in place means that projects could stall and teams lose momentum. Lane summarizes, “Be more process-oriented than person dependent.” 

Christian Lane encourages everyone on software teams to develop a mindset for responsibility. That means if you find a problem, you own it. See it through to a solution. He loves the idea of stress-testing your systems by creating fires. “It keeps people on their toes,” he says. An example might be inserting a snippet of code that wreaks havoc. Engineers must backtrack and see where it was introduced. Also known as chaos engineering, it’s the practice of experimenting on a software system in production to build confidence in the system's capability to withstand turbulent and unexpected conditions.

Still, totally unplugging, although the healthiest option, isn’t always possible. Lane tells a story of when he was conflicted about taking his laptop on an overseas vacation. “On one hand, if I took it, I knew I couldn’t help myself and work. On the other hand, if there was a legitimate emergency and I needed to log in, I wouldn’t be able to.” 

In the end, he decided to travel with his computer and stay disciplined to only look at his Atlassian enabled dashboard when he logs in. If he saw all green lights, he would close the laptop after just 5 minutes or so per day. 

In the end, great leaders are measured by how well the business continues without you. As leaders, our job is about driving continuous improvement. When you take off time, operations may not be improving and optimizing, but they should still continue. 

A recap for a stress-free holiday:

  • Announce your plans, block off your schedule
  • Bust your tail for 3 weeks prior
  • Empower your #2
  • Use the right Atlassian tools 
  • Have process and systems for escalation in place
  • Develop a mindset of responsibility
  • Stress-test your systems

 

Topics: holiday atlassian-solution-partner work-life-balance
2 min read

How to Get Involved This #GivingTuesday

By Morgan Folsom on Nov 30, 2020 2:14:24 PM

Blogpost-display-image_SJ- Giving Tuesday blog

Now that we're rapidly coming up on the end of 2020, I'm taking time to pause my life and find things to be thankful for. Under normal circumstances, this exercise can be a great way to wrap up the year; after this year, though, let's just say that I had a harder time than normal pulling together a list. The truth is that despite it being a tough year, I do have a lot to be thankful for – I've made it through this year with a job and a home, something that many people are not experiencing this year.

As we enter the holiday season, the messaging that we see is increasingly commercial: Black Friday edges earlier into Thanksgiving, Small Business Saturday tries to pull focus locally, and Cyber Monday pretends like we're not online shopping for the first two, making it a trifecta of commercialism.

Giving Tuesday is an annual celebration on the Tuesday following Thanksgiving that encourages individuals and organizations across the country to do good. What better way to wrap up three of the highest spending days of the year by looking at how we can support others?

What we're doing

Here at Praecipio Consulting, we've stepped back and taken stock as well. Supporting our communities has always been a core value here, and we've been a member of Pledge 1% for years. We are proud to spend our time and money with organizations like the Flatwater Foundation, TreeFolks, and Bamberger Ranch. This year, we felt like we had to do more. At the beginning of June, the company began matching employee donations and doubling VTO toward relevant organizations.

This #GivingTuesday, we'll be taking it a step further and doubling employee donation matching for donations made on Tuesday, December 1st, as part of our continued dedication to supporting our communities. 

How you can get involved

That's what we're doing, but what about you?

There are a lot of ways to get involved, even in the middle of a pandemic. Check out local resources to find organizations that are accepting donations or for volunteer opportunities (if you're comfortable!). Events like gift drives and meal delivery are also great ways to contribute while still staying safe. Don't forget to look at local mutual aid funds for opportunities for even bigger impacts in your communities. 

Topics: flatwater-foundation do-good pledge-1% treefolks social-responsibility
1 min read

Praecipio Consulting joins the Aha! Partner Program

By Praecipio Consulting on Nov 9, 2020 11:30:00 AM

Blogpost-display-image_Aha!

We’re excited to announce that Praecipio Consulting has been selected to join the Aha! Partner Program as an inaugural partner. Recognized as the world’s #1 roadmap software, Aha! serves over 5,000 companies and 400,000 users. The Aha! Partner Program provides customers with access to a small and highly specialized group of certified partners that includes Praecipio Consulting. As a partner, Praecipio Consulting offers a wide range of product management and development services to extend the power of Aha! products.

Partnering with an innovation thought leader and one of the most respected SaaS companies will enable Praecipio Consulting to expand our reach and build on our current portfolio of cutting-edge technology solutions. Ultimately, our partnership with Aha! will allow us to better serve our clients  and advance their businesses. As one of the first partners, we benefit from the opportunity to deliver new services with close support and collaboration from the Aha! team. 

“We are honored to join the Aha! Partner Program as an inaugural member. Our diverse clients have varying sets of requirements, but common to them all is the need for a world-class product management solution. Aha! is a leader in this space and is a welcome addition to our portfolio of  technology solutions,” says Praecipio Consulting Founder & CEO, Christian Lane. 

"We are thrilled that Praecipio Consulting has joined our partner program to help customers innovate even faster and build products that customers really love. They are recognized experts in helping organizations achieve their digital transformation — by leveraging robust technologies and process frameworks like Agile, ITSM, DevOps, and ESM. We look forward to working closely together." — Brian de Haaff, Aha! co-founder and CEO. 

Praecipio Consulting also looks forward to what this partnership will bring as we continue pushing boundaries in the digital space with Aha!

Topics: technology technology-partners aha
3 min read

Tips for archiving your Confluence spaces

By Luis Machado on Oct 23, 2020 12:15:00 PM

Blogpost-display-image_Archiving Confluence spaces

Projects come and go, and sometimes what we once thought was a great idea may no longer be relevant or you've evolved your thought process. Since we're all undoubtedly great at documentation, chances are every one of your projects or endeavors has been noted or tracked in some fashion. Confluence, of course, is a great tool to do this with, especially if you organize your project all within the same space. But what do you do with that documentation when it's time to hang up the towel?

Usually, some record of your success or failure must be kept for posterity or perhaps, compliance. Whatever your motivations, archiving is important and Confluence allows us an easy way to do this natively. In this post, we'll focus on the native feature to archive spaces and also share some apps that could help you to organize archived content at the page level.

There are several reasons you might want to archive content in your Confluence instance, and it all depends on the life cycle of your projects or groups. To give an example, I worked for a game publisher for many years, and we would archive spaces after sunsetting (a term used to shut down a game product) one of our games. The major advantage to archiving is the content is still available in Confluence for reference purposes but won't show up in any page searches you perform nor will it appear in the Space Directory. This keeps your daily traffic from being cluttered with content from spaces that are no longer relevant to your business.

So you've reached a point in a project where it's officially time to move on, but the leadership team wants to keep the space for reference since some good ideas came out of the endeavor. Archiving the space seems to be the way to go, but how do you do that? Atlassian has put together a great document that details the steps for archiving in a cloud environment. To briefly summarize the process, you navigate to the portion of the space tools that contains the details and edit them, set the status to archived, and save. Pretty simple.

If at any time after archiving the space there is a request within your organization to review the archived content, you can link to the pages directly, and they will still be accessible. The search functionality within Confluence will automatically allow you to specify if you want to search through archived content in the case that the content available.

Atlassian also gives guidance on how to archive specific pages, which you can accomplish through a combination of manually moving pages and adjusting permissions to achieve similar results for the space archiving functionality. There are also third-party apps available, such as Better Content Archiving for Confluence, which gives you an increased toolset to make the archiving processes a bit less work. I recommend installing any third-party apps you wish to try into a dev or test environment before running on your production instance. One last thing to note, if you end up archiving a space accidentally or perhaps want to revisit an archived project and need the space to be active, you can easily change the archive setting to make the space available again.

If you need help managing your Confluence instance and want to learn how your organization can take full advantage of this tool, get in touch with Praecipio Consulting

Topics: best-practices confluence confluence-archives
3 min read

Atlassian Certification Program: Tips for studying for your ACP exams

By Rebecca Schwartz on Oct 21, 2020 12:45:00 PM

Blogpost-display-image_Atlassian Certification Program- Tips for studying for your ACP exams-1

Atlassian Certification Program (ACP) exams are a great way to enhance your Atlassian skillset and better leverage the tools at your organization. Atlassian offers a few different exams, depending on what aspects of the tools you're focused on and your current skill level. If you pass, you get a nifty badge you can place on your LinkedIn profile or email signature! Here at Praecipio Consulting, all of our consultants have taken at least one of the available ACP exams, and we have some great tips and tidbits to share that will help you prep for the tests and understand what they entail.

A little bit about the exams

  • Atlassian offers 6 different ACP exams
  • Exams are typically between 70-80 questions
  • Exams can be taken remotely due to COVID-19, but are proctored
  • Depending on the exam, the passing score is between 60-70%
  • You have 180 minutes (3 hours) to complete your exam

Take it back to your college days with study guides and flashcards

When studying for any exam, it's important to figure out how you best learn the material. Is it taking notes by hand so you don't have the distractions of a laptop? Or, are you more like me, where you tend to lose loose leaf paper so you prefer to type out what you've learned? Either way, the best tip I used to prepare for my exams was to organize my notes into a comprehensive study guide. Atlassian requires the completion of specific courseware before you can take the exams, and they provide downloadable PDFs for each exam topic. All of this information is great for your study guide. You can use a good ol' fashioned notebook for this, or, if you have access to Confluence, create your study guide there. I took notes on the courseware in Confluence, then used macros and Tasks to organize my notes and remind myself of topics that I needed to focus on. Because the exams cover a lot of material, flashcards are another great way to memorize information. There are several online services that allow you to create flashcards for free, such as Quizlet. Repetition works wonders when studying for any exam, so be sure to review your study materials several times.

Practice in a test environment

If your way of learning is by doing, a great way to prep is by reviewing admin functionality in your Jira or Confluence instance, especially if you have a test or demo environment. Project schemes, permissions (project and global), and workflow functionality can provide helpful knowledge around exam items. Chances are, if you're taking an ACP exam, you already have access to a Jira and/or Confluence environment, but if not, Atlassian offers a free Cloud instance if you're maintaining 10 users or less. Keep in mind that some exams only focus on Server functionality, but it's still great to get a visual for the items you'll be tested on.

Collaborate with others prepping for the exam

At Praecipio Consulting, we are all about teamwork. As I was prepping for my exam, so were several other Praecipians. We collaborated on our notes, shared our study guides, and had study groups. Sharing our thoughts and notes allowed us to each figure out our strengths and weaknesses around the exam material so we could help each other be successful. If you're the only one at your organization taking the exam, or are just deciding to do it individually, no worries - there are folks all around the world looking to get certified! If you venture over to the Atlassian Community, there are often discussions that folks have started to create study groups with members of the community (check out this post around the ACP-100). 

Stay in tune with your physical and mental state 

Prepping for and taking any exam is physically and mentally exhausting. It's important when studying to allow yourself breaks to better absorb the material. As I studied, I'd create incentives and goals around my study material. Once I got through half of my flashcards, for example, I'd watch the next episode of my newest Netflix addiction or read a chapter of my favorite book. That way, I had something to look forward to when studying and allotted plenty of time for brain breaks. When it comes to taking the exam, try to find a quiet space in your home where you can remain undistracted. If you get stuck on a question, mark it and come back to it - you've got 3 hours to get through the questions, so take your time! Remember, your well-being is a key factor in being able to focus and perform your best, so it's important to keep it in check.

Good luck with your next exam, and let us know if your organization needs further support with how to best leverage your Atlassian applications. 

Topics: atlassian agents training atlassian-products atlassian-certification-program
2 min read

What we can learn from MIT's Beer Game during disruptive times

By David Stannard on Oct 19, 2020 12:53:00 PM

Blogpost-display-image_COVID-19 – MIT’s Beer Game in Operation2

It has been said that one’s true character is exposed during times of crisis. Crises can also serve as an opportunity to compare theory against in situ behaviors, setting the stage for continuous improvement. 

In 1990 MIT lecturer, Peter Senge, released his book The Fifth Discipline, which was extremely influential for learning organizations. For me, it was my second encounter with MIT’s work on systems and the first non-engineering book that influenced the way I look at the world. Systems thinking is the fifth discipline that integrates the other four disciplines: personal mastery, mental models, building shared vision, and team learning.

Senge’s book summarized MIT’s “Beer Game” that MIT developed in the 1950s as a means to introduce dynamic system concepts. It describes what happens when a particular brand of beer suddenly experiences an unexpected upswing in demand. The game shows the difficulty in managing dynamic systems, and for this particular case, the supply chain for a single product – beer. I highly recommend reading the chapter or trying one of the simulations.

Reading The Fifth Discipline and using the simulation is one way to learn about dynamic systems. Another way to learn is just by living through this year, which has been synonymous with massive disruption and additional layers of complexity. It has provided us with the opportunity to directly experience the Beer Game for multiple products and multiple supply chains in real-time. So where was the missing toilet paper earlier this year? The missing Clorox wipes? The missing hand sanitizer? Did this only affect me? What about elsewhere? We may have mastered just-in-time supply chains and practices–complete with elegant models and all–but supply chains are in fact much more dynamic and complex. 

The average American family consumes 139 rolls of toilet paper annually year. Nice, boring, and predictable – just the way forecasters like it. Also, I’ve learned that toilet paper is a low margin business that is manufactured infrequently because of the forecasting’s reliability. 

Two of The Fifth Discipline’s eleven principles may provide insight: "today’s problems arise from previous choice” and "the harder you push the system, the harder it pushes back.” We have experienced unexpected shocks to the system this year, which has been further complicated by unpredictable consumer behavior. Consumers reacted by hoarding and impulsively buying substitutes for out-of-stock products, effectively magnifying the effects of a system under stress. 

During conversations with relatives residing in Germany, Serbia, Canada, and New Zealand, I learned that they didn't experience these shortages. Perhaps this is reasonable since they have different supply chains (or maybe we can blame the use of the metric system).

In 1997, Harvard Business Review recognized The Fifth Discipline as “one of the seminal management books of the past 75 years," and even though it's been 30 years since it was published, Senge's book is still relevant for those wanting to improve organizational performance. I recommend listening to the audio version or reading the text - it’s well worth the read.

Businesses everywhere have had the rug pulled from under them, and if you have faced challenges with your supply chain (or any other areas of your business), Praecipio Consulting can help with our tech-enabled business process solutions. Let us know how we can support you!

6 min read

Should I use Advanced Roadmaps for Jira if I'm not Agile?

By Amanda Babb on Oct 15, 2020 12:15:00 PM

Blogpost-display-image_Scaling Agile copy

As an Agile evangelist and a Digital Transformation-ist, I am asked this question from time to time. My first thought is, "Of course you're Agile...you just don't know it yet," but before I can actually answer that question, I have to understand the process. Every organization and agency in the world takes something, does something with it, and produces an end result. It's the process that is key for you and your organization to understand before implementing the Atlassian tools and specifically, Advanced Roadmaps for Jira (formerly known as Portfolio for Jira). 

At Praecipio Consulting, we call ourselves a bunch of process nerds that just happen to use the Atlassian tools to facilitate work. Think about making a pot of coffee: there are specific steps you have to take in a specific order to be successful. Starting the coffee pot before adding water and coffee doesn't work. Adding water and starting the coffee pot (without coffee) doesn't work either. There's a specific process that you need to follow to produce a pot of coffee. 

When it comes to work, what's the first step? How does the organization take in work? For those running traditional models, you may know this as Requirements. We have an idea that we'd like to propose, gather the requirements, and define the project scope. We then move to Design: expected function and architecture, and then to Implementation: actually putting the requirements into place in a product. In each of those phases, Advanced Roadmaps for Jira can help! 

What is Advanced Roadmaps for Jira? 

Advanced Roadmaps for Jira is a planning and roadmapping tool from Atlassian. It was first released in 2015 and has since developed into a powerful visualization tool for small-to-medium-sized organizations. With Atlassian's dedication to maintaining framework flexibility, it has evolved to become the tool of choice for many organizations, regardless of their self-proclamation. By supporting three estimation statistics (Days, Hours, and Story Points), Advanced Roadmaps for Jira can provide you with the best chance of success for understanding cross-team and organizational dependencies and answering the most important question, "When will this be done?" Purpose-built for Jira Software, Advanced Roadmaps for Jira supports mixed methodologies as well as framework-specific organizations. Add in the concept of multi-layer hierarchies, and you've got yourself a Work Breakdown Structure (WBS) as well as the ability to automatically schedule timelines based on Team capacity or velocity. 

Advanced Roadmaps for Jira adheres to the concept of the Iron Triangle. What is the scope? What is the timeline? Who are the resources (people) involved? Based on the estimated scope of work, the timeline in which I need to get it done by, and the people I have to do it with, will it be available on time? Simply choose the estimation statistic to calculate a schedule and you're off! Well, almost...

Scope: Where is the work being tracked in Jira? 

When creating a Plan in Advanced Roadmaps for Jira, the first thing to understand is the source. After establishing your hierarchy, determine where these Jira Issues exist. Where is work being performed in Jira? Is it in a specific Jira Project? Or perhaps a Kanban board for process visualization? Or across multiple projects? These are the sources for creating a Plan. You can use Jira Projects, Boards, or Filters as the source for a Plan. You can also use any combination thereof. However, aim for simplicity: use a Jira Project or a Board when you are able to instead of a complicated Filter as a source. 

We recommend using Filters as a source only when you need to manage stage-gates in your process. Using the example above, If the Statuses in your Jira Workflow are Requirements, Design, and Implementation, consider creating a filter that excludes Requirements. Just because it's a good idea, doesn't mean we will pursue it past the Requirements stage. In a Plan, we only want to see those things that made it through the stage-gate into Design. It's in the Design stage we will determine if or when we can get it done based on the timeline and people before moving into Implementation. We are not ready to Plan an effort until we've passed Requirements. 

Resources (Teams and Team Members): Who is doing the work in Jira?

While it's a bit chicken-egg, determining who is doing the work is critical to determining scope. In a Plan, we connect Teams and Team Members to the Sources in the Plan. This eliminates the need for clicking or typing or trying to assign a piece of work to the correct Team in a Plan. By connecting these, Advanced Roadmaps for Jira will determine the scope for the Teams and Team Members based on the source of the Plan. You also have the ability to tie multiple Teams to a single source. As an example, if you have two Teams managing their work in a single Jira Project, you can use the Project as a source for both Teams. By adding Team Members to the Teams, you can guarantee assigned work will be directed to the correct Team. However, unassigned work will be divvied up based on the next Team Member's availability. We recommend creating a single source per Team if both Teams cannot be assigned each others' work. 

Moreover, by adding Team Members to your Teams, you can determine the hourly capacity of each member. We see this most frequently used when specific job functions are split across Teams (e.g. QA or Design). By default, Advanced Roadmaps for Jira calculates 100% capacity at 40 hours per Team Member. If you need to split capacity across Teams, simply adjust the Team Member's capacity to 20 hours (50%) on one Team and 20 hours (50%) on the other Team. By using the Auto Schedule function in a Plan, you can then recalculate the timeline based on the change in capacity. 

Time: When will it be done?

This is where the power of Advanced Roadmaps for Jira truly shines. By using Releases (aka Versions), the Plan can calculate your probability of completing the effort on time. The Plan can also calculate when an effort will be complete based on Scope and Teams. For example, if I estimate my effort will take 4000 hours and the Team has a capacity of 200 hours, it will take 20 weeks to complete the effort. If my Release finish date is in 10 weeks, I will be off track by 10 weeks. The Plan will highlight this in red. 

Don't think of Releases as traditional "software releases". Instead, these are milestone dates for a specific Jira Project or across multiple Jira Projects. They can be calendar quarters, fiscal quarters, or even a specific date-driven event. By designating the Finish Date of a Release, you are determining the amount of time the organization has to complete a specific (or the entire) scope of work. 

Dependencies and Scenarios

Critical Path is a common concept in a traditional WBS. These larger milestone issues drive the entire schedule. If one moves, the rest move as well. In Advanced Roadmaps for Jira, we can manage this via Dependencies. By linking issues together, the Plan will schedule work using a finish-to-start dependency. Issue 1 must be complete before Issue 2 can start. Moreover, since items at the lower levels of the WBS drive the size and duration of the critical path, you can visualize a schedule slip based on the progress of the lower levels. 

Not sure you're ready to commit to a specific Plan? When trying to understand the "What if?" in each Plan, you can enable Scenarios. The Initial Scenario (default name) is used to understand current state: what the are Teams currently working on, the progress, schedule, and release dates. Creating additional Scenarios allows you to Plan for best-case or worst-case scenarios. What happens if I add capacity to the current scope of work? Will I be more likely to hit my Release (aka milestone) dates? By adding a Team to a Scenario (thus increasing capacity), you can Auto Schedule just that Scenario to determine if there is any impact to the overall schedule and any milestone dates. If you like what you see, you can update Jira Software from that specific Scenario and any other Scenarios will update based on the underlying Jira data. 

Want to know more? 

As an Atlassian Platinum Enterprise Solution Partner, Praecipio Consulting can help you determine the best way to leverage Advanced Roadmaps for Jira to support your intake, planning, and execution processes so that your organization can become more Agile. We have extensive experience in the entire Atlassian product suite and implementing Agile frameworks that provide a great foundation for your organization or agency. 

Topics: scaled-agile homepages agile advanced-roadmap
4 min read

Should I run my Jira Data Center on Linux or Windows?

By Yogi Kanakamedala on Oct 14, 2020 12:29:22 PM

Blogpost-display-image

This is a debate as old as the Operating Systems (OS) themselves and a discussion that never seems to end. Being in charge of making the decision between Linux or Windows for your team can be a hard choice. Currently, about 77% of all personal and professional computers around the world run Windows, while only about 1.84% of all computers run a Linux distro. Linux is the current choice of many organizations because of their development machines and servers. JIRA can run on either OS, with only slight differences as to how the software is managed and monitored. Linux offers better ability to write one-off scripts and utilities. It is important to note that Atlassian does developments and testing on Linux systems. Even though windows historically has performance issues compared to Linux, the gap has been reduced in recent years. Potential problems that Windows users face can be getting backups or processing data. Let's dive further into each OS and learn more about them! 

Operating System Overview

Before making any decisions, it is important to know the history, pros, and cons of each OS. 

Linux

LinuxLinux is an open-source, OS created by a Finnish student, Linus Torvalds, in 1991. This free and highly customizable OS is currently the choice of many organizations, large and small, as their development machines' and servers' OS. Most of the different flavors of Linux, called distributions or 'distros,' are built to use fewer hardware resources, making the overall system more efficient. Additionally, Linux is easy to customize and modify to the liking of the user due to the fact that the source code for it is available publicly. 

Because Linux is completely free, there is less traditional "technical support" available with the product. The available support comes in the form of paid support from a third party or from the Linux community through public chat boards and FAQ sites. Not all versions come with long-term support due to a slow rate of change when it comes to OS upgrades. 

With customizability and freedom to modify as needed comes with a steep learning curve. For example, remote access requires command-line knowledge. This is less intuitive than Windows graphical remote access interface. System changes and customization requires complex operation. 

One of the benefits that comes with an open-source OS is security. With many eyes around the world looking at the source code and improving it everyday, less and less attack vectors are found by malicious parties. Another reason for better security is obscurity. Linux, when compared to Windows, has considerably less market share, making Linux systems less of a target for attacks. 

Linux also offers some additional benefits. It is very easy to write custom scripts, users have full control on updates and changes, and lightweight architecture helps with performance.

Windows

windows

Windows is a for-profit product and was first launched by Microsoft in 1985, gaining popularity with the release of Windows 95 in 1995. This propelled Windows into being the leader of OSs around the world. One of the reasons for this popularity boom is the easy to use graphical interface that Windows is known for. Windows is usually the choice for novice and business users, as well as large companies looking for quick responses and dedicated support. As with all proprietary technologies, individual users experience less customization. Additionally, the OS is not going to be as optimized to hardware as Linux. 

When the OS is purchased, Microsoft provides integrated and online help to all customers. Getting personalized help is usually easier with Windows than with Linux. Due to the market share of Windows, almost all software products are designed with Windows in mind. Some Windows programs are simply not available in Linux. It is important to note that even while many third-party products are free, the majority of Microsoft products are only available at a cost. 

Windows was designed with ease of use in mind. Graphical interfaces are available for making most configurations. For example, to access remote servers, Windows offers a graphical remote desktop software. There is no need to be a command-line expert to customize the server. The learning curve for Windows is not as steep as Linux. This is really important for novice users and more proficient users may be frustrated by the lack of fine-tune control over the system or by the oversimplification of system tasks. 

Due to the popularity of Windows, the OS is a large target for malicious parties. Many security vulnerabilities and system instabilities have been reported throughout the years. To be fair, Microsoft has been able to make security improvements in response to the security leaks. Regular system upgrades and security fixes help protect sensitive data. 

So, should I run my Jira Server/Data Center on Linux or Windows?

As with many hard questions: it depends. Windows is more user friendly. The built-in remote desktop access makes it simple to make changes and update JIRA configurations. Linux servers may have a sharper learning curve and feel more demanding, but they perform better. Linux provides more customization options while working with JIRA and better security.

jira

The decision comes down to one main factor- comfort level. Having prior knowledge of Windows or Linux servers will go a long way in helping make the decision and will make working with JIRA easier. How comfortable is the team with each OS? It is also important to consider the style of the rest of the organization, as OS consistency is incredibly important for productivity and collaboration.

If your organization just wants to focus on development and not worry about managing JIRA, Praecipio Consulting can offer expert support services with our Atlassian Platinum Enterprise expertise and process focus. 

 

Topics: jira best-practices linux windows server
5 min read

Be Notorious Like RBG

By Shannon Fabert on Oct 12, 2020 9:15:00 AM

Blogpost-display-image_Social Justice- Be Notorious like RBG

The employees of Praecipio Consulting were devastated by the news of the passing of Supreme Court Justice Ruth Bader Ginsburg (RBG). To me, and to so many of us here, she was a role model and a major inspiration. I felt a deep and profound loss upon hearing the news. 

Many people don't know this about me, but the first time I remember somebody asking me what I wanted to be when I grew up, I said a Supreme Court Justice. I was only in 1st grade. While I don't remember anybody telling me that was a silly dream, I do remember people saying, "you should be xx instead." It almost always had nothing to do with being smart – it just wasn't what little girls grew up to do. Sandra Day O'Connor was nominated to the court as its first female justice when I was three years old. She was the only woman to serve until RBG was nominated when I was 15. There have been 113 Supreme Court Justices in the history of the United States, yet only four have been women. In 2015, RBG was asked when will there be enough women on the bench, and she said, "When there are nine." 

Regardless of one's political position, RBG's presence on the Supreme Court left an undeniable legacy for women and men across the world. In her memory, we encourage you to read through her 'dissents' during her time on the Supreme Court. While these are highly technical writings, her ability to intellectually challenge the majority voice using the written word absolutely astounds me, making them very worth the read. You don't have to look very far into any of these documents to pick up on the level of intentionality and acuteness she brought to the highest court in the land. 

Image Source: Librado Romero for The New York Times

Many different organizations have pulled together lists of her achievements as well, from co-founding the ACLU Women's Rights Project to winning cases before the Supreme Court, long before becoming a Justice.

There are several ways to reflect upon and honor her legacy:

Learn more about what she fought for

Many resources are readily available to learn about RBG and her legacy – here are a few you can start with!

Donate to organizations with the same values as RBG

Reach out to your senators and reps directly

Forget not that democracy is by and for the people. As constituents, there are several ways that we can provide feedback to our senators and representatives.

If you have feedback, here are some options for contacting your senators and representatives:

It is worth noting that if you want to reach somebody who is not your senator or representative, you will likely not get a response back, as they are not obligated to respond if they don't represent you. If looking to put pressure on or to support these people, signing petitions can be a great way to show support through sheer volume.

Reading this post is only one small thing we can do to remember the legacy that Ruth Bader Ginsburg left. So while you're learning more about her life, don't forget that you too can be Notorious like RBG

 

*At the time of publishing, the Center for Reproductive Rights is currently matching donations in Justice Ginsburg's name.

 

 

Topics: do-good social-justice
3 min read

Challenges in Managing Your Own Atlassian Instances

By Morgan Folsom on Oct 2, 2020 12:30:00 PM

Blogpost-display-image_Challenges in managing your own Atlassian instances

Are you having trouble managing your Atlassian instances? As tools like Jira become mission-critical to organizations, it's increasingly important that their maintenance is formalized, with dedicated resources who manage the tools. Let's walk through a few of the biggest challenges that we see and how Praecipio Consulting's Managed Services offering can help ease the pain.

 

Can you help if we don't have the technical experience to support the tools?

It's not uncommon that teams find themselves struggling to manage the specifics of Atlassian. Just because you've got a killer IT team doesn't mean they'll be experts on a whole new platform on day one! There are a lot of intricacies to the tools that can take admins a while to understand, especially when we're looking at Jira. On top of figuring out the technical aspects of maintaining the tools, you're also expected to help make process recommendations and changes for the teams that use the tool at your company. 

One of the biggest benefits of using a Managed Services provider is that you don't have to develop all of the in-depth expertise on the tools, because we've been there and done that. Our focus on the Atlassian suite means that we know the tools better than anyone so that in addition to answering your requests, we can anticipate issues because we know what to look for. 

What about about if our IT team is too small to have dedicated admins?

Maybe your team are experts at managing the Atlassian suite, but you're missing one major thing: time. Keeping your instances healthy requires ongoing maintenance, dedicating time for things like platform upgrades and marketplace app configuration, as well as triaging requests from your users to make the tools work for them. This is something that affects teams of all sizes and can be especially painful if you're part of a small organization. When you don't have dedicated Atlassian admins, the impact on your instances can be huge. If teams are only able to focus on addressing breakfixes and user requests, things like upgrading your marketplace apps can fall by the wayside. 

Our Managed Services team excels at thoroughly preparing for and executing upgrades, and regularly checking to make sure your instances and apps aren't affected by any critical security issues. 

Or what if we've moved to Cloud and don't know what administration we need to do anymore?

If you're one of the many organizations that have moved from hosted Server or Data Center instances to Atlassian's Cloud, you've probably realized that administration looks a little different now. Because a lot of the technical maintenance tasks aren't necessary anymore (woohoo!), your team gets to focus on making sure the instance is healthy from a process perspective. This kind of administration requires different skills from your admins – and while they hopefully have been providing this before, it's easy for this to fall through the cracks. 

Administration isn't just about creating workflows or fields, but making sure that the configuration in the instance aligns to industry and Jira best practice. Jira in particular is extremely configurable – with the right combination of apps and know-how, you can do basically anything, for better or worse. A lot of common configuration choices can be setting you up for future headaches – things like too heavy a reliance on scripting when out-of-the box configuration can do the same thing, making upgrades a pain and causing negative performance impacts. 

If any of the concerns above strike a chord, let us help

Topics: atlassian managed-services cloud atlassian-products atlassian-solution-partner
4 min read

Turn Your Next Project into a Promotion

By Christian Lane on Oct 1, 2020 1:15:00 PM

Blogpost-display-image_Do These Things to Leverage a Successful Project Into a Promotion

Make this next project the one that gets you noticed.

Kate Cornell was in a tough spot. Her fast company growth exposed a weakness. Her project management tools were a collection of cobbled-together solutions that were never purposely developed for case management or tracking complex projects. As a result, the team was fragmented and communications were inefficient, making work difficult to track. 

There had to be a better way. When the problem was presented to the management team, she was tasked with figuring it out.

Smartly, she knew that she needed some specialized help in not only choosing a platform but configuring it to meet the present and future needs of the company. After vetting multiple vendors, she chose Praecipio Consulting, a Platinum Atlassian Partner known for their strategic approach and ease to do business with, not to mention their expertise around the Atlassian platform.

katie aci blog post

In her role as the Director of IT Project Management for ACI Worldwide, it’s her responsibility to make sure projects like these are executed well. The company depends on it - careers depend on it.

Thankfully, this project was an enormous success. In a double win, the company was able to save significant costs and the Atlassian technology stack is exactly what they needed.  

Now that the project is complete, we asked her to reflect on the process and what she would recommend to others faced with a similar challenge.

Tell us about the vendor and how they performed for you. 

“I knew from the get-go that this is a project we needed help with. We used our previous CRM-based system for 10+ years, and there was an incredible amount of data that needed to be migrated over. But what impressed me most was their ability to ask questions and gather requirements. You can tell they had lots of experience. They led us in directions we didn’t know we needed to explore.”

What did success look like?

“I’m calling the project a huge success - first, because the solution works well. The data moved over, and we finally have everyone on the same tool. It’s nice to have a framework that is purpose-built for what we need. We’re able to move faster and with more efficiency than ever before. What I’m most proud of though is the broad adoption among our team. It’s hard to break out of your routine and use something new. Going through a necessary learning curve is difficult and cumbersome, but our team bought into the long-term vision and saw the value immediately.

What advice would you give project managers that want to fast forward their careers with a project like this?

Don’t operate in a silo. Design an escalation process so that when you get stuck, you can bring in other stakeholders to work toward a solution. Transparency is key. Managers don’t like surprises. They understand challenges will arise and usually, they are willing to help. But make sure you have a plan to execute and not just a problem with no solution. 

Set realistic expectations. I want my managers to commit to running at a rate of speed they feel is appropriate considering they have multiple projects. If we are managing the business correctly, everything is not an emergency. I can wait an extra two weeks if it means the project is done right the first time. 

Clearly define done. Ambiguity is a productivity killer and it can ruin relationships. The best managers we have err on the side of over-communication versus under. Making sure all relevant team members are aware of progress milestones, have an opportunity to provide input, and understand how this project fits within our overall mission is how it should be done. 

Be predictable and reliable. Successfully handling projects that deliver on time and within budget earns you a reputation as someone who delivers results. Our best managers are the ones that use company resources wisely and think one step ahead of the task at hand. This strategic mindset gives managers comfort knowing that they don’t have to worry about micromanaging.

Praecipio Consulting's take on how to leverage a successful project:

In our experience, we have seen how production-based project managers have climbed the ladder of success. One common theme? They make others around them better. Getting the most from your team and developing the talent of tomorrow has far-reaching implications for any company. At Praecipio Consulting, we are in the business of making our clients more competitive while helping them realize cost savings through better processes and better technology. IT project managers that have an upward career trajectory tend to not get caught up in technical jargon and can talk to the C-suite in terms of ROI and how the project fits into the strategic plan.

One thing all experts agree on is that communication between management, engineers, vendors, and even other third parties will mitigate the risk of a project losing momentum or failing. If your communication skills can match your ability to motivate teams and deliver technical projects, you’ll be asked to take on more and more important projects and be rewarded accordingly.

If you're interested in the game-changing solutions that Atlassian products can bring to your business, let's chat!

Topics: enterprise project-management atlassian-products atlassian-solution-partner
2 min read

How to Know If Your Organization Is Ready to Scale Agile

By Amanda Babb on Sep 28, 2020 12:15:00 PM

Blogpost-display-image_Scaling Agile

Are You Ready to Scale Agile? 

You are an Agile evangelist. You have championed the shift to Agile at your organization and have coached several teams successfully. Your organization is delivering quality product faster to your internal and external customers. But there's still a struggle to coordinate across different parts of the organization. And you get pulled into meeting after meeting to coordinate across teams. As a result, your most successful teams are expressing frustration with each other and, and now, quality has slipped. Something has to change. 

You've heard about scaling Agile. You may even have an idea of some of the well-known frameworks, such as SAFe, LeSS, Scrum@Scale, etc. But are you ready? Is your organization ready to scale Agile? 

Organizational Readiness

While this is not an exhaustive list, ask yourself and your organization these questions to assess your readiness to scale Agile. 

  • Which framework is best for your organization?
  • Do you have management and executive buy-in? 
  • Do you have funding for external training and certification?
  • Can you group teams together to support strategic initiatives?
  • Can you identify your change agents and champions?
  • Can you identify a set of teams to pilot the change?
  • How much time are you willing to commit to the change?
  • How much time do you have to commit to the change? 
  • How much time are you willing to commit to continuous learning? 

Iterate Your Framework Implementation

Just like the scaled Agile frameworks themselves, you approach their implementation iteratively. One of our clients chose and implemented SAFe for a single program and scaled iteratively. They started with one Agile Release Train and in three years scaled to four Agile Release Trains with the intention to launch an additional train before the end of the year. They also reorganized the Trains once they realized they were no longer organized around value and instead were structured in a traditional resource-management way. 

The implementation of SAFe within this client's organization, while it had a specific start date, was implemented iteratively and over time. It also took the backing of management and executives and a devoted set of change agents willing to take the steps for scale.

We here at Praecipio Consulting have assisted our clients in their journeys to scale Agile. Let us know how we can help you take your first step. 

Topics: scaled-agile safe agile
4 min read

How Spore-Infused Canola Oil Supports the Forest Ecosystem

By Christopher Pepe on Sep 25, 2020 11:54:55 AM

Blogpost-display-image_Steering a forest (1)

Last year I switched to grocery store canola oil to lubricate my chainsaw bar. I add Oyster mushroom spores into the oil so that they are dispersed while I cut. This method was developed by Paul Stamets of Fungi Perfecti and discussed in his book Mycelium Running. There doesn’t appear to be a commercially available product; however, by making it myself at close to the cost of conventional petroleum-based bar oil (~$15/gal), I improve my forest and should have some convenient forage this fall. I am still refining the process of infusing spores into canola oil, but if you are curious to try it, I’d be happy to swap notes.

Why vegetable oil?

Available since the mid-1980s, vegetable-based bar oil usage has grown more rapidly in Europe and is gaining adoption in the US. Workers’ occupational safety and health, and environmental protection are the biggest concerns caused by the thousands of gallons of petroleum-based bar oil that is left in our forests each year.

“Petroleum-based oils are known carcinogens and medical records show that they cause discomforting eczema and oil acne. In addition, prolonged exposure to petroleum-based-oil mist can cause irritation of the respiratory tract. Environmental damage caused by petroleum-based oil spills has had extensive attention from the media.[1]”

Whereas, canola oil “has excellent lubricating properties and some studies have shown up to 40 percent reduction in consumption without sacrificing bar-and-chain life.[1]” Again looking to Europe, we see that there are 80+ brands of vegetable-based bar oil in Germany alone. Austria has gone so far as to outlaw petroleum-based bar oil. Europe has even developed a standard (CEC-L-33-T-82) that measures the amount of oil that biodegrades over a 21-day period. Within that standard, products can contain some mineral oil additives. A popular choice in the US, STIHL BioPlus, degrades 93.8% in 21 days. Commercial vegetable-based bar oils cost about twice as much as petroleum products, which has hurt adoption. But with long-term environmental concerns and sustainability driving today's business decisions more than ever before, that additional cost will be more easily justified.

Canola oil is also a renewable product. It is worth considering that conventional agriculture relies on fossil fuels, and accounts for 10% of the US greenhouse gas emissions [2]. Canola-based bar oil is still seen as a net positive as it keeps the toxins in petroleum-based bar oil out of the forests, and we have the potential to change our agricultural footprint into the future.

Why mushrooms?

Saprobic mushrooms, the decomposers, are the cornerstone of returning nutrients back to the forest. Common native fungi include oysters and Turkey tail. As tree limbs and litter fall to the forest floor, saprobes reach up and consume them. Mycelium, the vegetative part of the mushroom, invades the tree litter, brings along water, and attracts insects that feed on the mycelium. Those insects attract birds and forest creatures to tear apart the rotting wood. The mushrooms start the process, decompose the most difficult tissues (lignin and cellulose), and invite the others to continue the job. This process converts wood back into soil.

There are many functions that mushrooms serve in our world. Oyster mushrooms are known to feed on nematodes[4] and are effective water filters. They’re used by humans and other animals as food and medicine. Turkey tail mushrooms contain anti-cancer medicines, are aggressive decomposers, and protect against parasitic fungi. Many of our best medicines have come from mushrooms and many more are expected to be discovered, especially in the few remaining sections of old-growth forests. There are dozens of powerful mushrooms that humans have partnered with and countless more that we don't even know the value of yet. Perhaps they will share their stories someday.

Why use spore infused canola oil?

Mushroom spores are everywhere. In fact, you have inhaled dozens since you started reading this article. Kathleen Stutzman, VFF’s Conservation Forester, gave me the sage advice that “the forest does not need you to be healthy.” Similarly, the mushrooms do not need me to find their way into deadwood. However, the choices that I make can help steer our forest in the direction I want it to go. By preferring some species, I can speed up decomposition and quickly build the thin soil on my rocky hillside. New research suggests that species like Turkey tail will also ward off potentially destructive species like the honey mushroom[3], one of which is the largest organism to ever live on earth. While honey mushrooms likely serve a function in the forest, they also cause a lot of financial hardship for timber companies. The jury is still out on honey mushrooms in my opinion, but Turkey tail and Oysters mushrooms help decompose everything 3” and smaller that I leave behind, provide us food and medicine, and support the entire forest ecosystem.

References

  1. https://www.fs.fed.us/eng/pubs/html/98511316/98511316.html
  2. https://www.ers.usda.gov/topics/natural-resources-environment/climate-change/
  3. https://www.youtube.com/watch?v=FPeBYnGwo4Y
  4. https://www.youtube.com/watch?v=vBWzrlCBhCM
Topics: carbon-footprint green-team
2 min read

Does a Project Manager fit into an Agile world?

By Marcelo Garza on Sep 18, 2020 10:15:00 AM

Blogpost-display-image_How does a Project Manager fit into an Agile world- (1)

Project managers have a wide range of responsibilities when working on a project: they are in charge of planning the project, creating a schedule and timeline, executing each phase, managing budgets, serving as the liaison among all stakeholders, and also troubleshooting and maintenance in addition to other activities. As such, a Project Manager(PM) must be very organized and detail-oriented. A PM also needs to have great people skills because, at the end of the day, this person is responsible for leading the team and communicating with all involved parties.

The Project Management Institute describes the role of a project manager as someone who acts as an agent of change. Someone who “makes project goals their own and uses their skills and expertise to inspire a sense of shared purpose within the project team.”

Project managers serve as leaders. Aside from ensuring the project is delivered on time and within the agreed-upon budget, they also encourage their teams and inspire their clients. They need to solve problems as they arise with strong critical-thinking capabilities while also possessing strong communication skills to ensure everyone remains informed, motivated, and onboard.

A good PM delivers a final product on time, on budget while meeting or exceeding client expectations. Tracing projects back to business goals is becoming increasingly necessary for project managers.

All brains on deck

The Agile framework focuses on self-organization and team empowerment rather than defining specific roles, which is why there is no need for a traditional command and control project manager; the project manager role is pretty much covered between all the existing roles there are.

Anyone who's ever taken an Agile class or training has heard of the defined roles of scrum master, product owner, and development team in the scrum framework, which makes no mention of the project manager role. I have taken five Agile classes from different places and never once have heard the word project manager. So, where does this skill set belong? Is there really no use for a project manager in an Agile setting? Is there nothing a project manager can do to add value to an Agile project? 

An Agile organization can–and does–function without a project manager. However, there is huge potential for a PM skill set to add value to an organization, specifically on large projects. I have worked in QA Testing across various complex projects for the past five years, and it is clear to me that a PM can greatly impact both the journey and outcome of the project in regards to budget and risk management, as well as coordination between multiple scrum teams.

A project manager can add value by managing key aspects of every project, overseeing budgets, risks, etc., especially on large scale projects for enterprise organizations. Having a project manager also frees up the scrum master to focus solely on his or her core functions.

Project Manager vs Agile management

agile project manager

If you are looking to scale Agile principles within your organization, our team at Praecipio Consulting has you covered. Feel free to reach out to us with any questions!

Topics: scaled-agile project-management agile
3 min read

What's important for growing pre-IPO companies?

By Christian Lane on Sep 17, 2020 12:15:00 PM

What's important for growing pre-IPO companies_

It’s a dream we all have: To be the founder or early employee in a company so disruptive that it has a real chance to hit it big. With success comes prestige, security, respect, and of course, lots of money. 

How can you set up your small business to become the next big thing?

The key is to learn from others who blazed the path before you and not make the same mistakes they did. 

Jim Collins, author of the iconic business book Good to Great, suggests that one of the most important factors in building a great company is to adopt the right technology early in your business lifecycle.  

“When used right, technology becomes an accelerator of momentum, not a creator of it.”

-Jim Collins

Whether your business is the manufacturing of widgets, service, or software development, technology is what allows you to spin up faster, pivot, and gain a competitive edge through efficiencies. Praecipio Consulting specializes in helping organizations leverage technology through the use of Atlassian’s suite of products and leading frameworks like Agile and Scaled Agile, ITSM, DevOps, and Enterprise Service Management. EVERY company is a technology company or is currently undergoing a transformation to operate with those capabilities and mindset.

Michael Corbat, CEO of Citi, agrees. In a recent keynote at Mobile World Congress, he said, “We see ourselves as a technology company with a banking license." Capital One’s CIO, Rob Alexander, says they are a “software development company that does financial services.” Mary Barra, CEO of General Motors, says she wants the public to “see GM as a technology company rather than an automaker.” Uber, Amazon, and other high-profile companies have made similar comments. It’s a common theme from organizations that have already had their IPO. Pre-IPO companies should take notice and follow their lead because it's what investors are looking for. 

Early investors want to see customer growth, not necessarily profitability. Having a plan to scale using technology can help a company get to a critical mass. For example, Twitter had 321 million users before they turned an annual profit in 2018. That figure would have been impossible to reach without cutting edge technology and processes.

But before you’re a big company eyeing a public offering, you have to start somewhere. When a business first starts, you usually have a founder or two with a good idea and the ambition to match. In a few months, when the concept is market-validated, a few motivated employees are hired. The excited team runs hard and fast but without established processes. Good ole’ fashioned hustle covers up any existing weaknesses. But eventually, the lack of infrastructure and tools catches up with the founders, and the business will begin to falter. If not acted upon quickly, failure is imminent. 

It’s at this point in a pre-IPO’s lifecycle that technology infusion becomes so critically important. It’s smart to set up your small business like it’s going to be a big business and plan for success.

We recommend moving toward standardization and being a cloud-first business. Utilizing platforms like Jira and Confluence keeps projects moving forward and with a high degree of predictability and reliability. Tools like these allow you to scale and will never be a choke point in your growth.   

It’s not just about growth either. It’s about sustainability and resilience. Even established companies like General Electric, Kroger, and Fitbit have found cloud computing success. Investors and boards of directors appreciate the risk mitigation in times of crisis and the flexibility that comes with the updated IT strategy. 

As a startup-founder myself, understanding the cost-benefit technology can bring you is just the first step. The details lie in implementation and design. It will always be worth the investment to bring in an outside consulting firm to design a workflow to reflect your desired processes. Training your team on how to use this technology as the backbone of your operations means you have a system for accountability and quality. Once in place, you can concentrate on building more, selling more, and not worrying whether or not your IT infrastructure can keep up.

Getting to the IPO means your company has joined a very select group of highly-efficient and promising companies of a generation, and the proper technology tools can help you get there faster.

At Praecipio Consulting, we are total Atlassian enthusiasts, so if you want to know more about how Atlassian products can help your business grow while becoming more resilient, we can answer any questions you may have!

Topics: atlassian devops technology service-management cloud itsm digital-transformation
5 min read

Jira Align vs. Advanced Roadmaps: Which one is right for my organization?

By Amanda Babb on Sep 15, 2020 8:15:00 AM

How Jira Align compares to Advanced Road for Jira

As organizations continue to scale Agile practices, our team at Praecipio Consulting is frequently asked which Atlassian product will best support the effort. Principal Consultant, Brian Nye, put together a great webinar describing the differences between Advanced Roadmaps for Jira (formerly known as Portfolio for Jira) and Jira Align. As Praecipio Consulting has expanded our Jira Align practice, we'd like to take a moment to compare and contrast these products to help guide you in making the right decision for your organization. 

Your Agile and Digital Transformation Journey

Your organization can't talk about your Agile transformation without talking about your digital transformation and vice versa. After all, the Atlassian products are meant to support Agile frameworks as well as your digital transformation. Many organizations have embraced remote work as a result of the global pandemic and have fundamentally shifted toward online planning, roadmapping, and execution management. 

Your organization may also use non-Atlassian applications to manage planning and roadmapping. You've chosen to integrate these products with Atlassian for execution management. While this may be a great solution in the short-term, I challenge this as a long-term solution. Many of the frameworks guiding agile-at-scale exist because we're trying to bring strategic planning closer to actual execution and back again. Ask your organization the hard question: does maintaining these integrations follow the organization's digital technology vision for the future? 

Advanced Roadmaps for Jira (formerly Portfolio for Jira)

Available as an App for Data Center/Server Deployments and packaged with Jira Software Cloud Premium, Advanced Roadmaps for Jira (Advanced Roadmaps) is a great way to bridge the gap for small- to medium-sized organizations. If you currently have fewer than 500 agile team members executing their work in Jira Software, Advanced Roadmaps for Jira can provide visibility within and across teams. First, define the hierarchy above the Jira Software Epic. We use Initiative most frequently when deploying this for customers because of the reference documentation from Atlassian. However, you can choose whichever naming convention you'd like as long as there is a corresponding Issue Type. For example, create an "Initiative" Issue Type and link it to a Hierarchy level in Advanced Roadmaps called "Initiative." We also strongly recommend the Initiative Issue Type live in a separate Jira Project from all other execution work. This helps your Agile teams focus on the current backlog of work while the Initiative moves through its own review, decision, and backlog refinement process. 

Creating a Plan is as simple as defining your source data (Jira Projects, Boards, or Filters), tying the sources to Teams, and choosing Releases from your source data. Honoring the Iron Triangle of project and program management, you may either choose to have the Plan dictate your schedule or, when planning for the next business quarter, you may choose to drag and drop the Gantt-style bars to schedule work. There is also an option to blend the calculations. Meaning, if a Sprint already exists and is pre-filled, let the Scrum Board be the source of truth. Have the Plan calculate any Empty Sprints going forward. The same is true for Releases and Teams: the Plan can auto-schedule a Team or a Release based on the relative rank of the backlog in the Plan. 

If you're looking to understand the impact of shifting priorities, you can enable Scenarios in a Plan. This will allow you to pull the source data from Jira Software and blend it with additional planning while maintaining the current execution schedule. You can add new Initiatives, Epics, and Stories, as well as adjust Release Dates, and observe the impact of adding, removing, or reassigning Teams to work. If you have the Server or Data Center App, you can group Plans together into a Program to understand the overall health of multiple Plans and Releases in a single view. 

Jira Align

As its name implies, Jira Align brings strategic planning and execution together in a single product. Pulling execution data from Jira Software and blending it with Agile-at-scale frameworks, Jira Align ties your strategic vision to tangible work and is best suited for organizations with more than 500 Agile team members executing their work in Jira Software. Instead of trying to define a hierarchy, Jira Align provides a pre-set hierarchy with flexible language. Whether you're running SAFe, LeSS, Scrum@Scale, or your own model, Jira Align's seamless integration with Jira Software provides visibility across multiple Portfolios and Programs. 

Jira Align comes in three deployment options: multi-tenant Cloud, single-tenant Cloud, and on-premise. While we recognize the allure of an on-premise solution, Praecipio Consulting recommends either the multi-tenant or single-tenant Cloud deployment. This provides the robust functionality of the product without the additional IT infrastructure management as well as managing routine maintenance such as upgrades. Jira Align also comes in two licensing models, Standard and Enterprise, billed monthly per user. Standard provides your organization the ability to run Programs (also known as teams of teams) whereas Enterprise adds the Lean Portfolio Management and financials into the mix. In addition, each Jira Align seat comes with four Jira, Trello, or integrated users. Another key difference between the two license levels is integration. With Standard, you can integrate a single instance of Jira Software with Jira Align. This is perfect for the organization that is large enough but lacks maturity in their Agile-at-scale framework. Enterprise provides unlimited connectors, which in the case of some of our clients, allows them to avoid the pain of merging multiple instances of Jira Software before deploying Jira Align

The Jira Software Epic is the lynchpin of the integration. Teams will still work with Epics, Stories, and Sub-Tasks within Jira Software whereas Product Managers, Release Train Engineers, Portfolio Managers, and Executives work within Jira Align. The robust permissions within Jira Align also focus the right role in the right data. A Program Manager may care about the execution of the program, whereas the executive wants to understand how you're tracking to the annual corporate strategy. By aggregating and rolling data upward, Jira Align provides health and status monitoring of quarterly, yearly, and long-term goals. With over 180 out-of-the box reports, every role at every level can access the right information at the right time to ensure your organization's success. Jira Align also has Enterprise Insights, an optional App, to take business intelligence to the next level. 

Which one is right for my organization? 

The first questions to answer while you're evaluating either tool are around Agile transformation maturity, digital transformation maturity, and user discipline both across and vertically in the organization. Because both options rely on teams to perform their execution work consistently and with good data integrity, either product can be a blessing or a curse. 

  • How long have your Agile teams been executing within an agile framework? 
  • How long have your Agile teams been executing within Jira Software? 
  • How consistent are your teams across the organization? 
  • Do your teams and your business understand one another and communicate well? 
  • How well has your Jira Software instance been governed since it was deployed?
  • How much chaff do you have in Jira Software? 

While this is not an exhaustive list, implementing either Advanced Roadmaps for Jira or Jira Align requires you to ask tough questions of your organization. Praecipio Consulting can not only help you assess your current state, but we can also provide guidance and recommendations to accelerate your digital transformation. If you are ready to take the next step in your digital transformation and Agile journeys, let's chat!

Topics: scaled-agile jira-align agile advanced-roadmap marketplace-apps
4 min read

Why You Should Upgrade Your Atlassian Stack

By Suze Treacy on Sep 4, 2020 12:15:00 PM

Blogpost-display-image_Why upgrade your Atlassian stack-

One key component of managing your Atlassian applications is managing their upgrades. Upgrades can present a daunting and significant time investment for many companies, generally involving applications, add-ons, and integrations, with a large number of users dependent on the 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 you've missed the email updates based on your subscription. 

You 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 to secure the instance; after three days, two full sweeps of the instance and multiple upgrades, the vulnerabilities are mitigated and your instance is safe.

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

End of Life Policy

Once Atlassian releases 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. This is when many Atlassian Administrators 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:

Screen Shot 2020-06-03 at 8.40.10 PM

 

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, servers or infrastructure devices, or are straightforward to exploit.

Current security advisories can be found here.

New Functionality/Capabilities

Did you know that there is a new feature release for Jira Software every 6 weeks alone? Atlassian encourages users to submit bugs and feature requests at jira.atlassian.com. This public forum allows users to vote for and comment on submitted issues. Then, the Atlassian teams review 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. Generally designated annually, feature releases 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 adds and deprecates 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? In addition, 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.

App (Plugin) Support

If you are one of the many teams who utilize Apps (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 has developed the Universal Plugin Manager, available in both Jira and Confluence, to enable you to screen for any compatibility problems before 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: No adverse impacts to the target version
  • Compatible if updated: the plugin is not currently compatible, but will be once running the compatible version
  • Compatible once both are updated: the new version of the plugin isn't compatible with your current instance version and 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. 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 must take an intermediate step to upgrade to a 7.X version. Due to the functionality changes being much greater between platform releases that 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 is fully dedicated to the Atlassian stack and can offer you peace of mind by managing, supporting, and maintaining your Atlassian tools. This allows you to maximize the benefits of your Atlassian applications and empowers your team focus on what they do best. Working with our Managed Services team offers you expertise and best practices that draw from our wealth of experience and from 15 years working with the tools. We take the maintenance process off your plate, making sure that your tools–and your team–run at peak performance.

If you're ready to hand upgrades off to our experts, get it touch with our team to learn more about our Managed Services offering.

 

 

Topics: managed-services upgrade atlassian-products
3 min read

Why Jira Won't Make You Agile

By Morgan Folsom on Sep 2, 2020 12:15:00 PM

Blogpost-display-image_Jira Wont Make You Agile

It's no secret that here at Praecipio Consulting, we love Atlassianwe love Agile, and we especially love using Atlassian tools to Agile ends. The Atlassian suite (Jira, in particular) has been built to reinforce a lot of the concepts that are core to functioning in an Agile way, which is one of the many reasons that 83% of the Fortune 500 use it. So, setting up Jira is often one of the first steps companies take when they want to adopt the Agile framework. 

However (and this is a big one!), Jira, or any other tool, should absolutely not be the first step in your Agile transformation. 

Here's why:

Tools Won't Change Mindsets

If you've ever happened upon the Agile Manifesto, then you might guess where I'm going here. The very first line of the Agile Manifesto reads:

"Individuals and Interactions OVER Processes and Tools"

Agile is not something that you "do" to an organization by giving your developers Jira and having daily status updates that you call stand-ups. Rather, an Agile transformation is the process of rethinking how you deliver value to your customers from the ground up. It might sound like a big undertaking, and that's because it is! There's a good reason that "transformation" is the word we use to describe this process (I could insert a cheesy metaphor about butterflies, chrysalis, etc., but I think you get the idea). Now, while part of successfully running an organization means identifying tools that help your employees do their jobs well, the function of your process and tools is to support the individuals and interactions. 

Sure, we can use Jira to enforce some good Agile practices, but if teams don't know what the practices are or care why they're doing it, you won't get the same value out of them. The tools should be enforcing values that have been established, keeping teams from veering too off-path, but they are simply not an effective way of establishing values in the first place. 

Jira's not broken, you're just not Agile

While Jira can be customized to do almost anything you want, there are some structures in place that enforce Agile best practices. There are small things that work perfectly if your teams are well-aligned to best practices, but are huge headaches if you've got bad practices.

The most common example of this that I see is the struggle to manage sub-tasks in Sprints. Many teams use Sub-tasks to break down stories and bugs into smaller pieces of work. However, Jira will not allow you to close a Sprint if you've got stories with open sub-tasks. From a process perspective, this makes sense - your story isn't done until all of the work is done, which means you don't get credit for a story until it, and all of the work beneath it, are Done. Teams fight against this, wanting partial credit for the story that's not been completed. Ultimately, the problem here is not Jira - Jira is enforcing a good practice. The problem is the underlying process - maybe the team hasn't had the discussions about the Definition of Done, or they are getting pressure from above to complete a certain number of story points in a Sprint, or QA is not part of the team, so they're hitting bottlenecks along the way, etc. 

Examples like this come up often. Jira will enforce some fundamentals, and your failure to meet those minimum lines can make it look like the tool doesn't work for you. We can see another example in this hotly-debated blog titled Jira is an antipattern. This article posits that the use of Jira is a good sign that an organization's off-track, and while we explicitly disagree with the thesis, it highlights effectively why Jira cannot be the driver. Trying to use a tool to drive your Agile transformation can easily make it look like the tool is the problem, obscuring the underlying changes that need to be made. 

Ultimately, Jira is a great tool for supporting those Individuals and Interactions the Agile Manifesto highlights, but it is essential to remember that's just what it is: support. Trying to use Jira to drive your Agile transformations sets your teams up for failure if you're applying those rules and structures before even explaining what their purpose. 

When we say we love Agile, we mean it. If you'd like some guidance in your journey to Agile transformation and how to properly set your teams up for success with Jira, get in touch with the Praecipio Consulting team

Topics: jira scaled-agile jira-software agile
5 min read

Should We Use Next-Gen Projects in Jira Cloud?

By Amanda Babb on Aug 28, 2020 9:30:00 AM

Benefits of Next-Gen projects

Atlassian has always held the concept of the team in high regard. As you may know, even their stock ticker is TEAM. And with many organizations pushing to Atlassian Cloud from their Server or Data Center solutions, it's no wonder Atlassian is removing barriers to entry for first-time users and admins. Whether you choose Standard or Premium, Jira Software adds the ability to create next-gen projects.

What is a next-gen project? 

Jira Software next-gen projects are a simple and flexible way to get your teams working. With some limited delegated administration, next-gen projects are created using a pre-defined template (Kanban or Scrum). These projects also come with three pre-defined roles: Administrator, Member, and Viewer.

  • Administrator: Updates project settings and can add other Administrators
  • Member: Can perform most functions such as create, edit, assign, and transition issues
  • Viewer: Can view and comment only

By default, if a user is added to the Jira Cloud site and provided access to Jira Software, they automatically become a member of every next-gen project (also known as Open). However, a next-gen admin can change the settings to be either Limited or Private. Limited puts all users of Jira software into the Viewer role and Private requires the admin to add a user to perform actions in the project. In addition, setting the project to Private hides the project from any search results. 

Each next-gen project operates similarly to a Classic Software project. You get either a Kanban or Scrum Board based on your project template as well as the reports you've come to know and love from the Server and Data Center products. One key difference is the addition of a Roadmap. Each next-gen project and board comes with a Roadmap. This allows teams to track start and end dates of the epics and better communicate with their product owners and stakeholders. 

The benefits of a next-gen project

Next-gen projects are flexible and delegate administration to the Administrators. This means the Administrator can create new Issue Types and Workflows, add unique fields, assign access to individuals or groups, and can enable or disable specific agile features such as enabling backlogs. This provides the ultimate flexibility for newly formed agile teams to work out their processes and data needs while performing their daily work. Let's take a closer look at each of these elements. 

Issue Types can be created on the fly at any time. As an Administrator, you can add up to 30 unique issue types to your next-gen project. By default, next-gen projects come with Epics, Stories, Bugs, Tasks, and Subtasks. If you remember, these are arranged in a loose hierarchy with Epics at the top; Stories, Bugs, and Tasks in the middle; and Subtasks on the bottom. Currently, any additional issue types will be added at the same level as Stories, Bugs and Tasks. If you'd like to add your own Subtasks or parent issues, feel free to submit feedback to Atlassian. 

Workflows are configured directly on your Board. Simply add a column to add a status to your workflow. That's it. You may also add rules such as assigning an issue or updating a field. Other Marketplace Apps can add automation triggers and the like to next-gen projects as well. 

Administrators can also add Custom Fields for your project. While Jira already comes with a robust set of Jira-created fields, you may choose to add checkboxes, people fields, numbers, dates, dropdowns and more. You can even change the order of the fields on the issue view to put the most important information at the top. 

Notifications on certain events can also be tuned to suit the team's need. For those already familiar with notifications, these events include: Issue Created, Issue Updated, Issue Assigned, Issue Deleted, etc. In a next-gen project, you can notify All Watchers, Current Assignee, Current User, Reporter, or a Project Role. Simply select the event and the people you'd like to notify, and Jira will take care of the rest. 

Last, but not least, there are nine separate Board features you may choose to enable for your next-gen project. This includes things like the Roadmap, Reports, Backlogs for Kanban, and more. 

There's no doubt that next-gen projects provide your team the ultimate flexibility in managing their work. With easily navigable menus and a simplified Administration interface, next-gen projects can be great for you and your team. 

The disadvantages of a next-gen project

One of the things we love about the Atlassian products is that they are super flexible and you can do pretty much anything you'd like with them. One of the things we hate about the Atlassian products is that they are super flexible and you can do pretty much anything you'd like with them. The same is true of next-gen projects. With ultimate flexibility and delegated administration, it becomes difficult to aggregate data across multiple projects. As a product manager, project manager, Release Train Engineer, or other person over several teams, you may find next-gen projects frustrating. 

Because the configuration of a next-gen project is unique to the individual project, gathering a status update is difficult. Not impossible, but you need a solid working knowledge of Jira Query Language (JQL) and good discipline from your teams to ensure they're transitioning tickets through the workflow. Creating custom Filters and Dashboards is your only way to aggregate data across projects. In addition, since each team can create their own custom fields, you risk data bloat. For example, one team may create a field called Bug Type using a dropdown and another may create Bug Type using checkboxes. While both are correct, to understand where Bugs are located, you have to add both fields to your filter. And the values may be unique per project as well. 

Work can only be estimated in Story Points, regardless if your project is Kanban or Scrum. This is also regardless of Issue Type. If you enable estimation on either a Scrum or Kanban next-gen project, every piece of work should be estimated and estimated in Story Points. Tasks, Bugs, and Stories all need points to establish a consistent velocity for predictability. 

Since there is a single workflow for all Issue Types, the team cannot split processes between types of work. If a Task follows a simplified process (To Do, In Progress, and Done), but a Story needs more detail (Backlog, Selected for Development, In Progress, and Done), the team cannot split these items into two distinct workflows. Every type of work must follow the same path through the board. 

There are additional technical considerations as well for things like Cloud merges (bringing two instances together) and Cloud to Server or Data Center migrations (moving off Atlassian Cloud to an On Premise solution). While these efforts are few and far between, all next-gen projects must be converted to Classic projects before these efforts start. 

Are next-gen projects right for you? 

At Praecipio Consulting, we believe you must use the right tool for the right job. The same goes for next-gen projects. While there are many benefits, there are disadvantages as well. How do you manage cross-team dependencies? Are you willing to span multiple projects for status updates? Do you trust your teams to make the most out of the functionality? Are there long-term scaling opportunities you need to consider, such as integrations, or other products, such as Advanced Roadmaps, for Jira or Jira Align? If you'd like to know more about next-gen versus classic Jira Software projects, Praecipio Consulting has extensive experience managing and assisting clients with these questions and more. 

 

Topics: best-practices business-teams cloud atlassian-products jira-align next-gen-project
7 min read

CICD: The Software Value Stream to your Customer

By Christopher Pepe on Aug 26, 2020 12:45:00 PM

DevOps Best Practices that connect you to your customer

Level Set of Terms

Before we dive into today's blog post, let's get familiar with these terms:

  • DevOps: A mix of cultural and technology practices to improve the use of software and technology-servicing customers.
  • Continuous Integration (CI): Traditionally, a developer spends their day coding, and at some point, they save (commit) their efforts within a development environment or an application branch. Think about a tree. Do you want one full of intertangled branches (loads of developers, all doing something, but getting in each other’s way), or do you want a well-balanced tree with a solid trunk? The same is true with coding, and CI allows for the integration of code to the trunk as fast as possible via agreed testing success. If the system fails (a diseased branch), then the feedback is fast enough that the code can be fixed and resubmitted. Note that the approval and commit steps are manual but the expectation is that they are performed daily at a minimum.
  • Continuous Delivery (CD): Removes the manual step and introduces automated approval based on testing success to push software to the trunk. CD eliminated the authorization wait time found in CI, thereby decreasing the feedback time. Faster feedback equals faster fixes, which underpins the culture of “if no defect found, then proceed to the next step in the software value stream.”
  • Continuous Deployment: I call this the ‘Trust My Developer’ process. Testing, packaging of code, release, and deployment (to the correct trunk or environment) are as automated as possible. We trust the process, the tools, and the quality of the code, and therefore we know that if there is an issue, we can also remove any code causing problems as quickly as possible. Feedback from the customer on the new applications or features is immediate.

How we created these practices: A bit of history

Software is what makes technology exciting, as it is often the software elements that make things happen, solve problems, or fulfill needs. It stands to reason then that the flow of software to a customer needs to be as fast as possible. Unfortunately, in many businesses today, that flow is a mixture of work, wait time, approval time, and probably rework. 

Does your software stream look like this?

  • Receive the request for something to be changed (new, feature or fix)
  • Wait
  • Get it approved
  • Wait
  • Pass it to a team as something to do
  • Wait
  • The team at some point begins to work on it
  • They finish their work and pass it to another team to add their code, or they give it to a test team
  • Wait
  • The test team schedules the environments for testing: code, security, performance, business continuity
  • Wait
  • After authorization, the code is deployed at the pre-set monthly or quarterly release
  • Wait
  • The code is released
  • Pray that it works and that things have not changed so much since the original request

Do you recognize your lengthy cycle of innovation? It doesn’t have to be this way, thanks to the practices of DevOps: Continuous Integration, Continuous Delivery, and Continuous Deployment.

Timewarp to today

What do your staff or customers want? Quality, fair cost, sustainability, resilience, and practicality. They want technology that helps them and, preferably, they want it now. Given the interconnectedness of the world, if a customer does not find satisfaction with you, then they go elsewhere within a mouse click. Your business peers can also do the same, hence this is how Shadow-IT (when peers circumvent formal IT processes) begins.

But what if:

  • Requests are assessed within a short time of receipt?
  • When the team began working on the request (either some aspect, if not the full request), was ready it for use within a sprint (two weeks to a month)?
  • As much as possible, the culture is that if no defect is found, the request moves to another team or goes live?
  • If the request can be improved, then how?

Jez Humble and Dave Farley best explained these practices in their book Continuous Delivery. Major software vendors such as Atlassian built their products based on these concepts (and have an excellent series of blog posts showing the why and how). It is becoming more and more difficult to find a business that does not depend on software, so why have processes that limit the use and improvement of your products or services? Sounds like nirvana (or a significant culture change).

Some of you by now are thinking that this can never happen where you work. I won’t quote how many times a day banks, Amazon, or even the latest start-ups that were born during the pandemic, deliver software to customers.

Tip: Look at sites from mature DevOps companies like Netflix and Amazon, and make that your goal so that you can work towards creating meaningful change within your organization. 

The CICDCD+ culture:

  • No defect goes live
  • No defect goes to the next environment
  • Ideally have no more than three environments; two is even better
  • Automate as and when we can
  • Test multiple times, as often as we can
  • Trust in the tools we use
  • Trust in the people that use those tools
  • Ability to roll back (uninstall code) as quickly as we can promote code
  • Limit the amount of work performed at any given time
  • Limit the size of our changes (make smaller changes?)
  • Changes are independent of the application or data (yes this is hard)
  • Every day is a new day during which we strive to improve the process

The Gap of Change: Are you ready?

CI implies that your organization wants to create and improve a pipeline of software to your customer. You also agree that management is going to allow the technology and governance processes to be available to develop, maintain, and improve the pipeline. CD also implies that you are satisfied with the flow of software, the timely feedback of information related to software value, and issues are resolved before working on other code. Automation is used to automate the approval of changes and the delivery to the appropriate environments or customers.

CD+ implies that you are content with both the culture and technology of software and how development and deployment have matured. You are ready to automate as much of the process as possible. Changes are small and independent enough that if there is an issue, they are quickly revoked. Minor changes also mean that customers get spoon-fed new software, one feature at a time. Documentation and recovery are both simplified, and the cost of software reduced.

Remember that there is no value in anything you do in technology until it is used to help someone fulfill a need or solve a problem. Until that time, everything you do or spend money on is a waste. Limit your waste by trying these practices. In the next blog, we will explore the metrics of CICDCD+, and the final blog of this series will provide tips from the leadership aspect.

If you have any questions in the meantime about any of the concepts discussed in this post, let us know

Topics: devops continuous-improvement customer-experience cicd
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 migrations cloud hosting atlassian-products podcast
5 min read

Common Agile Myths: Everything's Made Up and the Points Don't Matter

By Amanda Babb on Aug 14, 2020 4:00:00 PM

2020 Blogposts_Everythings Made Up and the Points Dont Matter- Common Agile Myths

Type "Agile myths" in your favorite search engine and you'll be amazed at the plethora of results. Especially those that say, "Top myths busted!" While I consider myself an Agile evangelist, I'd like to take a moment to discuss the harsh reality that many organizations face day-to-day. Agile is not a new concept, but the term is. The Agile Manifesto codified the term and working agreements in 2001, but I (and other evangelists) argue that it existed way before the term was formalized then attached strictly to software development. 

Iterative Development of Complex Systems

"I felt exactly how you would feel if you were getting ready to launch and knew you were sitting on top of 2 million parts — all built by the lowest bidder on a government contract." - attributed to astronaut and U.S. Senator John Glenn 

There were three Apollo missions before a person was ever placed in a rocket to (eventually) go to the moon. February through August of 1966 saw rocket, heat shield, and in-orbit fuel performance tests before a person set foot in the capsules. After the tragedy of Apollo 1, three more unmanned missions were flown before NASA decided to try again. It took an additional four Apollo missions before Apollo 11, and the iconic first step happened in 1969. That giant leap didn't happen with Big Up Front Requirements. It happened with teams of teams working together, iterating, retrospecting, and making adjustments. Isn't that Agile and moreover Agile at scale? 

How many other times in history did we as humans nail something the first time? The Wright Brothers didn't just magically produce an airplane that sustained controlled flight in 1903. Carl Faberge didn't create imperial eggs immediately upon his return to St. Petersburg in 1872. It's not called WD-1, it's called WD-40. Agile is how we've developed some of our greatest inventions, art, and human achievements. 

Scrum versus Kanban Agile

Let's take a step back and look at the two most popular frameworks of Agile: Scrum and Kanban. Instead of boring you with the typical definitions, instead, let's look at why teams and organizations think they choose one over the other. 

Scrum

"I am guaranteed to release product to my customers every two weeks."

Potentially shippable product does not mean it's in the hands of the customers. It means it meets the team's definition of done. It may have to be deployed into an integration or stage environment before production for further integration and testing before being released. 

"We don't have to estimate capacity, we just estimate the work."

Scrum (and Agile in general) is about predictability. If you delivered an amount of work this sprint, you should be able to deliver a similar amount for "the next sprint. If your velocity makes wild swings from sprint to sprint, there's a larger problem. A good team plans their sprint delivery based on their past performance. Which leads to another one...

"There is no long-term planning, just short-term execution."

Scrum is where long-term product planning meets short-term execution. Products and product features are extremely long-lived if they are the right things. No one wants to spend time and money on things that customers won't use or don't work.  

Kanban

"We do Kanban because Scrum takes too much time."

Kanban was born from lean manufacturing. There is always a daily standup at the beginning of the shift. In best-in-class manufacturing, there is also a weekly meeting for metrics and a monthly safety meeting. In order to be successful, your Kanban teams should be taking almost the same amount of time!

"Kanban isn't planned or managed. Just executed."

The Kanban backlog is just as refined as a Scrum backlog. Based on classes of service, the team plans their work each day and throughout the week. For example, work in the "standard" class of service is defined as start to finish in the calendar week. 

"Our team isn't a software development team."

I waver on this one. Unless you are pure customer service (think call center), you likely have larger projects you're trying to complete. 

So what?

Given all of the above, it's safe to say there is definitely no single right way to be Agile (although there are LOTs of wrong ways!). As an organization, there will likely be growing pains while you try to figure out how teams work best. 

Agile is not a thing you do. It's not a software development framework. It's not a 40-hour skill. Or a two-week sprint skill. Or even a Program Increment skill. It's a mindset...nay...I would argue it's a lifestyle. Agile is all around us if you open yourself to it. 

 

Looking for more tips on how to be Agile? Check out Agile Batch Size: An Ode to Laundry or The ABC's of Agile. And if you want to know more about how to successfully implement Agile in your organization, reach out to us

Topics: scaled-agile enterprise kanban scrum agile
3 min read

Praecipio Consulting's Commitment to Social Justice

By Christian Lane on Aug 13, 2020 12:45:00 PM

2020 Blogposts_Social Justice Public Statement_

At Praecipio Consulting, we are committed to our communities as we continue to fight back against the systemic racism and police brutality that has plagued this country for far too long. Like many of you, we are hurting as we try to process the tragic and senseless deaths of George Floyd, Ahmaud Arbery, Breonna Taylor, Brayla Stone, and too many others. 

We believe that Black Lives Matter. Therefore, we are committed to educating ourselves, and listening to and amplifying Black voices.

It is troubling that, in the wealthiest country in the world, we’ve yet to fully realize our constitution's values of justice and equality. Yet, this is an old truth. Like many privileged Americans, we’ve struggled with finding a way to make an impact to help, support and participate in the movements that work tirelessly for justice and to reform the laws of systemic racism. We have problems. Black Americans and other historically marginalized groups continue to be oppressed. Black American men are profiled, incarcerated, and killed unjustifiably at astonishing rates; this is systemic – we need reform on so many fronts, now. COVID-19 is exacerbating the disproportionate load and stress on the marginalized; the gap between the haves and have-nots is expanding faster and wider than ever.

We believe that Praecipio Consulting has a responsibility to its employees and communities to uplift marginalized voices and groups. In doing so, we recognize the intersections of race, ethnicity, class, culture, nationality, immigration status, gender, sexuality, ability, age, and all social systems. We will work to bridge the equity gap and build communities that welcome and affirm people to be their whole selves, honoring unique identities and life experiences. 

As an immediate step, on June 2nd, we began matching employee donations and doubling Volunteer Time Off (VTO) toward relevant organizations and causes and created a Social Justice team. Today, we'd like to share with you our Social Justice team's plans.

Praecipio Consulting's Social Justice team's mission is to bring social, political, and economic awareness to the forefront by investing time and effort towards the education, advocacy, and required participation needed to enact invaluable change for marginalized groups in our society.

We are taking the following actions both internally and externally to make our mission a reality.

  • Internal Education - pulling together colleagues to educate ourselves with a Social Justice Learning club that will include books and documentaries, holding Lunch & Learns focused on these topics, and building a resource library for our company.
  • Community Engagement - identifying organizations in our communities with whom to partner and volunteer, aligning ourselves with actions and events addressing social injustice and change, and determining how we can be that change within our own circle of influence. We will seek opportunities in education, justice reform, environment, health care, and economic impact.
  • Direct Support - invest our time, equity and profit through our commitment to Pledge 1% to organizations doing social justice work.

Transformative change comes from our collective voice and actions. We will continue to embrace and celebrate diversity. As a business with a large platform, we understand that we have a responsibility to do more in spreading the message of love over hate and doing our part in building a more inclusive, equitable, and sustainable world.

"Nothing can stop the power of a committed and determined people to make a difference in our society. Why? Because human beings are the most dynamic link to the divine on this planet.”

- Representative John Lewis

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

Enterprise Service Management Blog Series (Part 2): Three Key Benefits of ESM

By Praecipio Consulting on Aug 5, 2020 4:48:47 PM

2020 Blogposts_What is Enterprise Service Management-2

If one system can do with relative ease what it used to take multiple systems to do, it makes sense to use that one system, right? Following up on our first blog post of this series, we continue to explore the benefits that ESM brings to an organization. 

Historically, the toughest part of this statement had been that one system could not do what multiple systems could, resulting in a need to keep those multiple systems in place. However, software has advanced to the point where this is not the case anymore. As an example, Jira Software was originally developed for software development teams to track bugs and was not feasible for an HR or Legal team to use. Today, its flexible workflows, security controls, ease of visibility, and several other characteristics have allowed all teams within the organization to use Jira. This has given way to the rise of Enterprise Service Management (ESM) as teams realize that they can simplify their software landscape and reduce the number of systems in play.

Consider three specific benefits of replacing multiple systems with one:

  1. Eliminate clunky handoffs. The toughest part of the process to understand and improve the handoff from one system to another. In addition to evolving teams, the work itself tends to change physical form, from an Excel spreadsheet to a Jira issue to a Salesforce ticket and so on. This creates unnecessary steps in the process and requires extra time to convert and understand the work. This behavior is not the result of intelligent design, but rather a factor of history and the way things evolved. Condensing to one system helps eliminate these physical shifts, resulting in cleaner handoffs and reduced process time.
  2. Include a rich history. When an item moves from one system to another, its history can get lost. A classic example is when a developer has a work item without the original business requirements or design thoughts from upstream teams. Cutting down to one system provides the team with the ability to receive the entire history of the work item. This rich history provides valuable context, eliminates confusion, reduces process time by decreasing the time spent understanding the problem, and decreases the possibility of rework due to misunderstood context. 
  3. Reduce Costs. One license paid to one vendor generates economies of scale and minimizes costs related to using multiple licenses. It typically increases bargaining power with the vendor and decreases cost per seat. Additionally, maintenance and training costs both decrease. If an employee works in one system, compared to several, that translates to only one training session versus multiple sessions. Better yet, keeping the training budget the same and committing to several training sessions on one system will further increase people’s proficiency in that system, boosting their productivity and performance. Maintenance then becomes easier as the IT team only has one system to monitor and keep running. Similar to training, when you invest time into only one system, it encourages deeper learning within the team and drives results in better support of the system, further minimizing costs due to less downtime and incident recovery time.  

Not to mention, using one system as opposed to several brings additional benefits of improved communication and data insights. Understanding the workflow and developing patterns is much easier in one system than it is when work transfers through several systems. Furthermore, when teammates only have one system to check instead of several, they are more likely to communicate faster and better understand problems. 

Finally, a benefit not to overlook is the fact that employees like working within a single system. In our experience, employees enjoy seeing work flow through to different teams and appreciate the ease of using a single, connected, and integrated system. Furthermore, with one system to monitor, teammates have improved visibility of work coming up the pipeline and can follow the progression of the work they’ve completed. This leads to a better understanding of upcoming work, as well as a greater sense of accomplishment when they can see their work completed. 

In the last of this series on the topic, we will explore the ROI of ESM based on our experience with a client, demonstrating how implementing ESM best practices can save you money while improving your processes.  

Topics: process-improvement service-management cost-effective
2 min read

Praecipio Consulting's Incident Management Solution Is Live in Workato's Automation Marketplace

By Morgan Folsom on Jul 31, 2020 12:15:00 PM

2020 Blogposts_Praecipio is live in Workatos automation marketplace

Fun fact: At Workato's 2020 Partner Awards, Praecipio Consulting took home the Partner Award for IT Automations for the work that we did in collaboration with Workato and a leading animation studio to deliver an integrated Incident Management solution. The award recognizes our value in streamlining the incident management process through the integration of on-call tools, leading to improved resolution times and an enhanced experience for both the agent and customer.

And now, you can find this exact solution to in Workato's recently-launched Automation Marketplace, an online marketplace of best-in-class workflow automations across various business functions inside an enterprise. The Praecipio Consulting team created a solution around Incident Management using Workato and the Atlassian suite that seamlessly communicated to Jira Service Desk, Slack, AND PagerDuty. This recipe for success keeps agents focused on helping their users (rather than trying to figure out which tool has the most up-to-date information) and delivering an exceptional experience for the client's customers.

Head over to Workato's automation portal, where we outlined exactly how to implement this solution within your organization. And for more information about how we use Workato, check out our recent case study on Enterprise Service Management!

Topics: atlassian automation workato incident-management user-experience
1 min read

Is Going Agile Worth It? The Wall Street Journal Says So!

By Morgan Folsom on Jul 29, 2020 12:15:00 PM

2020 Blogposts_Is Agile Worth It- The Wall Street Journal Says So

Agile is one of the hottest trends in the business world right now - but is it actually worth it? (short answer: Yes!). The Wall Street Journal recently published an article that discussed the importance of cultivating an agile culture for enterprises who want to move forward with their business and survive the pandemic. Check out how our client, ACI Worldwide, has made impressive improvements in their process, pivoting to the Atlassian suite to manage their work across the board, in this Wall Street Journal spotlight. 

https://partners.wsj.com/atlassian/built-for-change/aci-worldwide-paying-agility-forward/

Not only did these changes help ACI Worldwide increase its enterprise agility, but it also successfully prepared their organization to quickly shift focus and resources during a constantly-mutating global pandemic. 

Give the article a read and let us know what you think!

Topics: scaled-agile enterprise service-management safe agile
4 min read

Enterprise Service Management Blog Series (Part 1): Why ESM Is Hardly A New Concept

By Praecipio Consulting on Jul 22, 2020 12:45:00 PM

2020 Blogposts_What is Enterprise Service Management

Michael Porter, a former Harvard professor, is one of the founding fathers of business strategy. He lent credence to the field by developing several ideas, frameworks, and theories around strategy that have been utilized, debated, and taught for four decades now. You may be familiar with his 5 Forces model, which is used to analyze the competitive landscape of a given industry, or his course titled “Competition and Strategy”, a requirement for all first-year Harvard MBAs. Though his ideas and theories are certainly not perfect and have evolved over the years, they laid the groundwork for modern businesses to think about their strategy, their position in the market, and their ability to move forward.

And when you think about it, it’s weird that some consider enterprise service management to be a new business process management trend. Let me explain. 

In 1985, Porter co-authored an article with Victor E. Millar in the Harvard Business Review titled “How Information Gives You Competitive Advantage”. In it, he laid out a central argument that said with the explosion of computer usage, companies would have access to a ton of information, flowing freely through the organization, that would allow managers to make more informed decisions faster. This, Porter argued, would fundamentally change how business was done and provide new ways for companies to stay ahead of their competitors. 

Consider this excerpt from Porter’s article:

“The value a company creates is measured by the amount that buyers are willing to pay for a product or service. A business is profitable if the value it creates exceeds the cost of performing the value activities. To gain competitive advantage over its rivals, a company must either perform these activities at a lower cost or perform them in a way that leads to differentiation and a premium price (more value).”

In other words, to gain an advantage over competitors, companies must perform their value activities at a lower cost or in a way that adds more value. Porter foresaw the drastic increase of information that would be available to businesses with the shepherding of the digital era. He logically concluded that such information, if used and communicated correctly, could be advantageous to managers looking to make decisions around the value-added activities in which their business engages.

The prediction of a sharp increase in the amount of information has certainly come true. In the era of big data, companies gather, store, process, and use more data than ever before. The problem is that typically this information is siloed, only about one particular subject, or only accessible and understandable to a few highly-skilled workers. This is the problem that enterprise service management will solve to bring Porter’s 35-year-old vision to fruition once and for all.

Enterprise service management (ESM) holds that the (mostly digital) processes that have been championed and used to gain efficiencies by IT teams for so long apply to the business as a whole, as seen by the adoption of similar processes and technologies in departments like HR, Facilities, and Procurement. ESM suggests that an organization should have a tool, which typically takes the form of a piece of software, that allows information to flow easily, quickly, and freely through the organization (sound familiar?). At Praecipio Consulting we have grown fond of referring to this as an operating system for business - one central piece of software that is used nearly ubiquitously in the organization, one that allows work to flow from division to division, team to team, teammate to teammate, with no loss of information and an attached, rich history.

Consider the typical lifecycle of the development of a new offering by a business - whether that be a software feature, physical product, or a new service offering. Marketing will research the market and determine where gains can be made. They will pass intel along to Product, which will develop these insights into a new product idea. The Product team will work with Development to create requirements, Dev will build it, QA will test it, and then it will be released to the market. Along the way, Marketing will generate buzz, Sales will sell, Legal will validate legality, HR will manage employees working on the offering, so on and so forth. In short - it takes a village, a coordinated effort among teams from different parts of the organization to deliver the new offering to market. 

The logic of a single system which transmits work in this lifecycle with no loss of info and rich history is apparent, as is the cost savings garnered from a single license paid to a single vendor, maintenance and training for one system instead of several, and usage of an efficient process unmarred by clunky handoffs to other systems.

To achieve this business process nirvana, we have long advocated for the usage of Atlassian’s Jira, Jira Service Desk, and Confluence products. Similar to Apple, Atlassian set out to develop products that work together seamlessly, but unlike Apple, Atlassian has retained that characteristic and further developed it to the point that these three products work together in harmony. The malleable and flexible nature of these products has helped them evolve from those used exclusively by software development teams for bug tracking to those used by IT, HR, Legal, Marketing, Customer Service, and several other business units. The ability of these products to merge these disparate units within a business shows an exciting step forward and potentially a culmination in Porter’s vision of a connected and integrated business.

In the next two articles that will form part of this ESM blog series, we will further explore the logic and numbers behind enterprise service management, and why and how it can help your company. 

 

Topics: service-management
2 min read

How Jira and Quickbooks Work Together To Streamline Financial Processes

By Ashley Halleck on Jul 15, 2020 12:49:41 PM

2020 Blogposts_Pros & Cons of WFH copy

Before I joined Praecipio Consulting, my background was in financial services, so I had never heard of the Atlassian suite of software before. My work-life consisted of strictly Excel, email, and a Bloomberg terminal. Needless to say, I was a bit confused during my first week as to how Atlassian’s software (in particular, Jira) would work with my new role in accounting. The more I learned about Atlassian’s software, the more I asked myself, “How does process management software geared towards developers apply to a financial controller?”

It’s safe to say that my early assumptions about Jira couldn’t have been more incorrect. I can seamlessly link every transaction to ongoing projects, open accounting issues, and everything under the sun that exists in Quickbooks (our system of record). I can’t tell you how much easier it is to simply reference a Jira ticket in a Quickbooks transaction instead of having to go through the arduous process of saving everything to Quickbooks. As a result, I am now as dependent on Jira as I am on Quickbooks!

How it works

Here at Praecipio Consulting, we created an Accounting project in Jira Service Desk, which is where we prioritize all invoicing and client correspondence. Once we create the ticket, it is assigned to the appropriate resource, and then all correspondence with the client or internal employees is attached to that issue, either through comments or cc'ing the ticket when sending an email. We use issue types like Accounting Submission, Generate Invoice, Billing Question, or Task. Each of these issues has unique fields and unique workflows that ensure it ties directly to an entry in Quickbooks and follows the necessary steps for entry.

In addition to using Jira Service Desk for invoicing and client correspondence, we integrated Salesforce and Jira to automatically create leads for licensing and projects alike. The workflows are specific to the opportunity type and auto-create the appropriate subtasks for accounting and sales. These issues are automatically assigned to the appropriate resource as you move each lead through its workflow. We reference each issue in Jira to the appropriate bill or invoice in Quickbooks, creating traceability for each opportunity. This integration ensures that we don't overlook any step in the process, from the closing of a sale to sending the final invoice.

Lastly, we use Tempo Budgets to perform billing closures on all of our projects. Budgets provides a perfect snapshot of the management of our planned vs. actual profit margin, revenue, and costs. This allows us to see which projects were over or under budget and ensures everything was billed accurately per each statement of work. 

 

To say the least, I do not know how I would do my job without Jira, Jira Service Desk, the Tempo suite of products. These tools aren't just solutions for developers; team members within any business unit can use them to improve their processes.

As we start the second half of the year, there is no better time than now to evaluate how you can automate tasks and streamline your accounting processes. Connecting Quickbooks to Jira could just be the solution that you never knew you needed!

Topics: jira accounting finance tips quickbooks