A question that I'm often asked is: Why have so many different roles on a scrum team? If a developer on a scrum team has the experience to act as the Scrum Master as well, is there any harm in consolidating? Short answer: Yes!

Although having one team member covering multiple roles seems more efficient, it can cause more problems than its worth. Before putting a team member in multiple roles, it's important to consider the following challenges.

Context Switching

Statistics show that it takes an average of 25 minutes to resume a task after being interrupted. Jumping between tasks that require completely different mindsets and skills require a huge context shift. Having a developer who is switching between working on code and managing blockers for the team can actually reduce efficiency. It may be more effective to have a Scrum Master working as a Scrum Master for multiple teams. 

Skills & Training

The skills needed to be a successful Product Owner (PO) are different than those needed to be a Scrum Master, which are different than those that make a good developer! The Scrum Master should have a high level of emotional intelligence and act as a leader for the developers. Developers should be subject matter experts, familiar with the best practices and best ways to implement the PO's requirements.

Conflicts of Interest

The Scrum Team is designed to have certain checks and balances – each role is well defined so that they can focus on the subject matter they are there for. When you start consolidating roles, there's a high risk of conflicts of interests. This is very clear when organizations try to combine PO and Scrum Masters – after all, one of the major jobs of the Scrum Master is to protect the team from scope creep, represented by the PO. Additionally, the Scrum Master unblocks the development team if needed, and helps facilitate the scrum ceremonies – an important part of that requires allowing the team to work through issues before utilizing your authority to pull in outside stakeholders. 

It can be tempting to try and combine your Scrum roles, but we strongly recommend respecting the division of responsibility that has been established. 

If your teams are having trouble with their scrum roles, have any question or just want to chat, contact us, we'd love to help!

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!

About Dashboards and Gadgets

The Jira Dashboards is the first screen you see when you log in to Jira. It can be configured to display many different types of information, depending on your areas of interest.

If you are anywhere else in Jira, you can access your Jira Dashboards view by clicking the ‘Dashboards‘ link in the top left corner of the Jira interface.

The information boxes on the dashboard are called Gadgets: 

If your user account has only one dashboard, the tabs on the left of the browser window will not be available and the dashboard will occupy the full window width.

 

You can easily customise your dashboard by choosing a different layout, adding more gadgets, dragging the gadgets into different positions, and changing the look of individual gadgets.

You can also create more pages for your dashboard, share your pages with other people and choose your favorites pages, as described in Managing Multiple Dashboard Pages. Each page can be configured independently, as per the instructions below.

 See the big list of all Atlassian gadgets for more ideas.

* This gadget will only be available if it has been installed by your Jira administrator.

 

The Firebug add-on for Firefox can significantly degrade the performance of web pages. If Jira is running too slowly (the Jira dashboard, in particular) then we recommend that you disable Firebug. Read this FAQ for instructions.

 

Creating a Dashboard

The dashboard that you see when you first start using Jira is a “default” dashboard that has been configured by your Jira administrator. You cannot edit the default dashboard; but you can easily create your own dashboard, which you can then customize as you wish.

To create your own dashboard:

1. At the top right of the Dashboard, click the ‘Tools‘ menu.
2. Select either ‘Create Dashboard‘ to create a blank dashboard, or ‘Copy Dashboard‘ to create a copy of the dashboard you are currently viewing.

You can now customize your dashboard as follows:

 

If you are using multiple dashboard pages, you can only configure dashboard pages that you own.

 

Choosing a Dashboard Layout

To choose a different layout for your dashboard page (e.g. three columns instead of two):

1. At the top right of the Dashboard, click the ‘Edit Layout‘ link. A selection of layouts will be displayed:
   
2. Click your preferred layout.

Adding a Gadget

1. At the top right of the Dashboard, click the ‘Add Gadget‘ link.
2. A selection of gadgets will be displayed:
   
    Select a category on the left to restrict the list of gadgets on the right to that category.
3. Click the ‘Add it now‘ button beneath your chosen gadget.
4. Click the ‘Finished‘ button to return to your Dashboard.
5. If the gadget you have selected requires configuration, you will be presented with the gadget’s configuration page. Configure appropriately and click ‘Save‘.

Moving a Gadget

To move a gadget to a different position on your dashboard:

• Click the gadget and drag it into its new position.

Removing a Gadget

To remove a gadget from your dashboard:

1. Hold your mouse over the top right corner of the gadget, until a down-arrow appears.
2. Click the down-arrow to display the following menu:       
   
3. Click ‘Delete‘.

Need some more help navigating Jira Dashboards? Learn more about Jira here, or contact our team of experts and we’ll answer any questions you may have.

The Cost of Quality (COQ) business model describes a method of increasing profits without increasing revenues.

Here’s how it works: COQ increases profit by shrinking business costs. If your business has a 5% profit margin, for example – and you decrease costs by 5% – you’ve doubled your profits. That’s simple enough, but how do you decrease costs?

COQ identifies the importance of shrinking costs without taking the usual cost-cutting measures like not buying everyone’s favorite pens or not stocking refreshments in the break room — the “let’s avoid morale buzz-kills to save a few bucks” approach to increasing profit. Instead, COQ promotes lessening mistakes and increasing business process efficiency.

Companies adopt and tweak COQ to reflect their business goals and in turn their profitability. The model applies to not-for-profit businesses too: budgets are tight; grants, revenues, or contributions may not increase, but the same valuable services need to be delivered with less and less money, right?

COQ is made up of three elements: conformance costs, non-conformance costs, and opportunity costs. We’ll explain these before we explain the rest of what the graphic illustrates:

Conformance Costs

Non-Conformance Costs

Opportunity Costs

Notice these three cost categories are not associated with the cost of producing the output. Materials needed to assemble a product (labor, supplies, etc) are not included. The three elements merely reflect the costs associated with the business process. As we always say, “the profit’s in the process.” The efficiency of your business processes determines your efficiency as a business. If you’re going to maximize your efficiency and profitability, you need a sound understanding of the cost of quality.

Think about it: process is where value is added and where profit is made. Consumers don’t squeeze oranges to make juice anymore. Okay, maybe on rare occasion, but who cuts down trees and processes timber as a raw material to make paper?

The cost of quality is associated with the cost incurred to ensure process outputs (products and services) meet customer requirements. For example, let’s say Company A manufactures pens, a process that takes ten steps to complete. About half of the time, the process works effectively, and high-quality pens are made. The other half of the time, however, is plagued by faulty manufacturing— lackluster execution in the assembly process. As a result, Company A has to keep half of its pens in its shop for a bit longer for fixing/repairing, incurring non-conformance costs. This leads to a lack of consistency. Ultimately, this waste is passed onto the customer with an increased price per unit and/or inferior product— making it more and more difficult to compete.

That’s why COQ’s biggest cost adjustment occurs in reducing non-conformance costs— tightening the process and ensuring customer requirements are met. This may require spending extra money to do some work over again.

Now, to run through the graphic:

• Conformance costs are important and help ensure a business’ success and stability. when optimizing your business, conformance costs should stay the same or in many cases increase.
• Non-conformance costs, as we’ve mentioned, need to drop significantly— though you can never expect to be without them, strive to get rid of them.
• Opportunity cost is the value of the next best choice. It’s the “what could have been.” If a business is suffering from non-conformance costs, the “what could have been,” is higher in the left portion of the graphic, where non-conformance costs are much higher. If a business is succeeding financially, there is little “what could have been,” therefore reducing the opportunity cost.
• Operating costs are constant. They’re the costs of a business’ building, utilities, licenses, etc— which fluctuate, but not enough to factor into this model.
• Profit looks like this: $$$. Reducing non-conformance generates more $$$.

So, how do you reduce non-conformance? Remember: the $$$’s are in the process.

Would you like more from us? Contact us here.