2 min read

Old Is New Again – Conversations Over Documentation

By David Stannard on Jun 18, 2021 11:43:00 AM

2021-q4-blogpost-Old is new again - Conversations over Documentation_1

Imagine a world where businesses can concurrently develop next generation manufacturing processes while designing products based upon the as-yet-non-existent implementation medium. Imagine that they can do this all while reducing time-to-market and allowing the continued benefit of exponential growth in complexity every 18 months. Add a twist of “design-anywhere-build-anywhere” – and serve shaken; not stirred. Perhaps in software, the analogy might be "
develop applications on a language being implemented and SDKs that will also be created concurrently – trust us, it will be fine." At the same time, many graduates from engineering colleges were learning that the soft skills of communication and collaboration had higher impact to their success than the hard earned technical skills.

In the early 1990s, an organization is asked by several of its clients to help them address time-to-market pressures. The result: in 1992 Don Carter published a book founded upon a transformational approach called Concurrent Engineering based on consulting experiences. One impact that I remember well was the increase in actual conversations amongst the various constituents - breaking down the barriers between the silos was a key component of this philosophy. Coincidentally, the quality of results increased too, along with client satisfaction.

Back to the future... Literally!

There is even more pressure on businesses to reduce time-to-market, and there are few signs that this will change or needs to change. No time for creating voluminous documentation in semi-isolation that can't capture all aspects and are often subject to interpretation by the reader. The division between hardware and software development has blurred. In fact, hardware designs are created, modeled, emulated, and the proposed implementations are verified using specialized high level languages prior to implementation. The abstracts are subsequently decomposed into manufacturable entities while continuously confirming no unintended loss of the design intent using specialized tools such as formal verification tools. 

Businesses are and must continue becoming Agile – businesses are greater than having Agile development organizations. So the adoption of Agile, Scrum, and other practices continues unabated. There are even early discussions of what’s beyond these Agile practices that are standing the test of time after several decades of adoption. 

Two important aspects of the Agile Manifesto are valuing “Individuals and interactions over processes and tools” and “Customer collaboration over contract negotiation”. It was increasingly common pre-COVID that these teams were distributed geographically and even culturally. So while tools are a part of the solution – the need to communicate well and often has never been more important. This practice is standing the test of time.

A closing note to Scrum Masters who help teams live the benefit of the cross-functionality objective: Your Scrum teacher and Agile coaches have provided you with lots of reference material about building teams and communications. Now is a good time to revisit those references; one of my favorites is “Crucial Conversations” by Kerry Patterson et al. The book addresses situations with perceived high stakes, diverse constituents, and possibly highly emotions.

Looking for more Scrum tips? Contact us, we love to help!

Topics: scrum collaboration documentation agile software-development
17 min read

Atlassian SSO: Onboarding & Offboarding Contractors (5/5)

By Katie Thomas on Apr 7, 2021 9:45:00 AM

Blogpost-display-image_Resolution Blog Series, Pt. 5-1

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 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 optimization practices security collaboration human-resource sso
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
32 min read

Atlassian SSO: Top 6 Questions to Define Your Scope (3/5)

By Katie Thomas 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: saas security collaboration data-center resolution sso
4 min read

How To Run D&D Campaigns With Trello

By Luis Machado on May 28, 2020 11:07:00 AM

2020 Blogposts_How Jira helps your team work remotely copy 3

It’s 2020, and the reality for a lot of folks has seemingly changed overnight. Working from home, remote meetings, a whole slew of new tools to learn and master. It’s a strange new world, and not just for our professional lives but our personal lives as well. So how do we make the change? How can we adapt to this new frontier?

I’ve been playing games with friends on the internet for several years now, way before social distancing practices became the norm. Even though we live hundreds of miles apart, I can still lead a group of close friends through the dark, dangerous lairs and pitting them against frightening creatures, all for glory and the pursuit of the almighty gold coin. There are a plethora of tools available that allow people to play tabletop games without the table, such as Roll 20, D&D Beyond, Discord, Skype, among several others. But there is a distinct lack of tools available for the person running the game, the game master, the dungeon master, the decider of fates, and facilitator of adventure to keep it all organized.  

When running a game there is A LOT to keep track of: monsters, treasure, characters, towns, plot points. If you’re using an old school pen and paper, you’re going to need a mighty large binder. Naturally, the desire to digitize this content has led to some creative methodologies. The one that has stuck with me is using a site that falls right within my wheelhouse: Trello.

At its core, Trello is a tool that helps you manage lists for collaboration. You create a list and then populate it with cards. The title of the card shows up in the list, clicking on the card lets you see an expanded view with more detail. You can also add custom labels to create color codes.

I first came across this idea from a post on Reddit called "DMing with Trello". This method gives you easy access to a board for the DM (as in Dungeon Master!) screen to have frequently referenced rules and definitions handy, a way for tracking combat, and board for managing campaign-specific content.

Campaign Content

dd1

While I'll breakdown how I manage my campaigns, how you organize your lists can vary. I started with making a list for the town Daggerford, where the players interact with each other. Each special location within the town has is its own Trello card. These locations, like a blacksmith, inn, or tavern can be listed for easy reference and the numbers in my list correspond to locations indicated on a map. The use of the built-in labels lets you categorize cards within a list, and the sorting view lets you filter the list with a specific category. So, if I’m looking for just blacksmiths, for example, I can filter the list for just that category.

dd2

dd3

Clicking on one of the cards brings up a larger, more detailed view where you can keep your notes.

dd4

Cards can also be formatted using markup to let you get as fancy as you want.  You can also extend functionality if you’re using Google Chrome by installing a browser extension: Trello Card Optimizer.

dd5

Combat Tracker

dd6

The combat tracker is a series of lists. The first list is where I set the turn order (top to bottom). Each subsequent list is a round of combat, numbered accordingly, and the players and monsters are all cards. You can arrange them all in turn order and then advance them to the next round when it’s their turn by clicking on them and dragging them to the next list. 

Keeping track of combat can be particularly tricky in an online situation. Using Trello gives you an easy, straightforward way to do it.  In this setting, I use the labels for various statuses and ailments. Poisoned by a snake? Petrified by a basilisk? There’s a label for that! Lastly, I keep a card or two at the top of the initiative list for easy access to the music links I use.

DM Screen

dd7

Last, but not least, is the DM screen. Set up in a similar manner to the campaign content, this board offers you the ability to quickly reference game rules that you frequently have to look up. How does grapple work again? What happens when a character is blinded? All these questions and more can be answered here, and you don’t have to worry about accidentally bending or tearing your rule book between sessions.

The DM screen is available as a public board that you can copy to your own account, allowing you to customize it to suit your game. I highly recommend using the Trello Card Optimizer with Chrome because it adds a lot of visual organization to your cards and board. 

Now get out there (and by "out there", I mean exploring the world of Trello from your home), and take a shot at organizing your game. As a final note, when the time comes to reunite with your players for an in-person session, you can travel light with just a laptop and have all your hard work available at your fingertips.

For more information on Trello and the Atlassian suite of products, reach out to your favorite Dungeon Master...er...Platinum Solutions Partner. Happy gaming!

 

 

Topics: collaboration project-management trello atlassian-products
4 min read

5 Ways to Make a Team Space in Confluence

By Morgan Folsom on Jul 16, 2018 11:00:00 AM

5 Ways to Make a Team Space in Confluence Header ImageWhile creating a space for your team in Confluence may seem like a simple undertaking, creating one that users actually want to interact is far from easy. We know what can happen when you miss the mark: you've got a team space, but it's a mess - nobody knows where to find anything, there's no consistent structure, and nobody actually uses it. It’s not hard for a space to become a documentation black hole - documents enter, never to be seen again.

Confluence is an industry leader due to its revolutionary capabilities. A well implemented Confluence workspace breaks down team silos, is specifically geared for turning conversations between team members into action, centralizes all information in one space, and fosters and encourages a culture of open teamwork.

Here’s the good news: creating a team space doesn’t have to be difficult or time-consuming. With the right structure and out-of-the-box Confluence tools, you can easily create a space for your team that you don't have to bribe them to use.

5 Steps to a Collaborative Confluence Team Space

1. Create a landing page

The first page that you see when you go to your team space needs to be clear and appealing. If the space’s landing page is too cluttered, your user's eyes will glaze over before they get any useful information out of it. On the other hand, if the page is sparse with no useful information, why would they keep going?

For your landing page, you want to include information about the space: this is where you can throw in a bit of basic information about the team and its members, but you ultimately want to focus on what will be useful for your team. Using a Children Display macro on this page can give users a better understanding of where they can find information in the space as a whole. You can determine how many layers to show, and even include excerpts of the pages below. Similarly, you can link to commonly used pages or provide some navigation hints customized to your space. Now that you’ve got users in the space, you want to make the rest of the experience just as clear.

2. Establish a hierarchy

We recommend thinking about setting up the space as people will look at it - what do they see first? The top-level pages - so start there. They could be anything (and everything) from projects or training to team building. You’ll want to make sure you include any information you want your team to know, without flooding them with a ton of first-level pages. 

You can empower users to build this space with you by using the Create from template macro to help enforce your hierarchy. Including the macro on a high-level page allows your team to click a button to create the right page in the right location (if you customize your space templates, these pages can even include the correct macros and labels you need to report on them in other places). Once you've got an idea of how you want the space to be structured, you'll want to address the ever-important content that lives within the space (that's why we're here, isn't it!). 

3. Make it easy to find information

There are several things you can do right off the bat to keep users engaged and ensure they have what they need to do their jobs. Using the space shortcuts on the sidebar can call out commonly used pages - either in Confluence or external pages. Confluence also has some built-in macros that can improve your content with little effort:

Your pages look great, but who do you want to see them?

4. Restrict what you have to

Confluence allows permissions to be set by space and by page. This means you can lock down individual pages that may be more sensitive, and open up the important ones for viewing and/or editing by the team. Be careful not to lock the space down more than you need to - space and page permissions are great for security, but don't let them be a barrier to collaboration.

Once your space is set up, the next step is about keeping it simple.

5. Cut out unnecessary information

Knowing what doesn't belong in your team space is as important as knowing what does. We've all seen the overflowing wikis, filled with personal user notes or docs that have been around longer than you have. Personal spaces in Confluence are there for a reason - users can track information that isn't relevant to the team in their own space, without filling your space with irrelevant information. Archive information that isn't relevant anymore - Confluence pages track when they were last updated, and using the Attachment macro lets you track that for all of your space attachments as well.

Now you're ready to build out an awesome Confluence team space. Say goodbye to documentation black holes and e-mails from your team asking where to find information and hello to easy collaboration!

Still have questions? Let us know.

Topics: confluence teams tips collaboration consulting-services
2 min read

Less Meetings, More Collaboration with Atlassian Tools

By Jill Cloud on Jun 26, 2018 11:00:00 AM

Have you ever been in a meeting and thought, "Why am I even here?" and then started daydreaming or doing other work on your laptop? After meetings that drudge on and on, it's easy to leave them more confused than when you started.

Meetings are the worst! Of course, there are tons of tips on how to run an efficient and productive meeting, but how about being more efficient and productive by NOT scheduling meetings. Skip them! Well, not really. There are situations where a meeting is necessary, but many of our daily meetings are pointless, calendar-eating blocks of time that we will never get back. 

Atlassian tools offer so many different ways to facilitate collaboration without sitting around a table at a specific time of day, requiring people to be engaged. Everyone's workloads are scattered throughout the day, and asking them to align priorities during a very specific block of time is not necessarily the best way to get people to collaborate effectively. Instead, creating a Confluence page focused on a specific topic - providing an outline of the work items that need to be addressed.  'Mentioning' your colleagues with the @mention feature notifies them about changes to the page, and they can collaborate when it works best for them. If a specific approval is needed from management, or if you need a colleague's feedback, you can leave an inline comment, which will notify them of your request or comment. If more discussion is needed, any team member can create a Stride room, that references the Confluence page. This will allow team members to actively collaborate on the topic. The communications can happen at a faster rate, allowing for more depth conversation (without a meeting).

This method will encourage and promote engagement with your remote employees and give them a seat at the table (so to speak). If the topic requires inputs from others not originally part of the conversation, it's easy to add them to the Confluence page or Stride room. They can quickly read the conversation and get up to speed.

Many people have a tendency to conclude meetings with no structured outcomes, deliverables, or expectations of team members. When you are using Confluence as your collaboration tool, it's easy to create tasks directly on the page. Since all Atlassian tools can be very transparent, team members are more accountable for completing the follow-up on time. In this example of a Confluence template for meeting notes, you can quickly add team members to a page, capture goals and discussion items and assign tasks:

Ditch the meetings – let those calendars breath – give people their time back, and do it all while accomplishing more, in less time. 

Topics: atlassian stride collaboration atlassian-products

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

Atlassian-Platinum-Solution-Partner

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us