2 min read

Work Should Be Pulled, Not Pushed | Praecipio Consulting

By Morgan Folsom on Jul 29, 2021 1:08:14 PM

Blogpost-DisplayImage-July_Work Should Be Pulled, Not Pushed

Pushing work is generally considered to be the process by which someone will finish their work and then hand it off to a teammate, regardless of whether or not that teammate is ready for it. This type of behavior is commonly referred to as "Throwing something over the fence" - 

though it can also elicit comparisons to seagulls, pigeons, or other mischievous birds who come in, drop something unfavorable, then turn and fly away. The clear implication is that a person who pushes work typically does not pay attention to nor care what happens after it leaves their hands.

Pulling work, on the other hand, is generally considered the action by which someone will finish up what they are currently working on, then go out in search of the next work item. Typically, there is a known stack of work that person can pull from, ideally ranked by highest priority. The implication in this case is that the person has completed their current work (or is blocked) and has the bandwidth for new work.

Which work environment would you rather be a part of?

Ignore Salt-N-Pepa: don’t push it.

In our experience, teams that have built a culture of pulling work see two main benefits: a better working environment and more accurate metrics. As described above, a push-heavy culture can result in friction, frustration, or even animosity between teammates. Perhaps just as detrimental, a push-heavy environment can actually skew the data and give misleading insights.

When the culture transitions to becoming pull-heavy, the seagulls – and their unfavorable somethings – disappear! Teams are better able to manage their workloads, and the data become clearer and more useful.

A simple way to begin establishing a pull-heavy culture is to add neutral zones at the points of handoff in your process. These neutral zones represent areas where no team is adding value – rather, the item is finished with the previous part of the process and awaiting the next part. An example would be a “Ready for QA” column. When the development team is done with an item, they can move it to the Ready for QA column. QA can then manage their own workload and pull the work into their process when they have the bandwidth to do so.

This change is likely to generate new insights and improve the way your team is working. For instance, it should now be possible to determine when an item is actually being worked on as opposed to idly waiting for someone to pick it up. This can better inform managers how throughput can be increased. Additionally, it becomes easier to focus on high priority items, as lower priority work should remain in the neutral zones until the high priority work is completed. Having a team lead periodically prioritize work in the neutral zone will further improve the process as team members can simply select the first work item that meets their skillset.

Create a more autonomous and less frictional environment for your team: focus on pulling work through your process, not pushing it. 

If you're curious on transforming your team's culture and create the ideal environment to get work done, contact us, we'd love to help.

Topics: blog best-practices service-management culture agile
5 min read

Can We Talk for a Moment About Spreadsheets? | Praecipio Consulting

By Amanda Babb on Jul 27, 2021 11:14:14 AM

Blogpost-DisplayImage-July_Can We Talk for a Moment about Spreadsheets-

No, seriously: can we please take a moment to talk about spreadsheets? I have a very large bone to pick with them. Spreadsheet is a four-letter word to me; and don't get me started on workbooks! I recognize spreadsheets have their place in the world. I'm always in awe when I see the most complicated and fragile spreadsheet being used to manage a simple set of data to provide "insights" into the business. Even better, a spreadsheet that helps manage prioritization, planning, and execution reporting on a regular cadence. I've seen complex CountA and SumIf formulas, and Concatenate, and pivot tables, and everything else people can throw at them. And while I'm impressed at the craftsmanship, I'm also incredibly frustrated. The time it took to create and iterate on that reporting could have been spent having conversations about the work or checking in with a team or removing blockers. Instead, the extraction, manipulation, and reporting of easily-accessible, real-time data takes precedent. 

While it was published in 2014, I still reference an article when discussing data and reporting with our clients: This Weekly Meeting Took Up 300,000 Hours per Year. Yes, you read that right: 300,000 Hours. Per. Year! A single team extracting data, then aggregating it across several teams, then teams of teams, then programs, then everywhere else, all to be reviewed in a 30-minute executive meeting where the conversation was, "Are we on track? Yes? Great."  <sends weekly update deck to recycle bin>.

I hold no ill-will to the spreadsheet warriors out there. Instead, I view it as a simple case of "We've always done it this way." Well, what if I could show you a different way? What if, through the power of Atlassian, I could provide you real-time analytics? What if I could show you how to integrate Jira with a Business Intelligence solution? Or provide Program and Portfolio Management including planning and execution data in Advanced Roadmaps or Jira Align? How many hours would that save you or your organization when providing in-depth analytics to executive management? I promise you, this is all possible. 

Individual Team Metrics: Scrum and Kanban

Individual Team metrics are available for both Scrum and Kanban Teams under Reports in a Jira Software project. For Kanban Teams, both the Cumulative Flow Diagram and Control Chart provide flow metrics for the Team. While it may have been a while since you've taken a statistics class (if at all...I confess I tried hard to avoid them), spending ten minutes reviewing these reports will provide information on bottlenecks, flow trending, and backlog growth. Adding Quick Filters to your Kanban Boards will allow you to drill down into a specific subset of data on your board. Want to focus on Stories or Bugs only? Create the Quick Filters. 

Scrum Teams have nine (yes, NINE) reports available on their boards. Are you using the Burndown during your Daily Standup? Can you predict your release of an Epic or Version based on the throughput in those reports? Have you reviewed the Sprint Report to see what was added or didn't complete during the Sprint and asked why? The Scrum Reports will tell you what is happening during the Sprint (or happened, during the Retrospective), but it's up to you and the Team to ask why it happened. 

Need additional assistance to understand what these metrics are telling you? There's a training class for that. Praecipio Consulting is happy to help!

Program, Product, or Teams of Teams Metrics

Client: "Hey, Amanda, we're pretty good on the individual team stuff. Is there another way we can aggregate team data together?" 

Me: "How much time you got?" 

Three solutions come to mind for this one:

First, let's talk about Advanced Roadmaps for Jira. As always in the Atlassian tools, flexibility is key. When creating a Plan in Advanced Roadmaps, tying the work to the Teams by pulling in the scope of work is the first step. Whether it's a Board, a Project, or a Filter, aggregating data across multiple Teams, then tying the source to the execution team, provides you predictable velocity and capacity planning as well as execution reporting. 

  • You want Progress? You got issue count and story point or time-based progress.
  • You want to predict a milestone (read: release) date? You got milestone dates.
  • You want dependency maps? You got dependency maps.
  • You want to look at the Plan in a capacity view or a release view or a specific timeframe? You got custom views. 

Sharing all this information from Advanced Roadmaps in Confluence is amazing. While native in Confluence Cloud Premium, you can download and install the free app from the Atlassian Marketplace for Data Center. If you would prefer to simply share a link to the specific view of the Roadmap, that's available to you as well. 

Second, EazyBI. We constantly hear of clients looking for a more robust way to cube and concatenate data across their Jira instance. However, our clients tend to revert to what's comfortable: the spreadsheet. Instead, using an OLAP analysis and multi-dimensional calculations, EazyBI can provide the complex reporting when Jira's native Reports and Dashboards just won't do. EazyBI started as a purpose-built solution for Jira: it recognizes Jira's data structures and surfaces field data you may not be able to work with in native Jira. Since it's a unidirectional sync, EazyBI will not change your Jira data either. EazyBI can also integrate with other data sources including (sigh) a spreadsheet. 

Third, Jira Align. Here at Praecipio Consulting, we love Jira Align. The Program Room brings together all the information from multiple teams, i.e. an Agile Release Train. Every bit of data from Jira Software is aggregated to provide a clear understanding of the pace of the Train. The Program Board, the current implementation Roadmap with risk indicators, the investment data, the actual execution data, all of it is available in the highly-configurable Program Room. Burnups, Burndowns, progress by Epic, this is all available in Jira Align. In fact, there are over 180 reports available in Jira Align. And if that's not enough, Jira Align BI extends the already-robust reports into your existing visualization tools or your enterprise data lake. 

Enterprise Business Intelligence Integration

You may already have a Business Intelligence solution. Quite frequently at Praecipio Consulting, we hear our clients mention PowerBI, Tableau, or data lakes such as Hadoop or Snowflake. These powerful solutions are likely already embedded in your organization. And there's probably a SME out there just waiting to assist. Enterprise organizations usually have an integrations team to help connect Jira and other data sources. In fact, we worked with a large organization to consolidate Jira instances to better connect data to their business intelligence platform. In just 12 short weeks, they were able to analyze and report on their current execution progress simply by being able to feed consolidated Jira data into their business intelligence platform. 

At Praecipio Consulting, we have extensive integrations experience across a wide-range of technologies. We can recommend Atlassian Marketplace apps as a fit-for-purpose solution or we can work with third-party integration engines to help you map data for enhanced metrics. 

Take a moment to step back and really examine your use of spreadsheets. While, again, they have a purpose in this world, to a hammer, everything looks like a nail. The spreadsheet is dead. Long live the spreadsheet. 

Topics: atlassian blog best-practices kanban scrum reporting support-live-music eazyBi jira-align advanced-roadmap business-intelligence
3 min read

Trello 101: An Introduction | Praecipio Consulting

By Luis Machado on Jul 23, 2021 12:21:13 PM

Blogpost-DisplayImage-July_Trello 101 - An introduction

Welcome to Trello 101! In this post, we'll be talking about the basic functionality Trello has to offer that can get you up and running quickly and start managing work for you and your team. We will explore the basic features of Trello and define some of the terminology used. To help illustrate some of these points I've created a template board you can copy over to get started and use to follow along with.

What is Trello?

Trello is an online application used for managing work. It allows for quick and easy team collaboration and empowers you with various methods of customization to tailor your workflow to meet any requirements. Think of it as a glorified digital white board with sticky notes you can use to record and track progress of different tasks! Either with a team or by yourself, Trello offers a way to turn your task list into a visual representation that you can interact with. The level of use ranges from simple beginners to complex power users, with automation and integrations built in. So without further ado, let's take a look at what makes up a board.

Boards

The first thing we need to do is establish what a board is. The board is essentially the personalized site that all of your information lives on: it's where all the organization happens, where you'll setup your workflow, create task items, invite team members for collaboration etc. Boards can be project or team specific, you can create a board for anything, you could even run a D&D campaign off of it. The sky's the limit.

Within the board on the right-hand of the screen lives your board menu. This is where you can manage your team members on the board in terms of their permissions, filter you view through the card search, utilize power-ups or setup any automations.

Trello 101 - An introduction-boards

Lists

Lists are essentially going to represent your workflow. In the example template, the vertical columns are your lists and represent the various stages that your work progresses through. This is the most typical use, but lists can also be used for establishing context on the board. The 'General Information' list houses the instructions for how the board can be used.

Trello 101 - An introduction-lists

Cards

Within the lists we have cards. Cards are the items of work that are to be performed or tracked through the workflow. Whenever you have a new task to track, you can create a card for it with a header and a description, and drag and drop it through the various lists as work progresses. In the template board I've created a few example cards to show the various functionality.

Trello 101 - An introduction-cards

Labels

Labels are a way to group tasks together. In the example of a software development project, you could have labels to represent the different elements like UI/UX, Localization, Codebase etc. In a team management setting you can have different labels for the different groups, you could also use labels to identify priority. They're customizable enough to serve whatever purpose you have for them. In the example board we are using them to identify priority of tasks. You can apply a label to a card by selecting the card and clicking on the 'labels' option in the right side menu.

Trello 101 - An introduction-labels

Adding Team members

Once your board is complete and you're ready to start working, you can invite team members to join your board by clicking on the 'invite' button in the top-middle of the board and adding their email address, or by creating an invite link to allow anyone with the link to join.

Trello 101 - An introduction-members

And that's it! You're ready to rock and roll. I encourage you to use the basic template to get started with to get a feel for how the site works. Once you're comfortable enough with it you can start to branch out into using power ups and automations. 

If you have any question on Trello, or any other Atlassian product, reach out and one of our experts will gladly help!

Topics: blog best-practices tips trello atlassian-products
2 min read

Agile 101: What is a Spike? | Praecipio Consulting

By Morgan Folsom on Jul 20, 2021 11:59:24 AM

Blogpost-DisplayImage-July_What is a spike-

A Spike, in Agile software development, is a work item to support future work by the team that can't be performed without more research, design, or prototyping. Creating a spike allows you to dedicate time in a sprint to finding out more information in a defined time-box.

The benefit of using a Spike is that if the work turns out to be either more or less effort than you expected, it won't throw off the team's ability to get all of their committed work completed. No one wants to find out mid-sprint that a story is much more work than you thought because you didn't really know what it required yet. When running Scrum and trying to manage velocity, sometimes you need to build in room for uncertainty. It may be that there's a piece of work that needs to be completed, but we're not really sure how much work that's going to take. In these cases, using Spikes can be a huge help. 

How do I use Spikes?

  1. Create a ticket to represent a spike in your backlog
  2. Include the Spike in your sprint – Estimate the spike to determine how much effort should be dedicated to completing the spike
  3. Complete the necessary exploration or design during the Sprint to determine the estimate for the original story
  4. Close out the spike and update the original story with the new estimate

Using spikes in your sprints can make your teams more reliable – you've got a better idea of what's going on, with less pressure to know everything up-front.

Looking for more Agile 101? Check out Project Estimation - Story Points vs. Hours Estimation or Why Jira Won't Make You Agile.

And if you have any questions on Agile, contact us, one of our experts would love to talk with you and see if it's a good fit for your organization.

Topics: blog scrum tips agile
2 min read

Are Retrospectives Useful for Non-Scrum Teams? | Praecipio Consulting

By Rebecca Schwartz on Jul 15, 2021 11:34:08 AM

Blogpost-DisplayImage-July_Are retrospectives useful for non-Scrum teams-

If you work in tech, you've most likely heard of the term "Agile". Agile is a framework typically used by software and project management teams to deliver better quality work to customers in a more timely manner. Depending on the way organizations approach their journey to becoming Agile, there are various methods they can use to get there. One of the most popular Agile frameworks is Scrum, which proposes teams lean on time-boxed iterations, called Sprints, to complete their work. At the end of each Sprint, Retrospectives are to be completed. Retrospectives are meetings where Scrum teams discuss how to improve the way they work; they are typically held every 1 or 2 Sprints. They give the team a chance to come together and discuss what they liked, what they disliked, or what they felt could've gone better during the Sprint.  Many teams neglect to complete this step, even though it is one of the most important items teams can leverage if they're aiming to truly be Agile. Thinking about Retrospectives and their benefits made me realize how useful they can be for all teams, not just Scrum teams. 

Retrospectives and Non-Scrum Teams

Retrospectives are great for non-scrum teams in that they push teams to look back and reflect on the work they've completed. This reflection is key for future work, as teams can avoid past mistakes or time-eating efforts that negatively affected the efficiency of their last project. They can do the same for the items that lead to success in their previous projects so the team can consistently deliver their best work efficiently.

Additionally, retrospectives are great for promoting team unity and trust across the team members. When team members can openly share their honest opinions about how the team is doing, team communication improves, leading to better quality work and better relationships between team members. Any team can benefit from this, no matter how the team goes about completing their work.

Consistent reflection and analysis of completed work are excellent tools, even if the team isn't using Sprints and your work isn't necessarily time-boxed. At Praecipio Consulting, we hold retrospectives after the completion of every engagement. Looking back on the wins and losses, I can't help but feel a sense of pride amongst my team members on the work we delivered. Setting aside this time for the team to come together and communicate with one another allows our delivery teams to grow and bond with one another. Not to mention, the work we produce increases in quality and the processes behind that work become more efficient. 

If you are curious about Agile, and would like to see if it's a good fit for your organization's needs, contact us and one of our experts will get in touch.

Topics: blog scrum tips agile
5 min read

Which Atlasssian Products are Right for my Business?

By Michael Lyons on Jul 13, 2021 9:55:57 AM

Blogpost-DisplayImage-July_Atlassian- Which Application is Right for my Business

Are you considering using the Atlassian toolset, but aren't sure which applications are best for your team or organization? Well I'm here to highlight some of the great applications that Atlassian provides so you can make the right choice for your business. Atlassian's product suite is made up of applications that can unlock your entire organization's potential, from Software Development teams, IT Operations teams and Project Management teams to HR, Legal and Product Owners. You can even use the tools for everyday life! We at Praecipio Consulting love these tools so much that we use them in our day-to-day work.

I will be focusing on a subset of applications that can be used as a starting point for your organization. The applications are great foundational building blocks to start with when using Atlassian for managing work, providing service experiences, or housing documentation. These applications can be used on their own, or they can be used together to maximize team collaboration and efficiency, depending on what suits your team or organization best. 

Jira Software

Teams and organizations can use Jira Software as a tool for managing and tracking work in software development projects. This tool is extremely flexible and can be used by teams that leverage both Agile and Waterfall methodologies. It is highly customizable and can track all sorts of work in the software development lifecycle, including initiatives, epics, stories, and tasks, as well as other items specific to the team. Teams can create customized workflows to track statuses for work items to ensure work is being completed properly and the right individuals are involved to support the work. 

Groups that leverage both Scrum and Kanban can equally benefit from Jira Software. Scrum teams can set work for sprints and track the sprint progress directly in Jira. Visual tools such as boards, dashboards, reports and plans can be used to monitor and execute work. For Kanban teams, Jira's board visual is great for seeing the tasks the team is working on and can help determine where the team needs to focus. WIP (work-in-progress) limits can be set depending on what the team can achieve. 

Software, Gaming, Finance, and so many other types of companies find this tool useful to develop new technology. For example, the development of an App across multiple platforms is an excellent case for leveraging Jira Software. Product Owners can help drive improvements of their Apps with enhanced transparency, reporting, and collaboration through Jira Software. 

Jira Service Management

Teams that provide any level of customer service such as enhancement requests, PTO submissions, or change management often look to Jira Service Management as their main tool. Service desks are useful for taking on requests from both internal and external customers. Requests can be assigned and tracked in the application to ensure customers are getting all the help they need. Companies will also use this application to track changes through the business, such as bug fixes or upgrades. As with Jira Software, Jira Service Management can be customized to fit what the organization needs to ensure great service is being provided.

Organizations use this tool for IT Help Desks. If an employee needs a new laptop or to have a password changed, a request can be submitted through a customized service desk. The requests are sent to teams designated by the organization and can be resolved by those teams. Jira Service Management can be used by other groups within the organization as well, such as Human Resources. As described in one of our previous blogs, HR Teams can leverage service desks to onboard new employees. 

Jira Service Management is used for many different types of requests here at Praecipio Consulting as well. For example, our Marketing Team manages a service desk for Webinars. If someone has a topic to present, the service desk can be used to submit the idea. Once the idea is received, our Marketing team will work with the individual to plan and schedule the Webinar. 

Jira Work Management

Jira Work Management functions similarly to Jira Software, but is geared towards teams that are managing non-software development projects. Project Managers across multiple industries can use this tool to assign and track project work. Similarly to Jira Software, Work Management is customizable and provides great visualizations to monitor work and ensure projects are being completed on time. 

This tool doesn't just have to be used for company-related work: it can be used outside of work as well. For example, searching for a new house! The house buying process is extensive, and Jira Work Management can help outline tasks, assign work, and set dates and dependencies so you can purchase your next home in an organized manner.

Confluence

Confluence is a robust content management tool that teams can use to house important project materials, knowledge resources, and document templates. Within Confluence, spaces can be created for organizations and teams to organize documentation. Then pages can be created within the space where teams collaborate and share notes and documents on work being completed. This application can work for any sort of organization in any field, not just for technology groups. 

This application can be used to document daily meeting notes, standard best practices for an organization, and much more. Confluence can incorporate helpful macros to enhance the information being shared. For example, macros include drawing features for diagrams and templates for consistency across documentation. This application enables all of your teams and stakeholders to communicate effectively about projects.

How Can Applications Be Used Together?

I've discussed a small group of the tools that Atlassian offers. These applications can be used on their own, and you may feel the need to only use one. However, if multiple applications fit your needs, you can use them together to achieve operational excellence.  A common case is leveraging confluence and combining it with other Atlassian applications. Confluence, being a great documentation tool, combines extremely well with the applications discussed. Below you will see these combinations and effective use cases for each.

Confluence and Jira Software:  Confluence can be used to document daily notes for scrum meetings and create templates for how retrospective meetings should be organized. It can also be used to store any internal team notes on work being completed.

Confluence and Jira Service Management: Confluence can hold documentation on how to resolve a specific issue pertaining to the business.

Confluence and Jira Work Management: Confluence can be used to document discovery sessions about the project or even store your robust project plans. Drawings can be added to confluence as well for reference. 

The immense synergy between Confluence and all of these applications can help maximize the benefits of your Atlassian applications!  If you have questions about any Atlassian applications, please reach out to us, we would love to help! Best of luck in your Atlassian journey!

Topics: jira blog confluence jira-service-desk jira-software atlassian-products jira-work-management
3 min read

Insight, Atlassian's Digital Asset Management Tool | Praecipio Consulting

By Kye Hittle on Jul 7, 2021 10:06:50 AM

Blogpost-DisplayImage-July_Digital Asset Management Tools for Your Company

Previously, we looked at why digital asset management is important for your organization. Today, we're exploring Atlassian's solution for tracking your organization's valuable assets digitally: Insight. Remember, we are defining assets as anything that helps you get work done: lab equipment, computer hardware, cloud infrastructure, mobile devices, software/SaaS licenses, tools, work stations, furniture, etc.

In our industry, digital asset management is usually thought of as a component of "service management." Service management was traditionally considered an IT function (often manifested in the form of an IT help desk). In recent years, however, we have been implementing these practices across the organization—from legal to human resources to finance—because they dramatically increase the speed and quality of how work flows.

This expansion of service management practices beyond the IT organization means more teams are taking advantage of Atlassian's asset management tool, Insight. The impact of this trend is often quite remarkable as processes are formalized, streamlined, and consistently monitored. Teams using Insight get additional process benefits. Unlike inflexible, legacy Configuration Management Databases (CMDBs), Insight uses an open data structure which allows your teams to manage any resource important to their service requests. Including assets in your service management practices is a big step forward.

Think about how work gets done in any part of your organization: your process workflows. It typically starts with the (internal or external) customer submitting a service request, like a new employee onboarding, a facility request, a contract review, etc... The request is picked up from the queue by an agent who will take actions to move the work forward to resolution. Many actions may be needed along the way: obtaining additional information, forwarding to another team, making a configuration change, creating an account, procuring a requested item, repair equipment, provide updates back to the requester, etc. These actions are all turbo-charged and made easier through Jira's functionality and built-in fields. But is there something missing? Yes, assets! Almost every request involves procuring, repairing, replacing, upgrading, decommissioning, or dealing with assets in some way. A Jira issue, by default, doesn't include fields to track data related to assets.

We could employ custom fields to create a drop-down list of assets, but we quickly run into limits with this approach. As discussed in the former post, assets usually have many attributes, such as serial numbers, vendor/service contacts, documentation, relationships to other assets, etc... There's no way to stuff all of this information into a custom field. Using multiple custom fields is cumbersome for agents and for reporting/tracking due to data entry accuracy issues. In addition, we can't establish relationships between assets represented in custom fields; these are important for being able to see all assets located in a certain location or seeing what other assets will be impacted by removing or changing an asset, for example. We need an integrated solution that's tailored to managing our assets within Jira tickets.

Insight-company-assets

Insight's basic functionality allows customers and agents to link an issue to a complete, dynamic asset record. This is incredibly powerful by itself, but that's not all: with asset management handled by Insight, we can do so much more to help work flow smoothly as part of digital transformation initiatives. Insight can automate ticket assignment based on any asset attribute, like location, model, or vendor. This prevents front-line support from spending time reassigning tickets to the appropriate queue and removes that wait from the request's resolution time. Alerts to stakeholders can be sent automatically. Should safety and engineering teams be alerted when tickets involving security systems, networking hardware or other critical infrastructure are opened? Automated discovery can be a crucial feature for audit/compliance and having an accurate picture of what assets are being used to in your business. We are amazed at the flexibility of Insight to help customers manage all of their needs around assets.

Are your assets managing you instead of the other way around? If so, get in touch, and let's apply the power of Insight to your business.

Topics: jira blog asset-management service-management insight digital-transformation
5 min read

Pros and Cons of a Cloud Migration | Praecipio Consulting

By Luis Machado on Jul 5, 2021 12:23:50 PM

Blogpost-DisplayImage-July_The Pros and Cons of a Cloud MigrationThinking a move to cloud might be the way to go for your company, but you're not exactly sure if such a move is right for you? There are a few questions you should ask yourself about your organization to understand the context of what a migration to cloud would mean for you.  As you're navigating the pros and cons associated with migrating from on-prem solution to cloud, you have to understand that how these factors are weighed largely depend on the context of your organization. Asking the following questions will help you establish that context:

Why move to cloud?

For context, the term 'Cloud' can be somewhat ambiguous, so if not otherwise stated I'm referring to cloud in the SaaS sense (Software as a Service), that is, maintained by a 3rd party and available in a cloud setting, such as the Atlassian product suite. There are other flavors of cloud out there, but the SaaS model is where we'll maintain our focus. The first question you want to answer is why? Why are you considering moving to cloud in the first place? Are there any specific pain points you are feeling in your current setup that you think might be alleviated by moving to cloud? Understanding what your potential need is for a cloud migration will help you to develop a business justification for the endeavor, as well as allow you to start to build the context of your specific situation. If the reason is "We're spending too much time on maintaining infrastructure for our on-prem solutions" then something like having no maintenance in a cloud environment would be weighed very heavily in your case.

What are you moving?

What are you going to be moving?  What does your current on-prem setup look like? How big is your userbase? What 3rd party add ons or apps are you using? Are you using a single instance and are wanting to consolidate in addition to migrating to cloud?  How much historical data do you have? These questions can help to establish the potential complexity of the migration you're looking to perform.  One of the major considerations that has to be factored into a cloud migration is the cost of entry. This extends from just the literal monetary cost to include time and human resources as well. If your company can't afford to divert labor to perform a migration, is it worth it for you to contract the project out to a 3rd party? Having an idea of what you are migrating will help you weigh the various options and give you perspective to consider the impact.

Pros

Now that you've established the context for you migration, let's take a moment to talk about the potential pros around migrating to cloud.  When comparing cloud to an on-prem solution, you can really break down the pros into four main points:

  • Accessibility
  • Scalability
  • Maintenance
  • Cost

Let's take a look at the first point, Accessibility. One of the great things about cloud is that it's accessible from almost anywhere in the world right out of the box. You don't have to configure any VPNs or allow lists, no special permissions groups to modify, all the data replication and content delivery is managed for you, and has a low cost to entry.

Scalability is another major pro in favor of a move to cloud and falls along similar lines as Accessibility, and typically goes hand in hand with Maintenance. The infrastructure behind the application or service is purpose-built on a platform intended to be scalable in order to support multiple customers.

Add to this the fact that you no longer have to be responsible for maintaining that infrastructure, you can focus efforts and resources elsewhere in your organization. If maintaining infrastructure is something in particular your business struggles with, making a shift to cloud can have a huge positive impact.

This leads us nicely into the topic of cost.  Depending on the specific context, cost can sometimes go either way: I'm including it in the pros section because I think in most cases, especially if you factor in for the long term, your costs overall will be lower with a move to cloud. Figuring costs in a cloud move takes some doing because there can be differences in the types of costs you'll encounter in a cloud setting vs. an on-prem. Again, because this can be pretty heavily dependent on the context of the specific situation being analyzed, I'll throw out a few common factors but I don't want to give any potentially wrong impressions. Cloud vs on prem costs infographic

In the table above I've done quick breakdown to illustrate the basic differences around Cloud and On-Prem, and I've added another column to include the option of moving to cloud as SaaS model vs self-hosted cloud. Cloud hosted and On-Prem hosted have some similar costs categories (licensing, infrastructure) but there is some reprieve you get from cloud specifically around the depreciation of hardware and maintaining the infrastructure. In a cloud model this is mostly tied to licensing and the monthly cost operating fees associated with the virtual hardware you have allocated for your purposes. Versus the more traditional model of maintaining physical servers, the personnel costs associated with that upkeep, and the cost you incur with depreciation. In a SaaS model this all mostly wrapped into the licensing cost, which is typically why licensing for cloud is both more expensive and more complex. 

Cons

There are of some potential tradeoffs and downsides to consider as part of a move to the cloud. The biggest areas that might cause you or your organization trouble include Control, Security, and Flexibility.

When you break it down, the concepts of control and security almost go hand-in-hand.  Control is probably the hardest thing to overcome when talking about moving your data to the cloud and understandably so. The bottom line of operating in cloud environment is your data lives somewhere outside of your organization and the infrastructure is managed by another entity. You're putting your data and your trust into someone else's hands. While this is not necessarily a bad thing, it can take some getting used to, and some adjusting of your internal methods or practices. Being familiar with the support process can help with this as know what information you can request and how to get it will help to alleviate some of the disjointed feeling when attempting to manage your application.

On the security front, if your company has very specific security requirements or has specific regulatory bodies you have to comply with, there is an extra layer of consideration when weighing the prospect of moving to cloud. It's important to first identify what those needs are and reach out to the cloud provider ahead of time to find out if those requirements can be accommodated.

Lastly it's important to consider that moving to a cloud application means you will not have access to anything beyond the application layer. This can mean workarounds previously in use with the on-prem solution may need to be re-considered or re-engineered, and there are potentially additional restrictions around API calls and traffic to/from the application. Spending some time discovering what your needs are vs what is available to you in a cloud setting will be key to realizing these potential pitfalls.

We are getting to a point where we're moving from "Is cloud the right choice?" to "Which form of cloud is the right choice?" Not all situations involving cloud are the same, and careful consideration and weighing of options is important for any potential move.  Having the right tools to plan and execute the transition as well as an understanding of the context of your environment can make all the difference when deciding how to move forward.

If you have any questions on migrating to cloud, have run into trouble implementing a migration, or simply want to see if your organization is making the most of its digital infrastructure and operations, contact us and one of our experts will reach out to you.

Topics: blog saas cloud digital-transformation cloud migration
3 min read

What is Jira Align: A Primer | Praecipio Consulting

By Amanda Babb on Jun 30, 2021 4:45:59 PM

Blogpost-DisplayImage-June_What is Jira Align- A PrimerA couple of years ago, in Atlassian's annual flagship event formerly known as Summit and now known as Team, I was in a room full of people for two days providing training on Advanced Roadmaps for Jira on behalf of Atlassian. If you've never attended a live Summit event, the Kickoff Keynote is always a sight to see. One year, Scott and Mike dressed as Daft Punk and mixed music as DJ Kanban (I still nerd out on that one), you see announcements about the expansion of Pledge 1%, and, of course, new product announcements. Jira Align was acquired by Atlassian and announced at Summit 2019. I. Was. Floored. You see, we here at Praecipio Consulting were looking for a larger agile-at-scale solution for some of our largest clients. 

Enter Jira Align

After becoming a SAFe® Program Consultant (SPC) in 2015, I spent a lot of time with clients understanding intake and execution processes and facilitating them through the Atlassian product suite. These clients were either just starting their SAFe® journey or had been the earliest adopters and already implementing SAFe®. After implementing Advanced Roadmaps (then known as Portfolio for Jira) to support SAFe®, becoming the Atlassian University On Demand "voice" of Planning with Advanced Roadmaps, and guiding the course content with Atlassian, I was in love with Advanced Roadmaps. And I still am. Advanced Roadmaps is a powerful data aggregation, roadmap, and scenario planning tool for small- to medium-size organizations either as standalone entities or within an Enterprise organization.

Jira Align, however, brought forth a whole new realm of possibilities. Bringing robust framework expertise and combining it with an easy-to-use interface, Jira Align is THE solution for Enterprise organizations running agile-at-scale. Don't believe me? Atlassian is considered a Leader in the Gartner Enterprise Agile Planning Tools Magic Quadrant as of April 2021. Experience and third-party accolades aside, why is Jira Align so amazing? Let's take a closer look. 

Jira Software Integration

Unlike Advanced Roadmaps, Jira Align is a standalone product hosted either in multi-tenant or single-tenant cloud infrastructure. While there is an on-prem solution, of course, there are a lot of additional considerations if you have to choose this deployment. The connection between Jira Align and Jira Software supports both Data Center and Atlassian Cloud instances. The most critical part of the integration is the Jira Software Epic. Epics can be created in Jira Align and pushed to Jira Software or created in Jira Software and pulled into Jira Align. Keep in mind, when creating the integration, best practice is to isolate Epics into their own Jira project. Bringing in Stories and Sprints is also easier if a Jira project represents a single team. 

Rooms at Every Level

Whether you're just starting out with a single Agile Release Train (ART) or are running multiple ARTs, Jira Align provides the Program Room for each ART. This is the central hub for tracking the current Program Increment (PI) and planning the next one. Sprint Progress, investment runway, intra-ART and inter-ART dependencies, PI Burndown, it's all centralized within the Program Room. This provides Business Owners, RTEs, and Program Managers a clear view of the progress of the work in the PI. 

Jira Align also provides the Portfolio Room and Strategy Room. These rooms provide the progress towards Strategic Themes, Portfolio investments, progress toward long-term goals, and status updates. When properly connected to Epics in the Program room, Teams and ARTs can open the "Why?" tab on the Epic and see how their work is contributing to the overall strategy. 

Everyone's Favorite: Reporting

Jira Align has over 180 out-of-the-box reports. Each layer in Jira Align has a Track section pre-populated with the more popular reports for that section. For example, in the Program section, Jira Align provides Program Increment tracking, Program Increment insights, and Dependency Maps. If you're not sure what type of report you're looking for, simply click the Reports menu and ask a question in the search box. 

For those organizations that need to integrate with other systems or need more robust business intelligence, Enterprise Insights can be added to Jira Align. 

Want to know more? We here at Praecipio Consulting would love to walk you through how Jira Align can support your agile-at-scale transformation. Contact us!

Topics: atlassian blog scaled-agile integration reporting jira-align safe advanced-roadmap
3 min read

4 Things to Look Out for When Migrating to Atlassian Cloud | Praecipio Consulting

By Jerry Bolden on Jun 28, 2021 3:17:41 PM

Blogpost-DisplayImage-June_Challenges moving from server to cloud (# things to look out for)Migrating to cloud can be a challenging move for any organization: there are many moving pieces to keep track of, and with the threat of negatively affecting both internal and front-facing operations, failure is not an option! Here are some key blockers to keep in mind when migrating to Atlassian Cloud from on premise instances, so that you can review ahead of time just how prepared for a successful migration your company is:

  • User Management
  • Automations
  • Size of Attachments
  • Apps

User Management

User Management and how users are set up is a major difference when operating in Atlassian Cloud versus on premise. This is an important obstacle to understand and address, as the approaches for user management are different between cloud and on-premise. Key to this is how users are created and managed; equally important is identifying any users with missing or duplicate email addresses, since these cause problems with data integrity and users being able to use Filters and Queues in Atlassian Cloud. 

Automation

Automations are critical to research, as some automations may not be functional or even allowed in Atlassian Cloud: these will need to be identified and assessed to determine the balance between the value they bring and the level of effort of recreating them. 

Attachments

Size of Attachments becomes critical when using the Jira Cloud Migration Assistant, as this does not support migrating Jira Service Desk projects, which may require importing data via Site Import that forces attachments to be uploaded separately in 5 GB chunks, one chunk at a time. This alone will drive the migration of attachments to exceed a typical outage window, as the Site Import process must first conclude prior to uploading attachments. 

Jira Service Management utilization is tied to the size of the attachments as noted above. While JSM is used heavily it is currently not able to be migrated using the Jira Cloud Migration tool. With that being said this drives the use of site import. With this comes having to migrate the users and attachments separately. This becomes more moving parts during the migration outage and the coordination and timing will become even more critical.  

Apps

Jira Suite Utilities (JSU) / Jira Miscellaneous Workflow Extension (JMWE) / Scriptrunner are apps available in the Atlassian Marketplace that may be used in one or more of your current workflows. While these apps have helped to drive the creation of workflows and processes to automate certain transitions or enforce proper data collection, there is also no current migration pathway to Atlassian Cloud. While JSU has become part of the native cloud, JSU along with the other two apps must be manually fixed in all workflows migrated up to the cloud. You must run a query on your on premise data base to ensure you map out all transitions affected by the apps. Then once the migration to cloud is complete, they must be reviewed and recreated manually to ensure they are all working properly. Where possible utilizing the out of the box options, that mimic JSU, can help to move away from at least one app. 

Specific to Scriptrunner, one common scenario is the use of it in filters can cause them to no longer function, potentially causing boards and dashboard to render incorrectly. These filters must be rewritten using the Scriptrunner Enhanced Search functionality. One good example is any filter that contains the phrase "issueFunction not in" will need be rewritten as "NOT issueFunction in". It would be advisable, when doing the migration to Cloud, to open a ticket with the vendors for advise on how to fix scenarios with JQL that worked in Server/Data Center that no longer work "as-is" in Cloud.

Overall these key obstacles will get you on the correct path to understanding what you know will need to be done in preparation for starting the migration. This by no means is a complete list of the only obstacles that you can encounter, but we hope it will help you to be proactive in fixing obstacles before they become a blocker to the migration.

We are Atlassian experts, and understand how the move to cloud can be fraught with unpleasant surprises. If you have any questions, or are in need of professional assistance, contact us, we would love to help!

Topics: atlassian blog automation best-practices migrations atlassian-cloud marketplace-apps jira-service-management cloud migration
6 min read

Confluence, by Atlassian: Understanding the Software | Praecipio Consulting

By Kye Hittle on Jun 23, 2021 4:42:15 PM

Blogpost-DisplayImage-June_Confluence Atlassian- Understanding the Software

If you've ever asked the question, "What is Atlassian Confluence?" you might have received one or more of the following common answers:

  • "It's a wiki."
  • "It's a knowledge base."
  • "It's an enterprise-friendly collaboration workspace."

And although these answers may be accurate, they aren't that illuminating if you're not already familiar with terms like "wiki" or "knowledge base." Confluence is meant to be used by everyone in your organization; every additional contributor increases the value of your instance. On your Confluence journey, it's important jargon doesn't intimidate users before they even get started! They are much more likely to jump in if you use simple, clear language and explanations.

As always, we're here to help! Let's look at each of these common methods of explaining Confluence and some alternate approaches.

What's a wiki?

Since most users are familiar with Wikipedia, Confluence champions may assume the first answer above ("it's a wiki") is a good way to employ the time-honored tactic of starting with something users already know. However, while most users have read a Wikipedia article, there is very little chance they've actually written or edited content on the site. This is where the analogy doesn't take us as far as needed for new Confluence users.

For most users, Wikipedia is just another read-only page on the web. Even if aware Wikipedia is user-editable, they almost certainly don't have the experience of easily creating and editing wiki pages and then having the content immediately available to other users. It's powerful, but hard to really "get it" if you haven't actually done it before.

This concept is critically important in understanding Confluence's value:

You can create and edit content that's immediately available to your team, or even our entire organization on Confluence. It's as easy as editing a document in a word processor but more powerful because you don't have to worry about how others will access the new content.

What's a knowledge base?

Next up in common ways to explain Confluence: the term "knowledge base."

This is even more unfamiliar to most users outside of IT. We may be able to better meet users where they are by using the phrase Frequently Asked Questions, aka the infamous "FAQ." Thanks to it's popularization as a go-to spot for answers on many websites, this might be a better entry point to explaining the value of Confluence as the central repository for an organization's knowledge.

We're all familiar with the struggle to find answers in our organizations. Our clients have tackled this challenge by centralizing their knowledge in Confluence. Users need to know:

Confluence is the single place where we store our FAQs. When you have a question, it should always be your first stop. Since you generate new organizational knowledge each day, help teammates (and yourself!) by storing answers, historical information, and future useful content in Confluence!

What's a workspace?

The problem with the term "workspace" is overuse. We hear it used to describe project management systems, collaborative editing in documents, physical locations (e.g. desks, lab tables, kitchens, classrooms), the main area of an application where content is manipulated, and even online portals. And that's just the beginning of things that get called "workspace."

We need something more precise when describing Confluence. Sometimes it's better to use an example to illustrate the value of Confluence instead of abstract jargon. Quickly explain how you or one of your teams have used Confluence. The more germane it is to users's daily responsibilities, the better. In other words, avoid using a software dev team's use case when talking to the accounting department. While Confluence can enable very complex use cases, stash those for advanced users. With new users, make it approachable and the value immediately obvious.

Drinking our own champagne

Recently at work I joined a three-person ad hoc team to reach out to attendees at Atlassian Community Events about career opportunities here at Praecipio Consulting. We started with a single Confluence page and simply attached one Keynote file as the starting point for our presentation. That's it. It took our team lead 15 seconds to create our team's "workspace."

During a subsequent remote meeting using collaborative editing we added sections to our page for talking points, an email template to event leaders, a table for tracking progress, and a Team Calendar to prevent schedule conflicts. All of us updated the document simultaneously. Additional meetings generated additional content sections, sub-pages (e.g. lessons learned), and more.

Because this was a one-time effort, a full project-management system or "plan to plan" would've taken longer than our actual project. But not having Confluence would've made it much harder to stay organized and make quick progress. Confluence is flexible and grew with us as our project evolved. Confluence also stores every edit as a previous version which can be referenced if the change information is ever useful (e.g. when did we reach out to a particular city last?). Since it was so successful, we'll likely repeat this effort in the future. Our work is stored in Confluence for when that day arrives. The wheel will not need to be reinvented, even though Confluence made that first round very efficient and effective.

That simple, thirty-second example of a one-page project "workspace" demonstrates several components that make Confluence so powerful:

  • Quick ramp-up and flexible for any kind of work
  • Evolves and grows with your team as needs change
  • Real-time collaborative editing allows everyone to stay on the same page, even in remote meetings
  • Add-ons and features, like Team Calendars, add deeper, dynamic functionality
  • Confluence automatically versions edits, allowing us to go back in time if needed

The Journey to Confluence Success

Making Confluence approachable for new users is a critical first step in successful Confluence adoption, but it's not the only one. Here are some other resources to ensure your success.

Professional Services

Confluence is easy to get started with, as long as users aren't intimidated by jargon. It's also easy for it to grow out of control without some guardrails in place. To prevent your Confluence from becoming an overgrown forest - and to make it easy, especially for your newer users - a good design for space organization, permissions, add-ons, and more will save you lots of pain. Praecipio Consulting engagements range from accelerators to get up-and-running on common Confluence use cases to custom-designed engagements tailored to your organization's specific requirements. Let's discuss what would work best for your situation.

Training

Atlassian documentation is great but most users don't read it. We offer instructor-led training to make sure your users get the practical how-to knowledge they need to be effective with Confluence from day one. Contact us for more details.

Atlassian University

For learning the basics of Confluence, you can always direct users to Atlassian University which offers on-demand online courses.

Atlassian Community

Finally, Atlassian has a thriving user community which meets online and in-person every day. Check the forums to see if your questions have already been answered or, if not, post it.

Confluence can dramatically streamline knowledge and project management. It can become one of your users' favorite tools for getting work done. We're experts and ready to help. Please get in touch and let us know how we can help.

Topics: atlassian blog confluence knowledge-base
4 min read

What is a Portfolio in Jira Align? | Praecipio Consulting

By Amanda Babb on Jun 21, 2021 1:55:35 PM

Blogpost-DisplayImage-June_What is a Portfolio in Jira Align-

Have you heard of Jira Align? I feel like we've told you about Jira Align. Maybe a few times. We here at Praecipio Consulting can't say enough about it. Its ability to manage agile-at-scale for enterprise organizations is unmatched. 

When implementing Jira Align or expanding your footprint, however, it's important to understand the objects in Jira Align, as well as their definitions. It's also critical that your organization agrees on these definitions as a whole. With that in mind, let's discuss the Portfolio in Jira Align. What it is according to the product, and more importantly, how to define it in your organization. 

What is a Portfolio in Jira Align? 

A Portfolio supports a value stream. What is a value stream? It's a specific set of solutions that deliver value to your customers whether internal or external. Where a lot of organizations make mistakes is thinking that a Portfolio is a grouping together of projects that need to be complete in a fiscal year. There is no regard for strategic alignment to themes, no consideration for investments, and may follow a business-unit-esque structure. This is NOT how agile-at-scale frameworks define Portfolios, nor how Jira Align defines them. In addition, Programs (aka teams of teams or Agile Release Trains) support a Portfolio. This ties the execution to the strategy in Jira Align. 

In Jira Align, a Portfolio has the following things: 

  • A Strategic Snapshot
  • One or more Program Increments (PIs)
  • A budget for the Snapshot
  • Strategic Themes with allocation to PIs
  • PI budgets established
  • PI budgets are allocated across the Programs
  • Blended rate established for the PIs
  • PI budgets, per program, have been allocated to Strategic Themes
  • Portfolio Epics are created and have been connected to a Strategic Theme, scored, swagged, budgeted, and targeted to one or more PI

Ok, that seems like a lot, right? And it is. In the words of Antoine de Saint-Exupéry, "A goal without a plan is just a wish." While you may have established goals (e.g. increase new subscriptions by 15% over last year), without tying goals to the PIs, allocating a budget, then creating Portfolio Epics, you have a wish, not a plan. 

How Do I Define a Portfolio? 

Depending on your organization, you may have to take a step back and really examine how you operate. There are many questions to ask your organization: how do we deliver value to our customers? Which programs support the value delivery? Are these programs truly cross-functional and able to deliver from idea to value in the hands of the customer? 

At Praecipio Consulting, one of our Portfolios is Client Delivery. This Portfolio delivers value to our clients by providing professional services around the Atlassian products and complimentary technologies. The solution (professional services) drives the definition of the Portfolio. Our Client Delivery organization is the delivery mechanism and is grouped into two delivery programs: technical and process. While these are not mutually exclusive, they do require specialization on the part of the teams depending on the services needed from the client. 

Can you break your value delivery, solutions, and execution mechanisms in the same way? If you're struggling to do so, it may be time to reevaluate your organization's definition of a Portfolio before defining it in Jira Align. 

Once the Portfolio is defined in plain language, then examine which Program(s) will execute against the Portfolio. Remember, a Program is a team of teams organized around the value delivery of the solution to your customers. The Program operates in their cadenced PIs, creates and ties Epics and Stories together to the Portfolio Epics to estimate and complete work. Without these links, you will not be able to understand your progress, investments, or overall health of the Portfolio in Jira Align. 

Reporting on the Portfolio

I know I've said this before, but there are over 180 reports in Jira Align. However, the most commonly used object is the Portfolio Room. There are three tabs in the Portfolio Room out-of-the-box: Financials, Resources, and Execution. In all three views, you will always see the Program Increment Roadmap. This gives you an understanding of the planning and progress of the PIs.

  • The Financials tab provides Budget by PI, Estimates, and Actuals in a single glance as well as Theme Effort vs. Value and Theme Budget Allocation against the ranked Theme Priority. 
  • The Resources tab provides allocated resources by theme based on estimated work in the PIs as well as team-week allocation Theme Effort Distribution against the ranked Theme Priority. 
  • The Execution tab provides Theme Progress, Points, and team-week efforts as well as Theme Burnup based on the number of points accepted. 

Of course, the Portfolio room is configurable based on the KPIs relevant to your organization. And a Portfolio manager can drill into any or all of the items listed above in further detail either by a specific PI or multiple PIs. Simply update the Program Increments you'd like to focus on and the Portfolio Room will update the data specific to those timeboxes. While Jira Align will suggest reports under the Track section of the navigation menu, again, you can simply ask Jira Align to provide the report you need under the full Reports section. 

Jira Align makes it simple to understand the health of one or many Portfolios in your organization. Best Practice is to start with one, iterate until you get it right, then expand across other Portfolios when ready. Praecipio Consulting's deep expertise with agile-at-scale frameworks as well as intimate knowledge of Jira Align can provide you the needed support when you're ready to take your teams to the next level: contact us and see if Jira Align is a good fit for your organization.

Topics: atlassian blog best-practices portfolio portfolio-management reporting jira-align
3 min read

Does Jira do burndown charts? | Praecipio Consulting

By Mary Roper on Jun 16, 2021 3:33:00 PM

Blogpost-DisplayImage-June_Does Jira do burndowns-Good reporting capabilities are essential to Agile teams using Jira Software - and for good reason! Data visualization tools are essential for promoting good communication and collaboration. One of the most sought-after reports is included in Jira Software out of the box: the burndown chart. Read on to learn how Jira makes it easy to generate and share the burndown chart with your team and stakeholders. 

The Inputs

  1. A Scrum Board: In Jira, the burndown chart is accessible through Scrum boards only.
    • To create a scrum-type board, follow these instructions from Atlassian. Column mapping is a key configuration point, as it's the basis for the burndown chart. 
  2. An Estimation Statistic: Determine how your team will measure work, and set an estimation value on each of the issues in your sprint.
    • Jira accommodates for Story Points, original time estimate, issue count, or any custom field, provided that the custom field is a numeric custom field type.
    • We know that this can be a sticking point for your team and asked our Principle Amanda Babb to shared her thoughts about Scrum Team time tracking to help you along the way. 
  3. An Active Sprint: Once your sprint starts, begin to review your team's progress. 

The Interpretation

Once the sprint starts, you can review the burndown chart along the way to understand the amount of remaining work in a particular sprint and gather feedback on the sprint itself. Below are a few scenarios that the burndown chart captures:

Scope Creep:

Scope creep is often unavoidable, so it's necessary to understand when they occurred especially if you team is no longer on target to meet its sprint goal. Here, the burndown chart reflects an increase in scope

scope-creep-burndown-chart

Opportunity for Alignment: 

It's important for the team to collaborate and land on an estimate for each work item in the sprint - not so much for the actual estimate itself but more for the shared understanding based on the requirements. This is often seen in both over and under estimates on the burndown chart. Below, the burndown chart reflects where some work was overestimated; the team is on track to the work well before the end of the sprint. 

opportunity-for-alignment-burndown-chart

Plateaus: 

Plateaus on the burndown chart are typical when you have a team who is either new to Agile as a whole or new to working together. It's an indication that the team got off to a good start early on, but didn't carry the effort through the remaining work items. 

plateau-burndown-chart

Ready to learn how Jira Software can help your Agile teams collaborate and communicate while working in Agile sprints? Drop us a line!

Topics: blog scrum data reporting agile
3 min read

Scrum Master Basics – Part 2 of 3: The Definition of “Done”

By David Stannard on Jun 11, 2021 9:45:00 AM

Blogpost-DisplayImage-June_New to Scrum Master Role Guide–Part2TheDefinitionofDoneThis is Part 2 of a series of 3 posts on Scrum Master Basics.  Here is Part 1

I have to admit, I’m biased. As a manager and a business person, I have a vested interest in my teams success. That success is built upon them achieving a sustainable pace of delivering value to paying clients while supporting their personal growth. 

The definition of “done” is a powerful tool. In my journey as an Agile Coach and Scrum Master, I have found that focusing on the team’s definition of ‘Done’ provides tremendous return on effort. If your team jokes about ‘Done’, ‘Done done’, and ‘Done, done, done’ - there is usually a gold mine of opportunity for continuous improvement.

I believe in the strong relationship between defining done and improving a team’s overall well being – I've seen it first hand. Conversely, I see high dissatisfaction within the team, from the Product Owner and people outside the team when there isn’t a clear definition. In the knowledge business, people like to create and provide things that others use; they generally hate building the wrong thing or things that aren’t wanted or used.

Here are a couple of real world examples from teams I've worked with:

1st example from a real demoralized team:

Scrum Team: “We define ‘done’ as the feature being ready for QA to test.”

Scrum Master: This is clearly an anti-pattern to delivering a potentially releasable unit of value. We’re doing Wagile, not Scrum!

Expunge that way of thinking permanently and never say it – ever!  Seek first to understand…

A Scrum Master should always assume that people are rational and therefore behave rationally. Dig into the reason for the definition. Perhaps this was the team establishing a working agreement based upon having a lone QA person and this was seen as a solution not a problem. I bet that they’d love some help that can result from simply asking “what can we do as a team to help you with your workload?See the world from their perspective. They may be transitioning from classical waterfall workflows and the team hasn’t adjusted to the concept of a cross-functional team.

Use the principle of “take it to the team”.

How can we (the Scrum team) help you? Help ourselves?

Scrum Masters also use individual 1-on-1 coaching – How can the team and/or I help you?

2nd example from a real team:

Scrum Team: “We define ‘done’ as the feature being implemented, passing tests, and meeting the acceptance criteria – but we never release anything.”

Finding possible root causes is again key. Problem solving requires an agreed upon statement of the problem and the desired outcome from a change. In this case – it appears that it is potentially releasable, so the team may have a variety of options such as exploring:

  • What is (are) the root cause(s)? Where does the team have the capability?
  • Discussing with the Product Owner as to why value isn’t being released?
  • What if we did a dark release so that we can keep our release ‘muscles’ toned?

Please note that the 3rd bulleted item shifted to exploring possible solutions. 

Two parting questions:

  • When should these discussions occur?
  • Who should be involved?

If you're wondering if Agile is a good fit for your organization, or have any questions on Scrum methods, contact us, we would be delighted to help.

Topics: blog scrum tips project-management agile
10 min read

ITSM and ITIL: Not So Different After All | Praecipio Consulting

By Yogi Kanakamedala on Jun 9, 2021 4:01:01 PM

Blogpost-DisplayImage-June_ITSM-ITILThe change to remote work has forced Information Technology (IT) teams to quickly and efficiently serve their customers. Due to this, many people talk about using ITSM processes or ITIL strategies to help their teams. But what does this mean? Are they the same? Or completely different? What does an IT team implementing these practices look like? To understand this, we first have to understand ITSM and ITIL. 

What is ITSM?

Atlassian defines Information Technology Service Management (ITSM) as a way IT teams manage the end-to-end delivery of IT services to customers. This includes a defined set of processes to design, create, deliver, and support IT services. 

The core concept of ITSM is the belief that IT should be delivered as a service

I think of ITSM simply as a set of tools you can use to improve your IT team. Just like you would use a handsaw to cut a piece of wood or a screwdriver and a screw to connect two pieces of wood together, you have to think about what you would like to accomplish with your IT team and which tool would be best for the job. 

ITSM processes focus on your customer's needs and services rather than the IT systems behind the scenes. These processes, when implemented properly, can help cross-department collaboration, increase control and governance, deliver and maximize asset efficiency, provide better and quicker customer support, and reduce costs across the organization. What are some of these magical processes? Glad you asked! 

  1. Service Request Management
    Any incoming inquires asking for access to applications, software licenses, password resets, or new hardware is classified as Service Requests. These requests are often recurring and can be made into simple, duplicable procedures. These repeatable procedures will help IT teams provide quick service for the recurring requests. Applying well-designed practices to your Jira Service Management application can streamline the process for an organizations' customer to create Service Requests and for internal IT teams to act on the Service Requests.  

  2. Knowledge Management
    The process of making, sharing, utilizing, and managing data of an organization to attain its business objectives can all be a part of Knowledge Management. Creating a Knowledge Base (KB) for IT teams to create content is crucial for teams to learn from the past and maximize productivity. Having a collaborative workspace, such as Confluence, for all teams to work within can help create one source of truth of information. KB articles can also be shared with your customers through the Jira Service Management portal to help resolve common or simple Service Request without having to contact the IT Team. 

  3. IT Asset Management (ITAM)
    IT Asset Management (also known as ITAM) can help ensure valuable company resources are accounted for, deployed, maintained, upgrades, or properly disposed of. Because assets have a relatively short life-cycle, it is important to make the best use of all assets. Integrating tools such as Insight with your Jira instance can help track all valuable assets throughout your organization conveniently within Jira issues in real-time. 

  4. Incident Management
    Any process that is responding to an unplanned event or downtime will fall under the Incident Management bucket. The only goal of Incident Management is to make sure that problematic services are brought back to their original operational status in the shortest time possible. For any incident to be quickly resolved, the original reporter has to be able to quickly communicate with the proper IT team asking for help and the IT team must be able to easily communicate back with the reporter to gather any relevant information needed to solve the problem. Jira Service Management can help make this crucial communication effortless.

  5. Problem Management
    Taking lessons learned from an incident and determining the root cause of the problem so that future incidents can be prevented or, at minimum, limiting downtime is the basis of Problem Management. Once a root cause analysis is performed on an incident and documented within your Confluence instance, the impact of future incidents can be reduced. 

  6. Change Management
    Change Management can be used to control and understand the impact of changes being made to all IT Infrastructure. The Change Advisory Board (CAB), a group of individuals tasked with evaluating, scheduling, and validating a change, can be leveraged to better maintain and ensure the stability of your IT Infrastructure. By taking advantage of Jira, employees can easily suggest changes and the CAB will be able to review the proposed changes, approving and scheduling the change as they see fit. 

To see these processes in action, let's consider a tangible example that will help bring it all together:

"Austin Snow" is a new employee at your company. As part of the onboarding process, they will need a brand new laptop. As their manager, you submit a Service Request to your IT team through the Jira Service Management Help Center. An agent in your accounting department is then assigned to this task. Using information from a KB article that has been built out in a Confluence page, the agent can see that they are supposed to put in a purchase order for the new device. From the Confluence page, the agent also knows to add this new asset in Insight and assign ownership to Austin.

Once the laptop is delivered and Austin tries to access an application and finds that they get a 404 error message. Austin reaches out to the IT team through the Help Center to create an incident with them. The IT team then proceeds to investigate this issue. They can find the root cause of the problem and fix it. Using the lessons learned from this incident, the IT team performs a root cause analysis (RCA) for the problem. As a result of the RCA, it is found that a change to the organizations' infrastructure can help prevent this problem in the future. The IT proposed the change to the Change Advisor Board (CAB) who then investigates the impact of this change, weighs pros and cons and schedules an outage window to perform this change. 

As can be seen in this example, ITSM processes can help quickly fulfill requests, transfer knowledge, keep track of assets, respond to problems, identify the cause of a problem, and implement any changes needed to prevent problems in the future. 

What is ITIL?

Information Technology Infrastructure Library (ITIL) is a set of best practices designed to support a company's IT operations. ITIL was introduced in the late 20th century as a series of books by a government agency in Great Britain in an attempt to help the British Government provide a better quality of IT service at a lower cost. ITIL v2 condensed all of the content in the early 2000s into nine publications. These two older versions are seldom used, most organizations currently implement ITIL v3 or ITIL 4.

ITIL v3

In 2007, ITIL v3 introduced the service lifecycle, a set of five core publications, to help organizations focus on continual improvement. The ITIL Service Lifecycle consists of five stages; Service Strategy, Service Design, Service Transition, Service Operation, and Continuous Service Improvement.

ITIL3-service-lifecycleSource: AXELOS, “ITIL Foundation: ITIL 3 Edition” (2007 - Updated 2011)

The Service Strategy stage helps level set the expectations of an organization so that a service provider can meet the organization's business outcomes. The Service Design stage helps the service provider gather all the requirements and create a plan to turn an idea into reality. The Service Transition stage is when the design from the previous stage is implemented and made ready to go live as smoothly as possible. The Service Operation stage focuses on making sure the services being provided are being fulfilled as agreed upon. Finally, the Continuous Service Improvement stage focuses on service provided staying agile and keeping up with the ever-changing needs of the organization. 

ITIL 4

Most recently, ITIL 4 took into consideration the latest trends in technologies and service management to help organizations as they undergo digital transformation. ITIL 4 consists of two main components; the four dimensions model and the service value system (SVS).

ITIL4-service-value-system-1

Source: AXELOS, “ITIL Foundation: ITIL 4 Edition” (2019)

The four dimensions model lays out four key areas to consider to ensure a holistic approach to service management. These four dimensions are Organizations and People, Information and Technology, Partners and Suppliers, and Value Streams and Processes. The four dimensions have to work together to help ensure that any Product or Service provided to the customer is able to provide value in an effective and efficient manner.

For example, in the above Austin Snow use case, the Organizations & People would be the HR Team performing the onboarding, the IT team helping deliver the laptop, the Support team handling the outage, and Austin Snow themself. The Information & Technology would be all the tools, Jira Service Management, Insight, etc. that were used to help Austin. The Partners & Suppliers would consist of the internal IT team in charge of the service request and incident management or any other external team that as leveraged to deliver the request or fix the incident. finally, the Value Streams & Processes would consist of any well-defined procedures that were used to help deliver the service to Austin.

ITIL4-service-value-chain

Source: AXELOS, “ITIL Foundation: ITIL 4 Edition” (2019)

The service value system lays out how all the components of an organization have to work together to provide maximum value. To accomplish this, 5 main elements are used produce Value from an Opportunity or Demand; Guiding Principles, Governance, Service Value Chain, Practices, Continual Improvement. 

Guiding Principles help define how an organization will respond in all circumstances. These principles should be considered when making any decisions. Governance defines how an organization is directed and controlled and always stem from Guiding Principles. The Service Value Chain is a set of inter-united processes used to deliver a product or service to a customer. Practices are resources to help perform work. Continual Improvement is how the process can be improved to help provide the most amount of Value to an organization. When all of the elements of the SVS are implemented and used properly, an organization will be able to capitalize on every Opportunity. The four dimensions must be considered with all elements of the SVS to ensure a great quality of service is provided to your customers. 

ITIL v3 and ITIL 4 are essentially guiding the same fundamental ideas of service management. ITIL 4 takes a new approach to provide this guidance. It is important to consider the inner workings of your organization to understand a set of principles that will best mesh with your organization. 

How are they related?

Now that we have laid down a foundation for ITSM and ITIL concepts, let's explore the relationship between ITSM and ITIL.

Unlike the title of this blog may suggest, these two concepts are not opposing ideas. ITIL is a framework of ITSM, meaning ITIL takes the concepts and values of ITSM and lays out a set of defined best practices that organizations can easily apply to their business to help improve IT services. In other words, ITSM processes describe the "what" while ITIL best practices describe the "how". 

ITIL is not the only ITSM framework; frameworks or processes such as DevOps, Kaizen, Lean, and Six Sigma are also implemented by organizations. ITIL is the most popular ITSM framework to help improve IT service delivery.

In summary, ITSM is a defined set of processes to design, create, deliver, and support IT services. ITIL, a framework of ITSM best practices, can be used as a set of guidelines to quickly adopt ITSM principles into your organization. These guidelines can then be continuously improved to be a perfect fit for your unique IT team. 

As The Digital Transformation(ists), Praecipio Consulting can help you integrate digital technology into all areas of your business. For more information, please check out these case studies: FORTUNE 20 ELECTRONICS COMPANY OPTIMIZES JIRA AND CONFLUENCE FOR ITSM BEST PRACTICES and WORLD'S LARGEST BEVERAGE AND BREWING COMPANY MIGRATES TO ATLASSIAN ITSM PLATFORM and blogs Three Weeks to an ITIL-based Service Desk—No, Really

If you have questions on ITSM or ITIL, and wonder if your organization can benefit from these powerful methodologies, contact us, and one of our experts will be glad to help.

Topics: jira blog confluence process insight itil itsm digital-transformation jira-service-management remote-work frameworks
2 min read

Scrum Master Basics – Part 1 of 3

By David Stannard on Jun 3, 2021 10:13:00 AM

Blogpost-DisplayImage-June_New to Scrum Master Role Guide – Part 1 (2)

Congratulations on becoming a Scrum Master (SM)!

Scrum is a tool that builds teams. It exposes the issues but not the causes and solutions. A Scrum Master helps their team grow through continuous improvement & collaboration. 

As a builder of teams, I’ve often seen smart employees and colleagues return from training and struggle with how to apply their new knowledge. Most often, failure occurs when the returning person takes an approach of telling people what to do and why the current approach is wrong.


Hence this 3 part blog series.

Some of the chief motivations for choosing Scrum are:

  • Delivering potentially releasable value at a regular cadence

  • Being responsive to change instead of steadfastly sticking to a plan

  • Eliminating waste / becoming leaner

  • Collaboration with clients instead of dry, incomplete, ambiguous contracts

In existing organizations, I’ve seen more successful outcomes and happiness when taking the “Start Small” approach. Mike Cohn in his book “Succeeding with Agile” observes “...there can be no end state in a process that calls for continuous improvement...”. 

Therefore, take incremental steps with your team – leave grandiose visions to the C-level. This increases the probability of success, which breeds confidence and momentum while reducing risk and investment. Similar to software development, your emotional stake in an incremental effort is much lower than multiple weeks of time investment; you’ll more easily throw away an approach that isn’t working. Your team learns experientially which requires trying, learning, adjusting, and growing together. Your team is a living system – so probe, observe, and adjust.

The noun “teams” is key. A Scrum Master’s success ultimately depends upon their ability to help them. You will require patience, the desire to learn about how to build teams, and a firm commitment to the values and principles of Agile. 

Assuming that you’re joining an existing team, here are a few concrete actions:

  • You’re about to change the dynamics of an existing team. So Meet the current SM and discuss the transition prior to showing up to the team’s ceremonies

  • Ideally, be invited to the ceremonies: attend – observe and assure the team that you aren’t planning any unilateral changes

  • Gain access to and review your team’s working agreement. Specifically – the definition of ‘Done’ - more in Part 2

  • Study their sprint board – more in Part 3

And remember – as Stephen Covey writes in The 7 Habits of Highly Effective People – "Seek first to understand not to be understood"

If you're wondering if Agile is a good fit for your organization, or have any questions on Scrum methods, contact us, we would be delighted to help.

Topics: blog scrum tips project-management agile
2 min read

Agile Tips - The Purpose of a Sprint Retrospective

By Michael Knight on Jun 1, 2021 10:15:00 AM

Blogpost-Display image-May_Purpose of a Sprint RetrospectiveA sprint retrospective is, in practice, a meeting scheduled after every 1-2 sprints in which the team comes together to discuss how to improve the way they work. The meeting can follow several formats, with the most common consisting of each team member sharing what is working well, what isn’t working, and any new ideas they have to improve. Some examples of takeaways from the meeting might be “Our daily standup is helping to keep everyone on track,” “We need a better process for reviewing tickets after QA is finished with them,” or “Let’s try estimating with story points instead of time values.”

Retrospectives were introduced to make sure the team is constantly in communication about how to improve. This process is commonly known as a feedback loop, and is one of the hallmarks of any good Agile process. Feedback loops have been discussed as one of the most important parts to becoming successful, either as a team or as an individual, a claim backed up by copious amounts of business literature full of research and examples on the topic. A prime example of this can be found in Talent is Overrated by Geoff Collins. While not a perfect book by any means, Collins does a wonderful job of explaining the importance of feedback loops. The argument posits that the way humans improve at anything is to do the thing, look back on the thing and analyze it, figure out how to improve performance of the thing, then do the thing again. The retrospective helps teams to do the middle two parts of that process.

Here are some tips for running a successful sprint retrospective:

Get on a consistent cadence

Doing retrospectives too often will lead the team to resent them. Doing them not often enough will greatly reduce efficacy and result in an inability to put into action the ideas brought up in the meeting.

Prepare ahead of time

Before the meeting, encourage team members to spend a half hour thinking of what is working well, what isn’t working so well, and ways to improve. That way the team can most efficiently use everyone’s time when they come together for the retrospective.

Bite off what you can chew

Instead of trying to implement all the new ideas after every retrospective, focus on determining which ideas are the quick hitters: those that have a big impact, but are easy and quick to implement. By adding the one or two best quick hitters each week, the process will evolve at a sustainable pace. Over time, the team will likely run out of quick hitters, giving you a chance to implement the more intricate ideas. 

Are you making the most out of your teams? If you need assistance with Agile, get in touch, we'd love to help.

Topics: blog optimization process process-improvement sprint agile
5 min read

How to Implement an IT Modernization Strategy - 1st of a 5 Part Series

By Praecipio Consulting on May 28, 2021 10:15:00 AM

Blogpost-Display image-May_How to Implement an IT Modernization Strategy- Part 1 What is IT Modernization

When we initially set out to write a piece about how to implement an IT Modernization Strategy, we quickly realized there is not only a lot to consider when weighing the possibilities, but also a lot of context required to lay a meaningful foundation. We want to discuss what IT Modernization is and what it means for your individual business, as well as other terms and ideas to help define the overall picture. Join us as we unpack and discuss IT Modernization through this series of blog posts.

Part 1: What is IT Modernization

We'll begin by exploring the motive behind IT Modernization, and identifying the traits that make up the profile of an entity that is looking to implement IT Modernization in their enterprise.  Overarching themes include Digital Transformation, Capital Expenses vs Operational Expenses, Legacy Systems, how Cloud fits into the picture (because it's no longer a question of "if" cloud fits into the picture), as well as others.

There are several questions to ask when trying to nail down the motive- we'll be working through these questions in our series:

  • Why would you be interested in IT Modernization in the first place?
  • What are some of the apparent benefits of IT Modernization? 
  • What would IT Modernization look like in your organization and how?
  • What would a rollout plan look like?
  • When do you tackle certain things over others?

By the end of this series our goal is that you will have the foundational understanding of IT Modernization that will help you answer these questions.

The Basics

If you've worked with Praecipio Consulting before, you know we like to start simple - so let's begin with the basic question "What is IT Modernization?"  To oversimplify the concept, IT Modernization is a process of assessing an individual system or group of systems in your organization with the intent of establishing the best possible balance of cost and efficiency. One of the challenges we often call out is that this can look vastly different depending on the context of what it is being applied to.

As part of an IT Modernization strategy there can be some aspects of your business where it makes sense to move in a more digital direction, for example migrating on-prem resources to virtualization or the cloud. While the overarching goal may be to get to the cloud, there are different paths that you organization may take based on your specific context. In the case of moving  an application to the cloud, there are the branches hosting the application on a digital platform like AWS or moving completely to a more SaaS model and allow it to be maintained by a third party.  And of course, for some other aspects of your business it could make more sense to maintain an on-prem solution but update the infrastructure. The key thing to consider here is how you can balance the cost of maintaining whatever aspect of your business you're assessing with the amount of performance proficiency it is providing.

Another term you'll often hear mentioned in the same breath as IT Modernization is Digital Transformation.  It's true that these often go hand-in-hand, but the main difference to consider is that Digital Transformation gets into the explicit changes you have to make in order to keep pace with the digitization of aspects of your business, like products, assets, and processes. IT Modernization is more of a strategy for improving your business through cost savings, efficiency or improving on how agile your business can be. More often than not, Digital Transformation will be a key part of your IT Modernization plan, but they are not necessarily mutually exclusive.

The Breakdown

With that in mind, let's start to identify the motive a business might have for exploring IT Modernization and what attributes make up its profile. The first question you have to ask is "Why would you even be interested in IT Modernization?" The short answer is every business should be thinking about IT Modernization on some level. We exist in a world where the only true constant is change, and as time progresses the main thing that we're betting on is that our technology and business landscapes will continue to shift. The most successful businesses will adjust business practices to match - if you're not willing to embrace the change and make it work for you, your competitor will, and they'll be happy to take your market share off your hands. Additionally, IT Modernization benefits the business, either by lowering your operating costs, or empowering you to be more efficient managing resources and development. Thinking about ways you can Modernize aspects of your business is just good business.

So how do you this? What does it look like?  Well, we've touched on the two key factors associated with Modernization: Cost and Efficiency.  There are a couple schools of thought when it comes to the approach and how you can execute modernization, outlined below.

The first approach would be considered a more traditional approach. This approach involves making incremental changes made over time targeting the most costly or bottlenecked aspects of the business. From this you can attempt to figure out how you can make them more efficient or cost less, or maybe a combination of both. The main benefit of an approach like this pertains to risk: changing pieces incrementally allows you to carefully consider those changes and their impact on the business as a whole. Incremental changes can also be very good for the bottom line since it allows you to budget changes over time.  One of the potential downsides to an incremental approach is it can be limiting. Taking the time to make incremental changes can take.. well... time.

On the other end of the spectrum there's the end-to-end or holistic approach.  This is about what you'd expect: instead of incrementally making changes you're making a plan to implement broad changes across your organization as a whole. This requires careful planning and consideration of what elements need to change in what sequence, to truly understand the potential impact across the organization. One of the benefits of this approach is it keeps the organization from advancing in a siloed manner, which can lead to less efficiency as a whole. In one instance, that might mean two different business groups moving their application to two different cloud solutions that offer the same functionality. Whether your approach is more incremental or end-to-end, it's important to try to take into account the potential impact across the business and ensure groups coordinate the efforts.

Modernization  Mechanisms

When it comes to implementing IT Modernization, it's important to understand that it is much more than a simple update to your technologies. Rather, the approach should be thoughtful and well planned, with an eye to the future and a willingness to embrace the new and sunset the old. At a high level it is important for your teams to identify out of its legacy software or assets what can can be invested in - whether through legacy software modernization or replatforming- and what should be divested from. Reaching a decision on the best path forward for each application will take time - legacy modernization is not an all or nothing endeavor. We'll spend dedicated time in future posts discussing how you can best approach application modernization. 

It's Just the Beginning

As you consider what IT Modernization means for your organization, keep in mind that there is not a one size fits all solution. Our goal in this blog series is to provide helpful context to help you define what an IT Modernization approach could look like and what success would mean to your organization.

At Praecipio Consulting, we enjoy helping our clients reach their IT Modernization goals and bringing teams up to speed with digital demand. If you'd like to learn more about how we can help, please reach out to us!

Topics: blog aws optimization saas it digital-transformation
5 min read

Data Lake Basics

By Kye Hittle on May 27, 2021 9:02:00 AM

Blogpost-Display image-May_Data Lake Basics

With Atlassian's upcoming release of Jira Data Lake for Jira Software Cloud, it's a good time to review the jargon we might stumble on in the reporting and business intelligence (BI) space. So let's jump into the (data) lake!

One word of caution: the BI industry has many players with varied opinions. Some terms get used and reused in multiple ways. One example is the emerging use of "lakehouse" - a combination of "data lake" and "data warehouse." Here we'll stick to as close to canonical as possible but expect to see terms used differently as you research.

Why does BI even matter? What are KPIs?

Your organization has systems (e.g. computer applications) which create and contain data. That data is extremely valuable for fact-based decision making in your organization. 

A CTO or CIO is able to more effectively allocate help desk head count with ready access to accurate metrics (also called Key Performance Indicators, or KPIs) like Mean Time To Acknowledge (MTTA) and Mean Time To Resolve (MTTR). (Note: MTTR is a tricky acronym. As Atlassian notes, there are at least four common incident management metrics that share this abbreviation! This stuff can be confusing...)

To provide these valuable, up-to-date KPIs to decision makers, we turn to BI. This industry is a dizzying array of technology components which take various approaches to achieving BI's primary objective: turning raw data into actionable insight. Often, we need to integrate multiple BI components to get from point A (data in the source system) to point B (reports used for decision making).

BI solutions often leverage a data lake or data warehouse to store business data.

What is a data lake?

A data lake is a central store of raw business data. The data lake is not typically used by the source systems whose data it contains.

The lake is designed to be accessed by tools like Tableau, PowerBI, and Qlik in order to analyze and produce insights from the data. We'll call these analysis and presentation applications "BI tools." To continue the lake analogy: if the BI tool is a fishing rod, then the data is the fish.

A data lake typically uses a file store technology but when it comes to Jira Data Lake, we don't really need to know much about the underlying tech because Atlassian Cloud takes care of choosing, configuring, hosting, and maintaining it for us. One less thing on our plate? Great!

All we need to do is connect our BI analysis and presentation tools (Tableau, PowerBI, Qlik, etc.) to Jira Data Lake. Boom! We're ready to start creating reports, graphs, dashboards, and whatever else we need to answer questions for our organization.

How is a lake different from data warehousing?

As mentioned earlier, some BI solutions use a data warehouse instead of a data lake. Some use both. While the line has blurred between the two, lakes are usually more unstructured than warehouses.

The initial data lake concept encouraged organizations to dump all of their raw data into the lake, including data from relational databases, flat files (e.g. CSV files), videos, and more. The promise that smart software and ever-increasing computing horsepower would eventually create solutions for accessing the overwhelming amount of data in the lake hasn't really come to fruition quickly enough. And many data lakes turned into data swamps. Lakes these days, like Jira Data Lake, are more purpose-built and have better designs for preventing a descent into swampland.

A data warehouse is more structured and normally designed with transformation processes on the front- and/or back-end that clean, normalize, and handle any other standardization before presenting it to our BI tools. These processes are represented by the "T" (Transform) in some more acronyms: ETL (Extract Transform Load) or ELT. The result is more predictable and accurate, but the cost and time to create these transformation processes is much higher.

Why use a data lake?

Why invest in this effort to centralize data in lakes or warehouses? Our BI tools can often connect directly to our application's database. Wouldn't it be easier to skip the lake/warehouse?

Eliminating the data lake or warehouse would simplify our solution design but experience has shown multiple issues with the direct-connect approach.

The most critical issue is often the potential load a BI tool can place on an application database. BI queries often require large swaths of data which can only be fulfilled through heavy workloads on the database. In addition, BI tools often don't optimize queries for performance. BI workloads can cause database contention and application stability should always be prioritized over BI needs. With today's easy-to-use BI tools accessible to a larger and less technical audience, this issue has only become more prevalent. Connecting our BI tools to a data lake prevents risking any application stability issues.

The next most common issue we see is needing to combine data from multiple systems. Since your organization doesn't just use one system, combining data across the organization is how so many powerful insights occur. For example, tying Jira KPIs to financial data is one way leaders can more easily understand technical metrics. But financial data is stored in the accounting system, not Jira. A direct connection to an application's databases only allows access to that system's data, preventing cross-system data analysis. While some BI tools allow you to perform "cross-database joins," performance is often unacceptable and some links are just not possible. Often the data from different systems needs to be cleaned and standardized before it can be linked for analysis. Doing this in a data lake/warehouse is far more efficient than attempting it "at runtime" in BI tools. When we first centralize our data we have the ability to combine data from as many systems as needed.

BI is all about trends over time. Some applications don't maintain much, if any, historical data. A direct connection to these systems doesn't allow for time-based analysis. The historical data simply doesn't exist. Lakes allow us to snapshot data at regular intervals in order to perform valuable time-based analysis.

Finally, with cloud apps like Jira Cloud, we don't have the option to connect directly to the application database. The only data access is often through APIs which can be slow for analysis and suffer from many of the same issues mentioned above. Jira Data Lake provides performant, safe data access.

Data lakes arose from the need for flexibility. No two organizations use the same systems or have the same data needs. Your organization's data needs will also change over time. The direct connection to an application database is too tightly coupled and doesn't provide enough agility to provide BI insights.

If you're wondering if this powerful new tool is a good fit for your organization, or have any questions about anything Atlassian, contact us, one of our experts would love to help!

Topics: blog management tips data business-intelligence data-lake jira-data-lake
3 min read

Atlassian Certification Program: Should I get an ACP Certification to be a Jira Admin?

By Luis Machado on May 26, 2021 10:07:00 AM

Blogpost-Display image-May_Atlassian Certification Program Should I get an ACP certification to be a Jira admin-To quickly answer the question: YES. At least that was the answer for me.  I’ve been an Atlasssian admin for nearly 7 years and I’ve only just this year received my first Atlasssian certification (ACP-600 in case you were curious).   It’s only recently that I’ve been able to really appreciate the value of getting certified, and I plan to go for as many certifications as I’m able to.  

Getting certified was something that I had thought about from time to time, but honestly I didn’t see how it would help me be better at my job.  I had put in a request with my employer to see if they would compensate me for the cost and never really heard anything back.  The cost was enough for me at the time that if my employer wasn’t going to worry about it, then I certainly wasn’t.

Fast forward several years and I find myself laid off, and in search of job. The layoff was budget related, the company was having some issues bringing products to market and so cuts were made all over. Even given that I found myself in a position and a state of mind that I hadn’t ever really considered I’d be in.  Those who have experienced being laid off know that it can actually be a pretty traumatic event, especially if it’s from somewhere you’ve worked for a long time.  I wanted to continue working in the Atlasssian ecosystem as it was something that I had become very familiar and very fond of.

After revamping and updating my resumé, I quickly realized that on paper I didn’t really seem to offer a whole lot to a prospective employer.  I had a decent amount of experience in my field but all I had to offer was my word.  Now, in an interview that could be enough.  If you can talk shop, and give enough context for the things you’ve done in a presentable and coherent manner, then an employer could potentially see the value in what you have to offer.

I was fortunate that eventually that actually happened for me and I landed a job with Praecipio Consulting, but before that, I had to fall back on other skills from previous jobs I had done.  Part of the requirements for companies that are Atlasssian Partners is maintaining a certain level of certification, being certified from the get go gives you a potential advantage. Looking back, I can see that me not having any certifications not only reduced my potential to even land that interview, but maybe also played a part in me being laid off in the first place. 

Certifications and similar credentials are there to prove to everyone else that you know what you’re doing and you’re continuing to grow, and learn, and become more proficient in your craft.  There is another aspect to this though that had not really occurred to me until now and that is, not only does it prove to others you have the skills to pay the bills, but also to yourself.  When you have something tangible that validates all the time and effort you’ve put into becoming the professional you are, it gives you the confidence to raise your own expectations.  This is something that is beneficial to the employer and employee alike. If I’m ever again in a position where I’m re-entering the job market looking for that next stage, I will be exponentially more confident that I’ll be able to find something, because I’m taking the time to ensure my resumé reflects my skills with official validation. 

So if you’re an Atlasssian professional, you like the toolset, you see yourself staying within the ecosystem and want to progress, do yourself a favor and start getting certified.  I recommend first going to your employer and seeing if they would be willing to cover the cost. Even if they’re not willing, it’s worth it for you to pursue it on your own.  It’s reassurance for the employer, but it’s an investment for the employee. One that will show dividends down the road, regardless of where it leads you.

If you have any questions regarding the Atlassian certification process: contact us, we'd love to talk you through your options.

Topics: jira atlassian blog training atlassian-certification-program
2 min read

Why Instructor-led Atlassian Training Is Better Than Online Courses

By Jerry Bolden on May 24, 2021 9:15:00 AM

Blogpost-display-image_Why instructor-led Atlassian training is better than online coursesAs the world transitions to more virtual or remote work and training, it seems that more organizations look to the ability to perform training online. Not with an instructor, but just the class or lab. 

While it is true you can follow along with a course online, you cannot ask the course questions and get answers live, and the question you type in will likely only get a direct answer (if any),  not an in-depth assessment of the question and other considerations that could arise.  Having an instructor-led course makes sense for the same reason there is a Human Resources department in each company: they are in charge of onboarding and touching base with new employees as they transition into a company and its culture.  Sure, the tasks of onboarding can be done online, but who would be there to answer questions or concerns of the employee without a team dedicated to making each employee successful in a company?  Instructors have the same drive, which is to make not only the training successful, but to ensure each person successfully learns the program. 

Personal interaction and adjustments to the class can be very important, and are not easily done through online-only learning.  Instructors are able to give students the experience and anecdotes they have learned while using the product.  They are not only able to clearly answer questions and point the person in the right direction, but they can also teach some of the 'tricks of the trade' they have learned throughout the years. This can help people retain the information as it is a personal story to connect the person and the instructor.  

Interpretation of body language or inflection in a voice is something that once again can only be done with human interactions.  The ability to listen to a person's question and read them or their voice allows for a better set of answers given to questions.  An instructor can not only give the answer to a specific question, but also understand if that answer is what the person was truly looking to understand or is now just accepting that answer and hoping they will learn, later on, what they wanted to know.  This also allows instructors the ability to ensure they have clearly understood the question and, in turn, clearly provided the right answer to the question.  The minimal interaction an instructor allows is for clarity and answering of questions to be focused to each person.  

Finally, when you have instructor-led teaching, the instructor is able to understand the different levels of knowledge/experience in a class at any time.  This allows the instructor to help with "extra" learning by being able to teach different levels of information.  This ability is important not only for the instructor to ensure they are communicating at the correct levels to people, but also it helps to drive the most fulfillment from the training. As instructors adapt to the classes, they can still go over the information, but at times may go a little deeper into a demo if the class is showing they can handle the learning, thus giving them more value to the training and the time they are willing to invest in the class. 

Instructor-led training is not necessarily essential to learning how to use a system, Atlassian or others. Yet without an instructor, the value of the course is minimized and relegated to only the material on the screen.  Instructors are able to not only lend their experiences and learned knowledge, but also allow for different individuals to get more out of the training as they may be able to handle more advanced information.

Interested in getting your teams the tools they need to reach their maximum potential? Contact us, and one of our Atlassian experts can talk you through our training options.

Topics: atlassian blog teams training atlassian-solution-partner remote-work
2 min read

Best Practices for Using Labels in Jira

By Courtney Pool on May 21, 2021 8:15:00 AM

Blogpost-Display image-How to use labels in jiraJira has a multitude of ways to group and categorize similar issues, such as through projects, requests types, or components. Many of these are aimed at issues that exist within one project, though, making it a bit more difficult to track items across your entire Jira instance. This is where labels can shine.

Labels are basically tags on issues. If you have 4 different projects that may all see tickets related to the same customer, then a label for that customer would give you a great way to quickly gather an overarching view of everything that exists for them. You can also have multiple labels on an issue, allowing you to easily catch it in any number of buckets.

Like with many things in life, though, a watchful eye and steady hand are needed to really use labels effectively. With that in mind, we’ve identified a few best practices to help.

1. Labels should be used for informal grouping.

In other words, don’t count on just labels to be the driving factor of important reports or anything else you need to be accurate 100% of the time. Because new labels can be created by users from the issue screen directly, they are not and should not be viewed as a source of truth. They’re great at what they do, but be careful to limit the importance placed on them.

2. Try to limit the number of labels you have.

Labels are shared globally, which means the list can get very long, very quickly. To make them more effective, try to come to a consensus internally on the whens and whys of new labels.

3. Set up clear naming guidelines.

Limit the number of labels by making sure you have clear naming guidelines. This will be different from organization to organization, but we encourage you to discuss and decide on these guidelines early and to then check in periodically to make sure they're being adhered to. If you’re looking to label issues from ABC Law Firm, for example, you could quickly end up with labels for abc, abclaw, abc-law, etc. Without naming standards, you will dramatically decrease the efficacy of the labels as an informal(*) grouping tool.

4. Routinely clean them up.

Even with clear naming guidelines and a company decision to limit the number of total labels, you may still end up with some that are no longer relevant down the line. Set a regular time for somebody to go in, check them out, and determine if there’s any room for clean-up. Even better, cleaning up labels is as simple as entirely removing them from all issues, giving you the opportunity to swap them out for another if needed.

5. Don’t overuse them.

This one really echoes all of the points above, but it bears repeating: Don’t overuse your labels. If you’re looking for something to track issues for a very-important, super-vital, must-be-accurate report? Labels are likely not the answer. Have a certain issue type that can have 30 different permutations? Again, labels are likely not the answer.

Jira as a tool has many options for tracking related issues. And labels, in the right hands, can be a great means of doing just that — if they’re handled intentionally and in moderation. Don’t be scared to give them a try, but do keep these best practices handy to keep your labels as helpful as possible.

Contact us if you have any questions on labels, or in anything Jira: We are experts in all things Atlassian.

Topics: jira blog best-practices tips information-architecture
3 min read

Best Practices for Software Licensing Management

By Jessica Ellis on May 19, 2021 11:25:00 AM

Blogpost-Display image-Best Practices for Software Licensing ManagementLet's make something clear: my.atlassian.com (MAC) is your best friend. Never heard of it? It's Atlassian's central license management platform. On the MAC website, you'll be able to see your license information and history, update technical & billing contacts, access license keys, and generate development keys. 

Over the last 6 years, I have helped hundreds of customers (from small businesses to Enterprise companies) with their license management. There are a few questions and frustrations that I see time and again, and based on that feedback, here are some of my top suggestions that will save you from future headaches.

Track your SEN’s

Your Support Entitlement Number (SEN) is a unique identifier that follows the life of the license. Even if the user tier or product name changes over time, your SEN never will. Consider it your “source of truth”. SEN’s can be found in your my.atlassian.com account, and are visible to all technical and billing contacts. I recommend sharing your SEN list with colleagues and procurement to make renewals more transparent. You can either export your license list from MAC, or include additional technical and billing contacts to open up visibility across teams and departments. 

Centralize your visibility

Once the Atlassian products gain popularity in an organization, I receive requests from different business units asking for their own instance or app for specific functionality. Logically, it makes sense to assign the technical contact as the person in charge of that instance or app. However, if you do that for each license you can splinter the visibility across the organization, making renewals complicated and time consuming.

I work closely with a global video game company who renews over 300 Atlassian licenses annually. Their organizing method has helped procurement streamline renewals, decreasing the amount of time it takes to identify who owns the license and what needs to be renewed. Each time a new license is requested I use the same technical contact email associated to the procurement department. After purchase is complete, procurement adds secondary technical contacts to the licenses in my.atlassian.com, giving the end user access to license keys. This allows procurement to see ALL licenses in MAC, understanding the entire license footprint and centralizing visibility when it comes time to renew.

Proactively transition your licenses

Life happens and people switch jobs all the time. I get a lot of requests from end users who inherit licenses but can’t see any of the licensing information or access license keys. How do you make sure the handoff is seamless before leaving? If you oversee the Atlassian licenses in my.atlassian.com, change the technical contact to the new employee information, or transition to another colleague who can retain access in the meantime. This will ensure continuity and give your organization a change management process for your licenses.

Co-term your end dates

Co-terming your license end dates can save you time during procurement cycles and allow you to plan for and estimate your annual licensing budget. If you have a variety of end dates it is best to co-term everything at once, allowing some licenses to be renewed for less than 12 months. Any new license purchased throughout the year can be co-termed (as long as the term is for 12 months or more). If this requirement makes the order too expensive, you can purchase your license for 12 months and realign to the co-term date on your annual renewal.

Co-terming is only possible for on-premise licenses (server and data center). Atlassian’s cloud licensing automatically “co-terms” the licenses on each cloud site to the same end date. However, at this time, if you have multiple cloud sites or Atlassian Access, they will have different end dates.

License Management doesn't have to be stressful: Praecipio Consulting's extensive experience can help you better navigate and manage your licensing landscape. Contact us, we'd love to discuss your options.

Topics: atlassian blog best-practices tips licensing
6 min read

All in Good Time with Atlassian’s Team Calendars for Confluence

By Kye Hittle on May 17, 2021 11:23:52 AM

Blogpost-display-image_Team CalendarsAh, a fresh, new month. For so long there was always at least one day where my email inbox was flooded with many, many calendar invites for recurring company-wide meetings, holidays, and deadlines. After carefully clicking “Accept” on each invite, I’d think, “there’s got to be a better way.”

Atlassian’s Team Calendars for Confluence offers a great solution, and it's included with Cloud Premium subscriptions! Let’s take a look.

TEAM CALENDARS FOR CONFLUENCE

 

Image source: Atlassian

What is Team Calendars for Confluence?

The plugin adds a Calendars tab to each space and you can create multiple calendars using built-in or custom event types. Each user also gains a “My Calendars” page which rolls up all Team Calendars they’ve watched. This is centralized, always up-to-date, and customizable calendar management.

Why use Team Calendars?

Clear the clutter. While Team Calendars helps avoid periodically flooding everyone’s inboxes with invites, it also prevents tasking someone to reissue invites to new team members who onboard mid-year. Even those of us who aren’t new can avoid getting peppered with calendar updates when inevitable changes occur.

Visualize. Team Calendars display events as a live calendar, which is a visual metaphor instantly grokked by most everyone. Select between week, month, list, or Gantt-like timeline views. Assign different colors and icons to event types to further visually distinguish your layout. We often see clients using Confluence tables to list out dates. Tables capture the event data but require unnecessary mental overhead to comprehend and can’t be combined with other calendars to spot opportunities and conflicts.

Crowd-source your calendars. Team Calendars allow any user to add and edit events, keeping calendars comprehensive and accurate. Most calendar systems don’t allow this or it’s too cumbersome. In Confluence, it can also be restricted when needed.

Let’s TAke Control of Calendars

At Praecipio Consulting, we’ve helped organizations use Team Calendars for an incredibly diverse set of use cases. Here’s how we suggest you get started. 

Corporate holidays and time off (vacation, medical leave, volunteer time off, etc.) are often some of the first calendars created since they have major impacts across the organization. Keeping these events in context with your day-to-day planning in Confluence increases their visibility and prevents conflicts.

Holidays and time-off are just the tip of the organization-wide event iceberg. Take a look at your work calendar and you’ll see lunch & learns, committee meetings, submission deadlines (expense reports, timesheets, benefits enrollment, etc.), social events, and more. Centralizing all of this in Confluence can result in a major productivity boost and a calmer work life.

Next, each team should consider the events unique to their work and create logical calendars to match. Marketing teams need to keep content creation, campaign schedules, and ad runs coordinated. Dev and product teams always need to have their release schedule handy. Client-facing teams may need to schedule around their clients’ external schedule of milestones, holiday, and deadlines. IT and service desks will need to keep support professionals informed of planned maintenance and outages. Each team will find they have many calendars and events to keep track of – and they’ll likely do a better job when using Team Calendars versus the invite model imposed by most calendar systems.

PRO TIPS

  • Designate a single calendar as the official organization holiday calendar. Have all other teams add it to the Calendars tab in their spaces. It’s inefficient (and dangerous) to have many different “Acme Co Holiday” calendars! Remember, Team Calendars makes it easy to reuse calendars and combine the calendars into one view! Many organizations choose to have this calendar live in a Human Resources space.
  • If you use Jira to track time-off requests, you can setup Custom Event Types which display these requests from Jira on the calendar to avoid duplicate data entry!
  • Use the Custom Event Types which allow Team Calendars to display live sprints, releases, and more from Jira. Using JQL you can specify exactly what’s displayed on your calendar, automatically updating as Jira changes.
  • If you are working with a client and they can provide an .ics file (usually available as an export option from most calendar services), you can quickly import hundreds of events into a Team Calendar so you can keep tabs on their events.
  • If there’s an existing calendar system you cannot migrate to Team Calendars, you may still be able to display the calendar feed within a Team Calendar. See subscribing to third-party calendars. Examples include Outlook/Exchange, Google, Teamup, Opsgenie, and PagerDuty.

Using Your Calendars

Now that you’ve got calendars setup, you’ll always find them under the Calendars tab within your Confluence space. This tab rolls up all calendars in the space (including calendars linked from other spaces) so you can see holidays, time off, deadlines, and happy hours all in one place. 

But wait! There are additional convenient ways to access your calendars!

  • Embed a calendar into a Confluence page with the Team Calendars macro
  • Link to an existing calendar in another space so that it shows up in your space’s Calendars tab (example: most spaces will likely link to the official corporate holiday calendar)
  • Each Confluence user will see all of the calendars they’ve watched in their My Calendars page
  • Integrate Team Calendars into your personal calendar in Outlook, iPhone, etc. Share these instructions with your users!

MORE TIPS

  • Embed a calendar(s) into your weekly team meeting notes (automate this with a template). Many of our customers have reported dramatically decreased schedule conflicts when the calendar is right there, being reviewed regularly.
  • When viewing calendars in a space’s Calendars tab or all the calendars you’re watching in the My Calendars page, you can temporarily filter out unnecessary event types by unchecking the boxes displayed to the left of the type under its calendar. If you want to hide an entire calendar, click the menu (…) next to a calendar name and choose Hide Events.

Caution

Like all Atlassian tools, it’s easy and intuitive to get started with Team Calendars. Here are some more considerations to make it an even smoother journey.

Calendar Names. A Confluence space’s view permissions are used to determine calendar visibility by default. Team Calendars does not enforce unique calendar names. For admins and others who belong to many Confluence spaces, having 27 calendars all named “PTO” makes it hard to find the correct calendar. We recommend including the space name or key in each calendar name. For example, “PTO - IT Help Desk” and “PTO - Marketing.” 

Beware when deleting custom event types. Deleting a custom event deletes all events assigned that event type. Move events currently categorized under the event type to another event type before deleting.

Migration considerations. Atlassian does not officially support Team Calendars migration but you can export and import each calendar manually to move your calendars. Custom Event Types are great but if you’re migrating to a new environment, make sure you are using the latest version of Team Calendars in both environments, otherwise custom event types may be lost.

Help is here! There’s an entire section of documentation for Team Calendars. If you need Team Calendars licenses (or are looking to migrate to Cloud Premium, which includes Team Calendars), need to migrate your Confluence environment, or need assistance with any part of the Atlassian suite, get in touch with us!

Topics: atlassian blog confluence teams tips project-management confluence-cloud
2 min read

Why Digital Asset Management is Important

By Kye Hittle on May 14, 2021 1:37:00 PM

Blogpost-Display image-May_Why Digital Asset Management is ImportantWe're always looking for ways to keep track of our stuff, from old metal asset tags firmly glued to lids of the first "portable" computers to Apple's recent AirTag product release.

At work we call these "assets" because they cost money to acquire, maintain, replace, and are (hopefully) required for our organization's operation. (If assets are not being used, your digital asset management system should be highlighting that potential savings opportunity!) Keeping track of these items doesn't just make sense from a financial perspective, it's also required by law in many cases.

When it comes to asset management we're not just concerned with an item's current location. Surprisingly often, an asset's purchase price, age, vendor, warranty details, user assignment, support/maintenance contracts, service history, and any of hundreds of other details become critically important to keeping the asset—and therefore our business—running.

And we're not just talking about physical assets like desks, laptops, phones, tablets, tools, networking equipment, etc. The move to cloud means we can instantly deploy servers, licenses, and other IT infrastructure we'll never actually see or touch! How do I put an RFID tag on a cloud server?

With more devices and services being employed to operate our organizations every day, spreadsheets don't cut it. Given this amount of critical data to manage, the only way to keep up is to turn to digital transformation.

Traditional Configuration Management Databases (CMDBs)

The technology market has seen the introduction of many inflexible, expensive "solutions" to manage assets digitally. Traditional Configuration Management Databases (CMDBs) have failed to deliver the necessary transformative power:

  • IT is overpaying hundreds of millions of dollars in unused features in these legacy CMDB tools
  • Customization requires specialized consultants (quickly adapting to the changing needs of the business is a core tenant of digital transformation)
  • Legacy tools often result in slowing down the flow of work across teams instead of enhancing collaboration between them

Praecipio Consulting is transforming organizational service delivery with an Atlassian alternative built to deliver maximum value: Insight, now built into Jira Service Management. It is a modern, flexible digital asset management solution to easily define collaborative asset tracking that best fits your organization's needs, right in Jira.

Atlassian Service Management saves companies money by retiring their legacy tools. This explains why Atlassian is ranked as a strong performer in this market, having a strong strategy, and achieving a rapidly expanding market presence.

From employee and contractor onboarding to incident management to asset intelligence, Atlassian Insight for Jira Service Management can quickly get your digital asset tracking under control and flex to meet your constantly changing business.

Digital asset management done right doesn't just require the best-in-class solution, however. It's a cultural shift in the way IT is delivered as a service. Contact Praecipio Consulting to get started on your service delivery transformation now.

Topics: jira atlassian blog asset-management tips service-management insight digital-transformation jira-service-management
3 min read

Jira Service Management Request Types Best Practices

By Morgan Folsom on May 10, 2021 3:10:00 PM

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

What are Request Types 

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

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

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

What can I do with request types

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

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

Request type best practices

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

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

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

A Carbon Neutral, Nature Positive Praecipio Consulting

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

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

Finding our path

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

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

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

Proforestation

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

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

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

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

Human Health

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

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

Existing projects as of 2021 Q1

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

Praecipios green path-table

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

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

Test Driven Development

By Lauren Schroeder on Apr 28, 2021 11:15:00 AM

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

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

Testing the Feature

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

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

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

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

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

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

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

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

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

Queues vs. Dashboards in Jira Service Management

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

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

What are queues?

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

What are Dashboards?

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

When to use queues vs. Dashboards?

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

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

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

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

Get early access to Atlassian Data Lake for Jira Software

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

Blogpost-display-image_Jira Data Lake Preview

What's a data lake?

Read up on the basics in our explainer.

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

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

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

Compatible BI Tools include:

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

Jira-Data-Lake-preview

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

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

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

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

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

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

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

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

By Robert Davenport on Apr 21, 2021 4:35:00 PM

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

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

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

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

Why Upgrade Your Atlassian Stack?

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

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

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

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

End of Life Policy

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

Security Vulnerabilities

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

Severity Rating System followed by Atlassian:

Atlassian_severity_rating_system

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

Current security advisories can be found here:

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

New Functionality/Capabilities

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

Compatibility with other Server Components

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

Plugin Support

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

Unable to Skip a Platform Release

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

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

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

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

How Do You Manage Releases in Atlassian?

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

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

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

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

Definition of Done versus Definition of Release

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

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

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

Method One: The Release Issue Type

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

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

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

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

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

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

Method Two: Bitbucket Pipelines

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

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

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

Which one is right for you? 

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

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

Can a Product Owner also be a ScrumMaster?

By Morgan Folsom 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 Morgan Folsom 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 Morgan Folsom on Apr 5, 2021 11:47:00 AM

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

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

When do I use a global transition?

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

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

How to configure a global transition

Transition Properties

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

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

Conditions

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

Post Functions

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

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

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

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

  1. A post function that clears resolution

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

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

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

Tracking CSAT through Jira Service Management

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

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

CSAT in Jira Service Management

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

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

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

jira-service-desk-satisfaction-report

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

The Pros of CSAT

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

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

Considerations of CSAT

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

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

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

Should Stories & Bugs Follow Different Workflows?

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

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

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

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

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

I hope this explanation helps you avoid unnecessary workflows!

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

The Impact Installing Apps Can Have on an Atlassian Application

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

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

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

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

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

Getting the Most From Your Jira Service Management Automations

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

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

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

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

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

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

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

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

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

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

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

How Service Management Capabilities Improve Your Organization’s Employee Onboarding

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

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

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

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

Why employee onboarding is a common issue

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

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

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

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

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

Plus, the global pandemic has made employee onboarding more difficult

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

How Service Management helps with employee onboarding

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

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

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

Examples of Service Management at work in employee onboarding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The starting point  

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

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

1. The migration from the local AD to Azure AD 

Username transformation with User Sync

Challenges 

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

Prerequisites 

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

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

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

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

Implementation steps 

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

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

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

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

Replacement: $1 email domain stripping

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

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

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

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

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

Challenges 

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

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

Prerequisites 

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

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

Implementation steps 

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

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

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

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

Stay tuned!

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

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

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

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

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

Strong fences make great neighbors

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

 IMG_4511IMG_4512

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

IMG_4507

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

IMG_4508

Not in my back yard...

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

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

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

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

IMG_4509

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

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

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

What happens if I keep asking why? 

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

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

Actions speak louder than words

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

For me and my puppers, it's simple. 

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

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

BRB, gotta run and get some more fence planks.

IMG_4510

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

Tips for Performing a Successful Root Cause Analysis

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

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

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

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

What is Root Cause Analysis?

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

Root Cause Analysis Blog Post

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

Why Does It Matter?

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

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

How Can I Help My Organization Embrace RCA?

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

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

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

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

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

Three Things No One Tells You About Custom Fields in Jira

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

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

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

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

Response Times for Jira Data Sets

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

2. There are native alternatives to custom fields.

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

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

3. You can proactively manage custom fields.

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

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

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

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

Do testers need to be in sprint planning?

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

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

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

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

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

The objective of Agile/sprints/scrum 

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

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

wCXkvvXwQxlBYxwzr_327Yp6iURV_I96Tp1aH_7sZ_o-nN_WgAHqwLsCGZhKraLYAj96nyay0z6VH3GqeZvv7HdSwF1OCGvp

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

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

Agile has four important values:

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

  2. Working software is more important than comprehensive documentation

  3. Customer collaboration is more vital than contract negotiation

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

Testing in sprint planning: The goal of sprint planning

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

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

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

Why testing should be involved

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

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

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

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

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

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

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

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

Jira Administration: Sys Admin vs Jira Admin vs Project Admin

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

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

Admins

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

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

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

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

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

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

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

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

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

Atlassian Experts, Best Practice

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

Preventative Measures

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

Predictable Cost, Scalable Model

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

Relationships

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Here are some facts:  

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

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

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

A quick overview of Data Center SAML SSO: 

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

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

what-can-data-center-saml-do

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

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

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

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

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

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

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

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

This will give you two workarounds: 

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

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

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

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

Note: No-code transformation options are quite varied. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How to evaluate your answers 

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

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

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

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

As you can see, there are three main possibilities: 

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

Now you know what’s your basic fit.  

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

Continuing your evaluation  

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

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

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

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

spot-the-difference-resolution

What’s Next 

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

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

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

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

How to Handle Delete Permissions in Jira

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

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

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

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

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

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

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

So, to summarize: Delete permissions? Very important.

Types of Delete Permissions

Amongst these permissions are four groups:

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

And two types:

  • Delete Own
  • Delete All

Delete Own Permissions

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

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

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

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

Delete All Permissions

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

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

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

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

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

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

Which Atlassian Cloud Tier is Right for My Organization?

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

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

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

The Four Tiers

Most Atlassian Cloud products* are available in four tiers: 

  • Free
  • Standard
  • Premium
  • Enterprise

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

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

The Free Atlassian Cloud Tier

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

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

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

Standard Versus Premium (and Enterprise)

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

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

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

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

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

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

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

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

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

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

Tips for maintaining a Jira instance

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

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

Marketplace apps

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

Configuration

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

User Management

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

Stale Data

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

Praecipio Consulting's Managed Services

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

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

Should scrum teams track their time?

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

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

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

What is a Story Point?

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

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

Why can't a team estimate in hours? 

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

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

The shoulds and shouldn'ts of tracking time in Scrum

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

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

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

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

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

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

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

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

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

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

Your Help Center will be flooded with password recovery requests.  

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

So, what are you going to do about it? 

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

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

 

Step 1: Take inventory of web applications 

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

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

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

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

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

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

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

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

Step 2: Check which applications support SSO  

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

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

Screen Shot 2020-12-05 at 1.09.30 PM

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

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

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

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

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

Screen Shot 2020-12-05 at 1.09.50 PM

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

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

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

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

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

Screen Shot 2020-12-05 at 1.10.18 PM

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

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

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

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

Screen Shot 2020-12-05 at 1.10.40 PM

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

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

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

Step 4. Analyze IdP opportunities 

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

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

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

Scenario 1: Microsoft Active Directory 

Screen Shot 2020-12-05 at 1.11.24 PM

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

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

Scenario 2: Office 365 

Screen Shot 2020-12-05 at 1.11.47 PM

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

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

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

Scenario 3: GSuite 

  Screen Shot 2020-12-05 at 1.12.11 PM

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

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

Next Steps 

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

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

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

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

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

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

Individuals and Interactions Over Tools Doesn't Mean No Tools

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The password syndrome 

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

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

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

Pain points for users 

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

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

Pain points for security officers 

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

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

Pain points for administrators 

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

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

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

Pain points for Help Desks 

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

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

A single source of truth 

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

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

Topics: blog sign standardize security verify resolution
3 min read

Microaggressions in the Workplace

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

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

What are microaggressions?

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

Three types of microaggressions

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

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

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

Microaggressions and the workplace

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

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

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

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

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

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

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

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

So what do you need to do now?

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

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

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

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

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

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

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

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

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

Topics: atlassian blog plan server licensing
4 min read

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

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

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

What is the Jira Cloud Migration Assistant?

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

At a glance

What can it do?

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

What are the limitations?

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

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

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

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

What about users?

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

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

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

My Experience

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

Further Reading

Topics: jira blog migrations cloud atlassian-products
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 atlassian blog confluence tools
3 min read

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

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

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

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

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

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

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

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

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

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

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

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

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

How is Confluence Cloud different from Server/Datacenter?

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

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

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

Navigation

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

Creating pages

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

Keyboard shortcuts

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

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

 

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

Page layouts

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

Screen Shot 2020-04-17 at 11.24.48 AM

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

Panels

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

Screen Shot 2020-04-17 at 11.28.05 AM

Macros while viewing a page

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

Screen Shot 2020-04-17 at 11.31.30 AM

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

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

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

How Your SaaS Provider Contributes to the Customer Experience

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

Blogpost-display-image_SaaS Requires Delightful Customer Service

SaaS Providers & Customer Service

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

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

pizza as a service

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

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

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

Training

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

Know Your User

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

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

IT Service Management

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

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

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

Metrics of SaaS

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

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

Final thoughts

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

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

Topics: atlassian blog saas cloud hosting customer-experience
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: blog environment do-good green-team social-responsibility education
5 min read

7 Non-Negotiables When Choosing an Atlassian Business Partner

By Praecipio Consulting 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: blog do-good pledge-1% nps atlassian-solution-partner social-justice
4 min read

How to Have a Stress Free Holiday

By Praecipio Consulting 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: blog 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: blog flatwater-foundation do-good pledge-1% global-climate-crisis treefolks green-team
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 blog agents training atlassian-products atlassian-certification-program
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: blog culture do-good social-justice social-responsibility
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

How to know if your organization is ready to scale 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: blog scaled-agile best-practices tips 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 specie