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. 

DIY 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.

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

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. 

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.

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.

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

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

The Four Tiers

Most Atlassian Cloud products* are available in four tiers: 

• Free
• Standard
• Premium
• Enterprise

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

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

The Free Atlassian Cloud Tier

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

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

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

Standard Versus Premium (and Enterprise)

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

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

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

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

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

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

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

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

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

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

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

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

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

What is Advanced Roadmaps for Jira? 

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

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

Scope: Where is the work being tracked in Jira? 

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

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

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

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

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

Time: When will it be done?

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

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

Dependencies and Scenarios

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

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

Want to know more? 

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

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. 

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

Your Agile and Digital Transformation Journey

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

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

Advanced Roadmaps for Jira (formerly Portfolio for Jira)

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

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

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

Jira Align

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

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

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

Which one is right for my organization? 

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

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

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

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

What is a next-gen project? 

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

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

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

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

The benefits of a next-gen project

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

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

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

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

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

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

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

The disadvantages of a next-gen project

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

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

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

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

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

Are next-gen projects right for you? 

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

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

Iterative Development of Complex Systems

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

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

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

Scrum versus Kanban Agile

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

Scrum

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

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

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

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

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

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

Kanban

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

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

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

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

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

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

So what?

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

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

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

Hopefully, you've followed my posts and webinars on Portfolio for Jira, as well as how to manage Lean Budgets in Atlassian and its ecosystem. We released a White Paper providing a solution for mid-sized organizations that have embraced SAFe® and want to also incorporate Lean Budgets concepts within the Atlassian technology stack. After all, one of the most critical pieces of adopting an agile mindset is to break the cycle of traditional Project Cost Accounting. 

Project Cost Accounting and agile frameworks (regardless of the flavor) are in direct conflict with one another. Moving teams to work in a Project Cost Accounting model does not work in agile frameworks. Instead, we move work to teams. When we scale agile, regardless of the model, all we're doing is connecting the overarching strategic initiatives to execution. Also, we're all still trying to figure out how to understand the costs associated with the work. SAFe® offers the seductive allure of Lean Budgets. Simply define the Enterprise budget and allocate it to the Portfolios to do what they will. Wait, what? Just hand over $100,000,000 to a Portfolio for the year and trust that they'll make the right decisions? As Yogi Berra once said, "In theory, there's no difference between theory and practice. In practice, there is." 

Lean Budgets Guardrails

While the Atlassian tools and ecosystem are not intended to be the financial system of record for any organization, one key part of Lean Budgets, which is called out several times in the Lean Portfolio Management competency in SAFe® 5.0, is to provide Guardrails. The four Guardrails are as follows: 

1. Guiding investments by horizon
2. Applying capacity allocation to optimize value and solution integrity
3. Approving significant initiatives
4. Continuous Business Owner engagement

© Scaled Agile, Inc.

The Atlassian tools, and specifically Jira Align, are uniquely positioned to provide the Guardrails for Lean Budgets. By adhering to the SAFe® Core Values of Transparency and Program Execution, Jira Align provides complete aggregation from the corporate strategy, including Mission, Vision, and Values, all the way through team-level execution and back up again. This includes Allocation, Estimate, and Actual comparisons based on the Program Increment. Mind-blowing, right? 

While you will have to wait for the full solution (details are coming soon), here are a few tips to assist you in your journey. 

Create a Strategic Snapshot

Your organization has a well-established Mission, Vision, and Values. They're likely plastered all over your organization's intranet or when in an office, you'll find them displayed every 25 feet down the halls. Add these into the Enterprise Room in a strategic snapshot that aligns with your fiscal year. Break down the Mission, Vision, and Values into long-term, annual goals and establish your Strategic Themes. Add those into Jira Align to start tying execution to these items.

Themes are an entity in Jira Align. Think of them as an Issue Type that drives the rest of the hierarchy. However, one of the key strengths of Jira Align is ensuring, at every level, the entity is tied to execution. In SAFe® the key execution entity is the Program Increment (PI). Even if a Theme straddles several PIs, you must commit to the timebox of the PI. This drives the entire organization to say, "This thing is important to us, and this is how and when we plan on executing it." While at first, you may have no idea, you can always go back and add the information after the fact. 

Determine Theme Allocation for the PI

While you may not know the exact dollar amount while planning the budget, you've likely done the SWAG for the fiscal year. SWAG, of course, stands for Scientific Wild Ass Guess. As you're determining your Themes and Portfolio Epics for the Fiscal Year (or just your Themes), you will likely have a high-level idea of how much of the pie you will allocate to each Theme. Since they are also ranked by highest to lowest priority, the allocations should follow suit as well. If a Theme is ranked number one, it should have a higher percentage allocated than, say, Theme number 10. Theme allocations can be updated as your organization moves through the budget cycle. Jira Align will do the calculation for you as you determine the overall budget. 

However, to truly succeed at Lean Budgets in Jira Align, you must determine the budget for the PI. Again, as you're working through your organization's budget cycle, you can start with your SWAG. For example, if you have an overall budget of $100,000,000 for the fiscal year and your PI cadence puts you at 12-week PIs, then allocate $25,000,000 per PI to start. By tagging your Themes with the PI(s), you can start to understand the dollars, as well as the overall level of effort, needed for a specific PI. As you get closer to final budget approval, continue to refine these numbers. 

Determine a Blended Rate

While I've proposed a series of different methods for translating Story Points to dollars either via Cost Per Story Point or Total Cost of Solution or Monetized Opportunity Cost, the fact remains that we live in a time-based world (sigh). And our best method for translation still comes from determining a Blended Rate. In Jira Align, once you've determined the Blended Rate for the PI, you simply enter it into a field and the magic starts to happen. But how do we determine a Blended Rate? 

Remember, a fixed Team equals a fixed cost. Take the combined salary of the team members, divide it by workweeks, then divide it by work hours. You can skip a step if you remember the exact number of working hours are in a year, but that number will vary based on your geolocation. You can always adjust as needed based on PTO policies and holidays to determine the Blended Rate. From there, Jira Align takes over once you're in execution mode. 

Budget, Estimate, and Actual

In the Portfolio section of Jira Align, you can quickly access a report called Investment versus Actuals. Wait, what? It's that simple? I click a button, and I can compare plan, actual, and variance? That can't be right. 

To be honest, it truly is that simple. However, if Teams aren't fostering good data in Jira Software and if RTEs, Program Owners, Epic Owners, and the like, aren't making the connections in Jira Align, you will end up with junk. This leads to frustration, as well as low adoption levels of the solution. Take a deep breath, and remember Principle #1 of SAFe ®: Take an economic view. Just like any other tools your organization uses, you must adhere to the process and commit to the facilitation of that process within the tools. 

Based on the historical Velocity of the individual Teams in a Program, the Blended Rate, the Teams' Burn Hours, and the Theme Allocation, Jira Align will calculate the Estimate (original estimate at the start of the Program Increment) as well as the Actual (actual completed stories in each of the Sprints). This is where the Team discipline comes in. If Teams do not estimate work, move cards across the board, and close Sprints, this fails. You cannot calculate the roll-up, or if you do, it's wildly inaccurate. Thus, the comparisons are out of whack, and when compared against the financial system of record, you find that you've spent your time and money on Theme number 10 instead of Theme number one. 

Want to know more? 

In the coming days, Praecipio Consulting will release a White Paper detailing the solution to managing Lean Budgets with Jira Align. We look forward to your questions and feedback. Lean Budgets is still an emerging concept, and while we have a solid solution, we'd love to know how your organization is currently managing or where you are in your digital transformation journey with the Atlassian tools.

Given the outbreak of the novel Coronavirus and the need for people to practice social distancing, people around the world have found themselves working, teaching and learning from home. Working remotely has its benefits, but adjusting to this environment has its challenges. 

When I started with Praecipio Consulting in 2013, I was the second remote employee for the company. Seven years later, we've grown significantly and while many of my colleagues are in Austin, a significant number of people work remotely from cities like Houston, Atlanta, Indianapolis, Vermont, and San Jose, to name a few. Even as a remote-work-friendly company, we are are still able to support all of our clients, even our largest ones with 24/7 operations and people distributed across the globe. 

In October of 2019, Praecipio Consulting went 100% remote, which was in large part due to our efforts to become carbon neutral by the end of 2020. Previous to this, we had Work from Home Thursdays, where we set a few clear expectations: 

• Be online and available from 9 am to 5 pm Central
• Your calendar must be up-to-date
• Camera must be on for all internal meetings
• Be mindful of meeting start/end times
• Use Slack or Zoom for 1:1 or impromptu meetings

The habits we built during that time positioned us to become entirely remote and prepared us for the world's current events.  Below is an excerpt from our internal Confluence instance, where we manage all policy documentation and communication. 

Best Practices for Working from Home

When working in an office, the routine of waking up, getting ready, commuting, etc., can start your day on the right foot. Even though we had Work from Home Thursdays, it became a lot more difficult to work from home every day. There are distractions: other people, pets, chores, solicitors. Here are some best practices that will help you transition from office culture to working remotely: 

1. Establish a routine and stick with it

You've likely established a routine when going to the office or even to visit a client site every day. Now that you're working from home, it's easy to slip into bad habits. We joke about wearing a robe to work or forgetting to put on pants. However, this is a real thing. Working from home is a 10,000-hour skill; it takes some time to master.

• Maintain your morning routine
  
  • Having a "commute" is helpful and gets your body moving. For some folks, it's taking kids to school or walking a pet. For others it might be going to the gym or for a run.
  • Hygiene is important. If you typically bathe before work in the morning, continue to do so. Answering that email first thing in the morning while you are still in your pajamas can quickly lead to a day's worth of work without you realizing it.
• Wear "normal" clothes
  • If you wouldn't wear it in the office, don't wear it when you're "at work".
• Set your end-of-day time and turn notifications off
  • Set Do Not Disturb or close the lid on your Mac.
  • Set Office Hours on your Google Calendar.
  • Snooze notifications in Slack.
• Set a lunchtime
  • Inform others by blocking it on your calendar.
  • Keep diverse snack/lunch options in your fridge and pantry.
  • If you don't cook (or don't know how), reach out to others for ideas.

2. Create a designated space to call "your office" 

This space should be all yours. Communicating the use of the space to anyone living with you is critical as well. If you're in "your office", other people should respect that space. At the same time, be respectful about working in your space too. Make sure you can keep background noise down so that you can focus when you're working. Either way, communicate clearly what your workspace is and stick to it. 

• Designate an entire room, if possible, or area of your house as your workspace. 
• Invest in a quality desk and office chair.
• Make sure that space is de-cluttered.
• Focus on ergonomics, not style.
• Try not to eat breakfast/lunch in your assigned work area.

3. Minimize distractions, stay focused on work and breaks

Distractions don't disappear when you're working from home instead of the office. Resist the urge to do things you wouldn't do at the office like watch TV, interact with social media, visit with your roommate or neighbors, or work from bed. It's important to practice self-discipline to stay focused on the task at hand and know when to take a break. Carve out parts of your day between tasks or meetings to stretch and to tend to things around the house like your pet, laundry, tidying up, or cooking.

• Minimize distractions like TV, social media, and those in your remote work environment.
• Schedule time for everyday tasks.
• Set a reminder to stretch regularly.

4. Set up a physical barrier between you and "your office"

It's important to have a physical barrier between your work space and your home space. At the beginning of the day, you should be ready to start, and at the end of the day, you will need to be "done." A physical barrier will help separate work and home life. 

• Have a separate room or privacy screen.
• Close your laptop.
• Close the door.

5. Switch it up every once in a while 

Once you've established your routine, make some small changes. Working remotely can be extremely isolating, and there are some weeks when you'll realize you haven't left your home all week or interacted with another human. While we are all currently practicing social distancing and only leaving our homes for the essentials, be sure you don't completely isolate yourselves. Take advantage of the technology available to virtually interact with colleagues and friends. 

• Schedule a "virtual" lunch date or happy hour with a colleague or friend.
• Make time for exercise at home and block it off in your calendar. 
• Take a walk around your neighborhood or complex with your dog or just yourself.
• Listen to a podcast during the time you set aside to tidy up or tend to your home. 
  
  

For those working from home for the first time, we hope this will be helpful in the coming weeks. And for company leaders, we encourage you to use this time to explore the opportunities of technology and the benefits of working remotely. 

Other helpful resources

• https://doist.com/blog/remote-career-advice/
• https://www.themuse.com/advice/do-you-have-what-it-takes-to-work-from-home
• https://blog.hubspot.com/marketing/productivity-tips-working-from-home

When I was growing up, my parents taught me all kinds of useful skills. By age 12, I helped my dad build my lofted bed. Routers, saws, drills, clamps, hammers: you name it; we used it. At age 19, I rebuilt a 1968 El Camino from the ground up. Everything from tearing down an engine to rebuilding suspension to (somewhat terrible) electrical. Even today, if you've read some of my other blogs, I've installed floors, rebuilt our fence, and completed other small home improvement projects throughout our home. Since a young age, I have constantly been learning new skills and putting them into practice.

At Praecipio Consulting, we help organizations streamline their processes and drive business with the most powerful digital transformation tools, yet their end-users struggle day-to-day with how to use them the right way. After all, you can give the worst carpenter the best hammer, but it doesn't mean they can build a chair.

Employee Learning as a Business Pillar

We've worked with clients of all sizes to implement the Atlassian tools as part of their digital business transformation. Our clients are always pleased with the results (lifetime Net Promoter Score of 70), and the subject matter experts we work with daily walk away with a deep understanding of the processes that the Atlassian tools facilitate. We always recommend expanding that knowledge beyond our champions to end-users and managers alike via training and training programs. While there are a lot of statistics regarding Return on Investment (ROI) for training, instead, we should focus on the learning and development of our employees as a pillar of our business. 

According to this article in Training Magazine, measuring ROI is not enough. Instead, we need to look at five key areas when evaluating the effectiveness of your learning approach: 

• Individual performance
• Time to effectiveness/productivity
• Employee engagement
• Ability to respond to market conditions
• Voluntary turnover

The authors go on to say that learning is not a static exercise. Employees should continuously learn throughout the digital transformation process. The article also mentions that learning and development should be strategically aligned with the business, yet only 40% of organizations surveyed stated that their learning strategy is well-defined. We see this with our clients as well: they take time to implement the Atlassian tools to facilitate industry best practices, however, they can't afford to take the time to teach their people how to properly use them. Implementing and using these tools are tied to overall business objectives, and there should be a clear learning strategy for educating your people about them. 

Learning outcomes and measuring success

As we move to remote work, we must first look at where we were. In-person courses were generally considered the most effective. Why? Because of the interaction with the instructor and the accountability of being in a room with your peers. I have served as an Atlassian instructor since 2015, so I have seen a breadth of engagement in my classrooms. Generally, I received high marks for the content and depth-of-subject knowledge. How do I know? Because we ask. At the end of each course delivery (whether it's at a conference, such as Summit, or a private course for an organization), we provide surveys as well as retrospectives to our clients. The surveys are for attendees to provide feedback, and the retrospective reviews the entire process of obtaining the training, from scheduling to logistics and delivery.  

If the organization releases an on-demand training, what is considered a success? First, the organization should ask what the intended outcome is. Learning outcomes depend on the "why" we've provided this training. For example:

• Is it compliance/security regulated?
• Is it mechanical (I can do) or do we explain why?
• Is it tied to a strategic outcome? 
• Is it tied to organizational change?

Each of these learning outcomes are measured differently. One client organization required every employee and contractor to complete annual compliance training. They revoked access to their systems if not completed within the expected timeframe. Success was measured at 100% completion within 30 days of your start date and every year thereafter by the end of January. This is a binary measurement, however. Did you complete it? Yes or no. 

When looking at other learning outcomes, success becomes less black-and-white. Many organizations are tying agile and agile-at-scale training to strategic outcomes and organizational change. The strategic outcome could be the number of departments or programs that have moved to agile. This is measured by the number and type of certifications held by employees. This is still binary: are you certified? Yes or no. Again, this metric does nothing to evaluate the overall effectiveness of the training or certification as it relates to the organization and general business strategy. 

The Kirkpatrick Model provides both the foundation as well as the "new world" evaluation for the effectiveness of training. While this methodology has been around since the 1950s, it is still relevant today. As with any model or framework, it's the application of these items that become an indicator of success. 

Organic versus formal learning

At Praecipio Consulting, we encourage our consultants to seek additional learning. Certifications are an option, but we also encourage Udemy courses, continuing education courses at colleges and universities, and networking or professional groups. We organize a monthly Skills Exchange for all members of the company, and we have weekly meetings to discuss what we learned the week before. But outside of these formal discussions and learning exchanges is the day-to-day interactions of our people that result in organic learning.

For internal communication, we use Slack. We have dedicated channels based on topics as well as client delivery efforts. No topic is off the table: everything from troubleshooting a problem to a specific function in the tools. If someone needs more dedicated help, we hop on a call to solve the problem. No one of us is as good as all of us together.

What is even more amazing (and I fully credit our people for this) is how much we learn from each other. Because we can teach one another, this reinforces what each of us has learned in the products. Moreover, when we consult and advise our clients, they learn best practices as well as tips and tricks to impart on their peers. Learning does not have to be formal: simply talking through a topic with a peer can teach both people. Providing a solid foundation, however, is where training courses can benefit everyone.

Distance learning and student engagement

While many of us may be working from home for the first time, many a company is scrambling for alternate ways to engage in training. Learning management systems are a great way to provide training content, but as stated before, are these systems delivering the right outcome based on the "why"? Are students actually engaging with the content or are they just checking off a box after completion?

If you can't bring an instructor to your people, bring the people to your instructor. Virtual Training is a great way to provide knowledge and guidance to your people. Praecipio Consulting instructors are live and on camera. They walk through the content and manage questions and discussions through virtual platforms. Hands-on exercises and guided demos provide students with a greater depth of understanding of the Atlassian tools and ecosystem. Other benefits include: 

• Cloud and Data Center/Server options
• Audience-specific courses
• Options to license a recorded session for internal distribution
• Custom training program development and delivery

Engaged employees equal business success

Overall, your organization must embrace employee training. While the Atlassian tools can facilitate your digital business transformation, your employees need guidance when it comes to working within them. Make the time to provide access to quality instruction and training content on the Atlassian products. And it doesn't have to be delivered in-person to be considered quality; virtual delivery is just as effective, and now is a great time to explore remote training opportunities. Reach out to us to discuss training options for virtual delivery. 

Student Diversity is Key for Learning

Over the last two years, I've had the pleasure of partnering with Atlassian University to provide a wide range of training, including in-person courses, virtual courses, and even being the voice of Planning with Portfolio for Jira. If I had to count, I've likely delivered training to close to 1000 students since 2017 as an Atlassian Certified Instructor, but this week was a first – one of my students was blind. 

When teaching an Atlassian University course, we provide students with access to a virtual environment to practice the concepts presented. Each student is also provided soft copies of the slides as well as a lab workbook to guide them step-by-step through the environment. This particular course, Confluence Server Essentials, provides new users the opportunity to learn about the basics of Confluence. Navigation, page creation, blueprint usage, and collaboration features such as @ mentions, comments, and blogs are all covered in the full-day course. 

My blind student had a laptop with accessibility features and used the Jaws Screen Reader to help navigate the different UIs of the applications. He also had a colleague to assist him if needed. As I started the course, he was attentive and eagerly participated in the discussions. However, when it was time for everyone to log in to their environments and start the first set of exercises, I noticed that he was starting to fall behind. 

During the exercises, his assistant had a technical issue with her own laptop and asked if I would step in while she talked to tech support. I sat down and watched as he tried to navigate his screen reader through the Confluence System Dashboard and eventually to the correct Space to continue through the lab. This was my first time working with a screen reader, and I spent quite a bit of time wondering how it chose which parts of the screen to read. However, once we got into a rhythm, I was able to help him navigate to the correct menu. By the end of the time box, we managed to complete two of the four exercises. 

Accessibility in Atlassian Products

Atlassian supports or partially supports accessibility requirements for Jira, Confluence, and Bitbucket Server and Data Center products, in compliance with Section 508 and WCAG 2.0 (AA). At Praecipio Consulting, we developed a custom accessibility app for Jira, at a client's request, to accommodate sighted and non-sighted users. While support and partial support of accessibility are steps in the right direction, I still needed to find a better way to help this student. 

Enter the Atlassian Marketplace. If the functionality doesn't exist in the products themselves, we search the Marketplace for apps to add on to the instance. There are over 2000 apps available for Server, almost 1000 for Cloud, and nearly 700 for Data Center instances of the Atlassian applications, and these apps are generally tagged with additional information to further help you make the right choice. Through a quick search of all compatible apps tagged as Supported, I found two that looked promising: Accessibility for Confluence and Unstoppable for Confluence. Not knowing which one would work best, I tossed a coin. 

Because the Atlassian University lab environments work like a mini Server environment, they function the same as the customer instances of Confluence we work in every day. Following best practices, I wanted to test the installation of the app in a separate environment before installing it for the student. In my Instructor Environment, I found the user with the most administrative rights (as per the lab workbook) and installed the app. A quick check of the documentation told me the additional installation steps needed to activate it. As testing is important as well, I validated functionality myself first, and I was confident this app would provide the student with a better learning experience. 

A Retrospective on the Accessible Experience

Once installed and configured, my student was able to continue forward with the next two labs, including all exercises. Through exercises like creating a blog post, editing a page, and adding attachments, he was starting to understand how Confluence could help him with his daily tasks.

What did we do well?

• Found an accessibility app and installed it
• Walked the student through how to use it
• Provided 1:1 instruction during labs to ensure understanding

What could we have done better? 

• Communicated about the student before class
• Researched screen readers to understand the best one
• Asked the students for a solution

Going forward, I want to identify students with accessibility needs beforehand, so that I can prepare accommodations as needed. While I have thought about this as an instructor before, now that I've had the experience and have learned from it, I am better prepared to provide a better learning experience for all of my students moving forward.

We can all do great things if we communicate ahead of time. If you or your organization have accessibility needs, let us know! We can bring solutions and custom solutions as needed. 

New phone, who dis?

On a random Sunday, my husband surprised me by forcing me into the AT&T Store. You see, I had recently been struggling with my phone recently and although it was still a great phone, it just wasn't as fast as I needed it to be. My Bluetooth was sketchy at best, I had to use headphones or the speaker for phone calls, and my battery life meant I carried a backup battery everywhere. At almost four years old, I was carrying a dinosaur. I picked out my new iPhone Xs Max and started the data transfer process.

"Would you like a case?" 

Of course, I want a case. My shiny new toy needs to be protected from my own idiocy of sleeping with it, shoving it in my back pocket, throwing it on my car seat, stuffing it in my purse, and all the other things I do with my phone (read: play games while in the bathroom. You do it too. Don't judge). 

I like clear cases. After all, Apple didn't spend its resources thinking about the aesthetics of these devices for nothing. And while I want my precious..er..phone to be protected, I also want to showcase its beauty. I pulled two clear cases off the wall, debated for all of 10 seconds and made my choice: a Pelican Marine case that promises "total protection from the elements". Fancy. 

User Acceptance Testing

It took two days for me to put the case on my phone. Why? User Acceptance Testing (UAT). 

Yup. Those are the instructions for installing my case.

"Attention: this is the best way to do this and, by the way, we need you to test this before installing your phone."

Wait...what?

"Put a piece of tissue in the case and submerge it in water for 30 minutes."

Um...okay. 

In case you're wondering, my case passed the test. I could move forward with the rest of the installation steps. But for me, this triggered a thought about User Acceptance Testing. 

Whenever we work with clients, we expect them to engage in User Acceptance Testing. We've spent a lot of time together implementing a solution that fits your needs and requirements. While we provide role-based test cases, it's up to you and your testing team to make sure the tools and solution match. Without this, the go-live for the solution will fail. According to The Standish Group's CHAOS report, user involvement is either number one or number two factor in successful, challenged, or failed projects. Considering we spend approximately $250 Billion on IT application development projects in the United States, wouldn't we want to engage our users early and often? 

Agile as a Feedback Mechanism

The CHAOS report includes comparisons between Agile and Waterfall frameworks and methodologies. However, the critical thing to remember is it's not HOW you implement a project, but whether or not you involve your users. Scott Ambler and Associates makes this comparison using the Cost of Change curve. While the Cost of Change curve is used to advocate using Agile, the message is clear regardless of framework. Early and active stakeholders lead to fewer defect costs because of the shortened feedback cycle. Users gotta use so we can make adjustments. 

This is what we forget about Agile. After all in the Agile Manifesto, two of the four points emphasize the people side of how we develop technology. We are supposed to value people over process and customer collaboration over contract negotiation. I have to ask, then, when was the last time you and your team held a stakeholder demo? Or created a focus group? Or at least bounced an idea off a mentor? This is where many organizations fail at agile: we're afraid to engage our users early for feedback. As a result, 50% of IT projects fail. And while the failure rate is dropping, I have to challenge whether it's because we're getting better at feedback or whether we're getting better at manipulating data. 

Test Plan: User, Customer, Stakeholder

Your audience is critical as are their roles. To solicit feedback early and often, you must place yourself in the role of the user, customer, or stakeholder. We've moved away from calling them User Stories to just Stories. However, the user profiles of these roles are critical to the creation of a good story. Who's the audience? What do they really want?

I like to think of the use case of my Pelican phone case. As a frequent traveler, I want the maximum protection for my phone for whatever I'm doing. I should be confident that it provides me impact, water, dust, and "being stupid" protection. I should also expect it to be lightweight, but aesthetically pleasing. In order to fulfill my requirements and acceptance criteria, what should my involvement be when I'm finally ready to use it? Is asking me to do a single, 30-minute test too much? At the price point of both the phone and the case, should I not be eager to be part of the testing process to make sure I have the highest quality product? I think this is a great way to validate whether or not the user gets what they wanted. And while my test was successful, there were clear instructions as to what to do if the test failed. 

Defining not only what you're intending to deliver, but to whom makes us better able to deliver the right thing with the right quality. Users gotta use. 

Lessons Learned: Users gotta use

No matter how cool or innovative or disruptive, if users don't use, we've failed. Complicated technology implementations or clunky user experiences or missing a key demographic are all failures. For as much as you expect to "fail fast", do you actually solicit the feedback needed early and often to adjust? I, for one, would love to see the failure statistics for my new phone case. My brain is putting together a Pareto chart of root causes as I type this. However, I also would like to see the number of users that didn't engage in the testing steps. After all, functional testing and user involvement is only as effective as the users that use. 

What do you think you can do better to engage the various roles of your users? And remember, it's not just tools and technology, it's the processes that support these as well. Want to learn how Praecipio Consulting outlines the importance of UAT in a migration? Watch our on demand webinar, Plan Your Jira Server to Cloud Migration. 

This year, my husband and I decided to FINALLY spend some money on the house. We started our conversation about home improvement at the end of 2018, thinking about “the list”: need, want, nice to have. We went through the exercise of writing separate lists to compare and prioritize. Quite frankly, I was surprised at how similar they were. We quickly realized there was a need to actually organize and prioritize instead of working on notebook paper, fridge magnets, and the occasional sticky note.

Trello vs Jira Software Cloud

When we were planning our wedding in 2015, we used Jira Software Cloud. We had a Kanban Board with tasks and actions. My husband, while enjoying the fact we had a list we could access from anywhere, struggled to actually transition the cards through the workflow. With my travel schedule what it was before we got married, I was constantly calling and texting because there were no updates on the Board. He especially hated the WIP limit I added to the In Progress column. He called it the "stop nagging me" column. In the end, it wasn't too terrible. It gave us a chance to talk about each others' annoying habits: my constant need for status updates and his inability to ever finish anything (wink). While it made our marriage stronger, it also taught both of us we needed something a little more lightweight to manage our home. 

This time, we’re using Trello. We have fewer cards and use checklists to manage the work. We still have a backlog, but it's concise and doesn't scare my husband with all the agile terminology. 

New Back Door with Dog Door? Check. New Ceiling Fan. Check. New Floors? Hmm...we have to research those. Floors can get pricey pretty quickly. While our budget wasn't tiny and we decided to install them ourselves, there are always hidden costs. We added a research column with a few requirements: budget, material choice, finish, and installation method (floating or glue-down). We finalized the budget and away we went. We chose a dark finish engineered bamboo (heh. get it?) and determined we could afford to do the whole house minus the wet areas (Kitchen, Master Bath, and Spare Bathroom). Several monies, a week for delivery, and a week to let the floors acclimate, we were ready to build. 

Bamboo* as the Foundation

*Not the treelike grasses of the family Poaceae. But working with Atlassian Bamboo during my day job got me thinking about continuous integration and continuous delivery while we laid down our floors. My husband and I created the project and plan. Our project name: Floors. Our Plan: LDHB (Living Room, Den, Hallway, Bedrooms). Our repository was the 90 boxes of floors stacked pallet-style. Our repository was centralized so we can both pull from the materials as needed. Our trigger for our build: moisture barrier and underlayment installed. 

The real fun was determining the Tasks. This was my first floor. While I understood the fundamentals, I needed some guidance to make sure I laid them down correctly. While he tackled the large areas, I was solely responsible for the Master Bedroom. My husband, who has laid over a dozen floors over the last few years, gave me the tasks:

• Start in the corner of the longest wall
• Insert spacer at the end of the board next to the wall
• Insert two spacers for each board down the wall
• Stop both tasks once close to the end of the wall

Pretty simple. However, my first floor required feedback. To be honest, I failed my first build based on feedback from my husband. I kept running the tasks without stopping for cuts at the end of each row. I had to remove some of my work, adjust, and rework the tasks: 

• Start in the corner of the longest wall
• Insert spacer at the end of the board next to the wall
• Insert two spacers for each board down the wall
• Stop both tasks once close to the end of the wall
• Measure for cut piece
• Cut piece
• Install cut piece
• Grab additional boards

While it took me a little longer to get it right, the results are pretty spectacular. I was surprised at how easy it was to get into a rhythm. Once I had the right tasks, I could repeat the build relatively quickly and solicit feedback less often as I made fewer mistakes. 

Home Improvement Retrospective

Once we finished the floors, it was time for a retrospective. After all, we both learned new skills whether they were physical skills or communication skills. And you can't have Home Improvement without the Improvement. 

What did we do well?

• Coordinated the Jobs and Tasks to make sure work was divided
• Clear responsibilities as to who can and should do what
• More experienced teammates provided good feedback for less experienced teammates

What could we have done better?

• More cleaning ahead of the start date (SO MUCH DOG HAIR)
• Earlier feedback based on the Tasks to prevent the first failed build
• Planning for food (although our local restaurants and DoorDash drivers made a mint from us)

What actions can we take going forward?

• Ask for feedback earlier in the entire process
• Explain "why" each other prefers a specific technique or method
• Freezer meals or Crockpot meals set up during the day

Continuous Improvement 

We're both feeling pretty confident now that we've tackled a relatively large home improvement project together. Trello's lightweight, flexible interface helps us better communicate and prioritize the needs versus wants of home improvement. Either one of us can add items to the backlog and we have: new interior hardware, update window treatments, etc. This way, each month we can evaluate our budget and either take on smaller improvements or hold off and make a larger improvement after a couple of months. 

Do you use any of your 'work' tools to manage your 'home' life? Contact us to share your use cases!

Third of Three

This is the third (and last) of a three series blog. Our lesson began where you learned that the Secret of Project Cost Accounting in Agile is Nothing. Then we reminded you to Never Forget Where You Came From and in this blog, we show you how to balance tradition and innovation.

The student becomes the teacher. At least, that's how it starts in Kung Fu Panda 3. Master Shifu is retiring and asks that Po, the Dragon Warrior, takes on the project of continuing the training of the Furious Five and other recruits in the Valley of Peace. Much like the agile organization, this causes some initial pain and confusion as everyone tries to settle into their new roles. Meanwhile, a new danger lurks on the horizon: Kai, a once-brother-in-arms of Master Oogway, is intent on revenge against the Kung Fu masters of China. He begins to collect them as jade trinkets as he marches toward the Valley of Peace. His defeat can only come at the hands of someone who has mastered Chi.

Change in an Agile Organization

Change in any organization is inevitable. Change in an agile organization is inevitable as well. However, that does not mean that change means the complete ramp-down of the resources tasked with delivering value to the customer. Nor does this mean that investment is so inflexible that it must be maintained indefinitely for a specific Value Stream. Instead, the value delivery of the Team or Team of Teams changes: support the solution until the next set of Epic-level initiatives are ready to be implemented. In Lean Budgets, the funding of a Value Stream changes based on the solution value delivery and the needs of the customer. What will it cost to operate and maintain the solution? Who bears this responsibility?

Empower Value Stream Content Authority

In project cost accounting, the resources are ramped down or the entire project is handed-off to "Operations". The funding between the development of the solution and the maintenance of the solution is moved between cost centers. As we know from Lean, handoffs are considered a form of waste and, quite frankly, messy. The Furious Five are pummeled by the training equipment as Po frantically shouts out conflicting orders and information based only on what he thinks the way the school should operate instead of trusting himself. He forgot to "Empower value stream content authority." In many organizations, this same confusion, enmity, and pain is the same: Go ahead, Operations, and maintain the thing you've only been involved in for a short time and make sure you don't mess it up. What if we instead maintained a Team or Train to operate the solution and instead moved funding to another Value Stream? The solution remains the same: defeat the enemy (in this case Kai), but the solution context changes in favor of a village of pandas...er...an emerging technology.

Trains are Fixed, but Shifting is Possible

As stated previously, if the Trains are fixed, the costs are fixed. Development and maintenance of a particular solution should then remain fixed. Only when a new set of Epic-level initiatives are given the green light and prioritized, should the Value Stream funding change to accommodate the solution. The Train itself costs $50,000 per PI (as stated in the previous posts) and shall continue to cost that as they maintain the solution. Infrastructure, new equipment, development platform management systems, licensing, etc., are what becomes variable. And this is where we can draw on the techniques that project cost accounting provide. Because these Epic-level initiatives are introduced at the PI boundary, this is also where, if needed, an additional Train can be launched or a train may shift from Value Stream to Value Stream.

Balancing Tradition and Innovation

Wait, what? Didn't we just say that if the Trains are fixed, the costs are fixed? But we're launching another Train or we're moving a Train? Doesn't that mean that the costs changed? Absolutely. This is where Po learns that teaching a bunch of Pandas traditional Kung Fu techniques is not the right solution. He maintains a healthy respect for the traditions of the past (project cost accounting) while balancing the needs of the future (lean budgets). If we launch another Train, what really has changed? We've simply added to the fixed costs for the number of PIs it takes to create and deploy the solution. Instead of $50,000 per PI, we've doubled to $100,000. The additional $50,000 is moved between the Value Streams. In the above diagram, this is demonstrated in PI 3. The funding is still part of the same overall pie, but current priorities mean that launching another Train will enable a different Value Stream to deliver on those priorities. Content authority is still empowered at the Value Stream and Epic-level initiatives are still prioritized within the Value Stream. If value is not delivered, funding can shift back to a different Value Stream the next PI. Po and the Pandas are able to defeat Kai because the investment shifted from the Kung Fu training school in the Valley of Peace to the Panda Village. The work was moved to the Train, not the Train to the work.

Simple... in Theory

While the concepts we've discussed throughout this series are simple in theory, they are difficult to manage in practice. As Yogi Berra once said: "In theory, there is no difference between theory and practice. In practice, there is." Stay tuned. We here at Praecipio Consulting have some great solutions that can turn this theory into practice leveraging the Atlassian tool set.

Second of Three

This is the second of a three series blog. When we last left our intrepid writer, we learned that the secret of Project Cost Accounting in Agile is Nothing. Fixed Teams means Fixed Costs. Fixed Teams means predictable velocity. In Kung Fu Panda 2, however, there is a danger lurking on the horizon: Lord Shen (a peacock) believes in a prophecy which leads him to destroy all pandas in China. He also yearns to regain the respect of his family by conquering China with a new weapon. In many organizations, Lord Shen is the dreaded spreadsheet: the ability to modify project costs based on resource leveling and moving Teams to the work.

Embrace the Past

Let me make this clear: tools are only as effective as the hand that wields them. Lord Shen took gunpowder, used in the making of fireworks, and developed cannons to defeat China. Something that was devised to bring joy to the masses was changed into something destructive which, had it not been for the fortitude of Po and the Furious Five, could have ended disastrously for China. Let's take a look at why project cost accounting can lead us to further victory by embracing our past while securing our future.

The Agile Team Seeks Balance

The Agile Team seeks to maintain balance: deliver the right functionality at the right time producing as much value for the business as possible. Scrum Master, Product Owner, and Team must work together to understand and provide the value. When business value is monetized, it becomes an easy value to track as a KPI, but hard to predict. What did we get for the $260,000 of labor costs we incurred for the team? In fact, what did we get for the $2.6m of costs we incurred for the Agile Release Train (Team of Teams)? If we were able to make revenue on the effort, then the math is simple: subtract the revenue from the costs and we see our net gain or loss. But we all know that actual financial management in any organization is decidedly more complicated. At least in the United States, there are tax breaks for Research and Development, differences between capitalizable and operational funding, and other financial aspects that many people who are much smarter than me spend their careers managing. Is there a way of reconciling our past models with our current and future state of agile? Can we gain the inner peace Master Shifu states Po (and by proxy, the audience) have yet to attain?

PI Boundary

There has been a debate raging on in the agile community around this concept for a few years. While I do not have all the answers with respect to this topic, I have a few ideas. One organization in particular comes to mind where this worked beautifully: a Value Stream with four Agile Release Trains (ARTs) was given their annual investment of $100m to be spread across seven Strategic Themes. The owners of each Strategic Theme came up with a series of initiatives and prioritized them against one another at each PI Boundary. Since Train costs are fixed at the Program Increment (PI) Boundary, if an initiative was completed, its cost was removed from the $100m pool. Any additional variables such as number of Sprints if an initiative was completed mid-PI were accounted for at the PI boundary as well. Simple, elegant, decentralized.

Lean Budgets

However, there was still the need to understand how much of that chunk of money remained at each PI Boundary and whether additional funds could be allocated to another Strategic Theme or another vertical within the company if money was left over. In Kung Fu Panda 2, Po, upon being confronted with a pack of wolf bandits sees a symbol and flashes back to his youngest memories: he's seen the symbol before, but cannot grasp the importance of it. He only knows it's something to pay attention to. Much like when, in SAFe, we discuss the concept of Lean Budgets. We instinctively know this is something to pay attention to, but we still cling to project cost accounting as our method of reconciliation. Below is an example of Lean Budgets in SAFe. 

https://www.scaledagileframework.com/lean-budgets/

Value Stream

The Lean Budgets concept strives to balance governance and empowerment while providing a simple funding model for a given Value Stream. A Value Stream is the organizational structure that provides a continuous flow of value through solutions to the customer (aka the Execution Engine). For example, a Value Stream can be a factory or a hospital. It can also be a development organization - as long as it is focused around solution delivery to a customer. Many organizations struggle to define Value Streams and instead loosely group teams together under a resource manager or other traditional reporting structure and call it an Agile Release Train. While effective on the surface, it complicates coordination across efforts. It's not until a common solution and purpose is defined that the organization can move forward. Lord Shen, as a common enemy across districts, aligns the Valley of Peace and Gongmen City. The teams come together with the needed resources to eventually defeat Lord Shen, but not without trials and tribulations. It is not easy to align an organization to value delivery just as it was not easy to eventually defeat Lord Shen.

If Teams are Fixed, Costs are Fixed

As I stated in the previous post, if Teams are fixed, costs are fixed. If Trains are fixed, costs are fixed. The only funding needed to produce a solution is to cover the cost of the Train. And the cost of the Train should be predictable through a PI. Assuming a single Train in the Value Stream, if each project team costs $260,000 per year, then a Train with 10 teams costs $2.6m per year. Divide the cost of the Train by the number of Sprints in the year (26), then multiply by the number of Sprints in the PIs (typically five), $50,000 is needed for the Train in the PI. Provide the Value Stream $50,000 and watch them work.

Once a Value Stream is defined, Lean Budgets then states it is important to "Empower Value Stream Content Authority." Storming Ox and Croc sit, defeated, in Gongmen City prison. It's only when the Furious Five and Po join them and demonstrate their ability to win a single battle that the two become empowered enough to try and save their city. Before this initial battle, there was no plan other than escaping Lord Shen. The Stretch Goal was to also destroy his cannon. There was no meticulously created work breakdown structure. There were no step-by-step dependencies. There was a single solution the Train needed to implement: learn Lord Shen's plan, escape Lord Shen, regroup to create a plan to defeat him. Our Train (Storming Ox, Croc, the Furious Five, and Po) completed their objective and stretch objective simply by understanding their value and executing on a single purpose.

Project Cost Accounting Starts with the Goal

If, as an organization, we instead try to use project cost accounting, we hinder the Train's ability to provide value. Project cost accounting starts with the goal: defeat Lord Shen. To defeat Lord Shen, we need all three Kung Fu Leaders from Gongmen City: Thundering Rhino, Storming Ox, and Croc. If we have all three, we can defeat him in a day and move onto the next project...er...battle. Three resources for eight hours = 24 resource hours. At $50/hour (our typical cost per hour), $1200 to defeat Lord Shen. This leaves the Furious Five and Po to defend a village from wolf bandits who, in fact, are Lord Shen's minions. The solution does not address the problem as a whole: Lord Shen is the root cause of the battles thus causing the Teams to move to the work. As we move through the story, it took the entire Train to defeat Lord Shen in just one battle and had Po and the Furious Five team members had content authority (knowing what Master Shifu knew about Lord Shen), they might have been able to save Thundering Rhino.

Evidence = Value Delivery Priorities

There are three other parts of Lean Budgets we haven't addressed: Provide objective evidence of fitness for purpose; Approve Epic-level initiatives; Exercise fiscal governance with dynamic budgeting. Let's take objective evidence first. The System Demos and DevOps model addressed in the Program Level of SAFe provides the organization the ability to provide objective evidence. Is it working code in production with dark features toggled on? Yes. Value has been delivered to the customer. Did our intrepid warriors escape? Yes. They were able to escape Lord Shen. However, what happens if value was not delivered? What happens if it takes another PI to deliver the solution? Taking the foundational approach from the project cost accounting model, we have to fund the Train for a second PI. Instead of $50,000 to deliver the solution, it is now $100,000 ($50,000 per PI times two PIs). However, if the cost of the Train has already been accounted for, this is a simple shift in priority, not a movement of funding. You don't have to find another $50,000. Instead, you negotiate whether it makes sense to continue the effort or abandon it based on other value delivery priorities. The path to inner peace starts to become clear.

Approve Epic-Level Initiatives

This ties beautifully into the next part of Lean Budgets: Approve Epic-level initiatives. As we established, the funding is there. If after evaluating the fitness for purpose, the choice is to abandon the effort, the Trains and Teams do not disband. Instead, the work changes as priorities shift toward the next Epic-level Initiative - moving the work to the Teams and Trains. The costs remain constant: only "how" changes, not the "what". The Epic-level initiative is still to defeat Lord Shen: it is the approach that changes for Po and the Furious Five ultimately giving them the flexibility to deliver the victory to China. The Teams and Trains shift to the new strategy and work toward the solutions continue.

Fiscal Governance with Dynamic Budgeting

Lastly, we address the final step on the path toward Inner Peace: Exercise fiscal governance with dynamic budgeting. Much like achieving inner peace, this is not something that is achieved quickly. The recommendation from SAFe is this is addressed semi-annually whereas project cost accounting re-evaluates every work effort once complete. If the effort is small (e.g. 1 month or two Sprints), the allocation of funding to the Team or Train must be evaluated off-cadence meaning mid-sprint or mid-PI. Depending on the internal procurement procedures, this can become a Herculean effort for Business Owners, Epic Owners, and oft times, the Team or Train. It is an unnecessary distraction and thoroughly disrupts the execution. Remember the Kung Fu Leaders of Gongmen City. The first battle with Lord Shen was lost when defined to a specific Team without the proper resources and an unrealistic estimate of the level of effort. Subsequent battles also proved project cost accounting failed the Team: the Furious Five were imprisoned, Po was injured and near death only to be saved by a soothsayer showing him the truth of his past.

Using Agile to Secure the Future

Po reached Inner Peace by embracing the tragedy of his past and letting go. However, we have to remember the lessons we've learned throughout the story. Understanding our past makes us better prepared to embrace our future and win battles. Project cost accounting is a great model when running an organization that is aligned to cost centers. But by realigning cost centers to Value Streams, the burden of project cost accounting is lessened and planning processes can become more efficient. When aligning to the quintessential tenet of agile, trust, you, too, can achieve inner peace.

First of Three

If you've read my other blog posts or watched one of my webinars, you should be familiar with my tendency to intertwine somewhat unrelated concepts together. I like doing this because it gets folks thinking: thinking about serious business and process things in a totally different context. This is the first of a three series blog. Today's topic: The secret ingredient is nothing.

Secret Ingredient

In DreamWorks Animation Kung Fu Panda, Po states to his dad, Mr. Ping (a goose), that he doubts he is his son. Mr. Ping looks at Po very seriously and announces he has something to tell Po. Po, at his most vulnerable, and by proxy, the audience, expects the Big Reveal: Po the Panda is not the son of Mr. Ping the Goose. Instead, Mr. Ping reveals the Secret Ingredient in his Secret Ingredient Soup: nothing. This leads to Po's epiphany that he in fact is worthy, is the Dragon Warrior, and, with the Furious Five, can defeat Tai Lung. Po has had the ability all along and nothing can stop him if he believes in himself.

Project Cost Accounting

Most organizations work with what is called a Project Cost Accounting model. If an effort provides the most value to a specific cost center, the cost center is responsible for estimating costs as well as the length of time for the project. While other costs such as rent, infrastructure, licensing, etc., are factored in, the most expensive resource is the people. The Project Cost Accounting model respects capacity management and resource leveling. If we need to release something in six months (26 weeks) and it will take 26,000 hours: 26,000 hours at 40 hours per week for 26 weeks is 25 people. Multiply the hours by the average cost rate ($50/hour) and the effort will cost $1,300,000 plus "other costs" such as infrastructure and the like. The Project Manager asks for the funding from the specific cost center and the project moves to execution mode (moving the Teams to the work). In reference to Kung Fu Panda, Master Oogway states that Po shall be the Dragon Warrior much to the dismay of the Furious Five and Master Shifu. No effort to dissuade him shall be heard. Raise your hand if you've ever started or managed a project that has left you feeling slightly dazed, incredulous, or rather disheartened.

Iron Triangle of Project Management

So you embark on your quest...er...project. Master Shifu tries to train Po using the traditional methods that were successful for the Furious Five. This leads to hilarious confrontations between the two as little progress is made and Master Shifu resents his time spent with Po. Much like Master Shifu tries to fit Po (and the team) into his model, the Project Cost accounting model adheres to the Iron Triangle of Project Management as well as several other assumptions. The other assumptions include: skill set is equal across resource types, resources are fully dedicated to the project, resources are in place on day one of the project, and work starts day one of the project. We know this is not how it plays out in the real world. Skill sets differ based on experience or technology, resources are usually split between multiple efforts, hiring and onboarding processes delay resource start dates, and work will start on the first day, but not everyone will have work to start on the first day.

An Agile Team is Fixed

The fact remains the Project Cost Accounting model is flawed when managing agile development teams. The strength of the agile Team is their ability to self-organize and create a predictable Velocity. Even before Po joined the Furious Five, Tigress, Mantis, Crane, Viper, and Monkey became legends throughout the Valley of Peace by working well together. An Agile Team is fixed: the number of resources should not change. Project cost Accounting comes into direct conflict with agile planning: because my team of six people is fixed, I will only ever be able to get 240 hours out of the team per week (40 hours per person per week). If the project is estimated at 26,000 hours, it will take 108 weeks to complete and exceeding the release timeline by over a year and a half. While an agile Team removes the assumptions of equal skill sets, dedicated resources, day one start, and day one work start, the 6-month deadline is still real.

Agile Team Dynamics

Tai Lung is headed to the Valley of Peace and he will arrive within a specific timeframe. The Furious Five (plus Po as a noob) then head off to defeat Tai Lung before he reaches the Valley of Peace. As we know, the confrontation does not go well. The team slinks back to the Valley of Peace bruised, broken, and defeated in more than the physical. In-fighting, blame, distrust: there's a reason as adults we relate to kids' movies. In this moment, Po is "that guy". Po's mistakes put Tai Lung's defeat at risk and prolonged the timeline. It also impacted the entire Valley of Peace and allowed danger to further encroach on the innocent. Raise your hand if you've ever felt the same during the course of a project.

If only we had thrown an army at Tai Lung! We could have easily defeated him before he arrived in the Valley of Peace. This incorrect assumption based on Project Cost Accounting then destroys the trust of the PMO in the agile organization. The dynamic of the team as it comes together only by playing off each others' strengths and weaknesses and acting as a team.

Don’t Disrupt the Team

Once the Team is set, it should not be changed based on Resource Leveling or Project Cost Accounting. Instead, moving smaller pieces of work to the Team results in greater throughput. Prioritizing the smaller pieces of work correctly to fit a deadline is critical as well. Po's training was very disruptive to the Furious Five and Master Shifu's Inner Peace. However, once the Team organized and defeated Tai Lung, they were able to save Kung Fu in Kung Fu Panda 2 and expand the lessons learned by Po to a whole village of pandas in Kung Fu Panda 3. The same can be said of Agile Teams or Teams of Teams. Adding a person to a Team to a Train or adding a Train to a Solution Stream based on Project Cost Accounting will disrupt the predictable velocity of the Team or Train and will likely discourage them from innovating or taking risks. The same goes for removing a Team or Train. Adding resources as dictated in Project Cost Accounting will cause disruption and will not allow you to vanquish your enemies...er...complete your project any sooner.

More Secrets

The Secret to Project Cost Accounting in Agile is this - There is no secret. If you follow the concept of an Agile Team, Project Cost Accounting and ROI in an agile framework is simple. If Teams are fixed and Agile Release Trains are fixed, resource costs are fixed. SAFe embraces this within Lean Budgets. It simply requires the organization to completely change how project financials are planned and reported. Stay tuned for next week’s blog, part 2 of 3, where I’ll share more secrets of Project Cost Accounting in Agile. 

What is DevOps?

Before we go into depth about the three phases required to fully operate as a DevOps organization, you must first understand DevOps, which has become an increasingly important framework in organizations. DevOps refers to a set of best practices that empower both the operations and development teams to perform more efficiently, exceed organizational goals, and drive long-term business strategy. 

Regarding the steps to achieve DevOps, I often find myself asking our clients, "What part of DevOps are you focusing on right now?" The response I usually get is, "Well, all of it." And while this is a valid answer, there are three key parts of the framework that you must consider when making the transition. Continuous Integration, Continuous Delivery, and Continuous Deployment are the three steps to becoming a mature DevOps organization. Let's take a closer look at each of them and how they can assist you in your DevOps journey: 

Continuous Integration 

Commit early; commit often. Build early; build often. Test early; test often. Merge early, merge often. That's it. Teams should constantly commit, build, test, and merge code. In a Scrum Team, these units of work are the Stories which the Product Owner will accept as complete, but they may require manual intervention to merge. Breaking down work into small increments is critical to ensuring Continuous Integration best practices. The first step in creating a solid CI/CD pipeline is to work with your teams, at least once per day, to simplify their tasks, as well as the development and testing processes, into consumable pieces. While you may already have a great DVCS tool, building and testing automation tools that support these practices are critical as well. With the Atlassian product suite, teams can easily manage these processes, even down to assigning who buys the doughnuts when the build breaks. 

Continuous Delivery

While often confused with Continuous Deployment, Continuous Delivery focuses on environments. Continuous Delivery means that if the merged code passes its automated tests, it can automatically deploy to a production-like Staging environment. Typically, additional steps, such as integration testing and security testing, will also take place in the Staging environment. Change Requests are filed, and if approved, the code is pushed to Production, along with other changes that may or may not be related. While changes are automatically delivered to Stage, changes are "manually" deployed to Production. As the organization matures with Continuous Delivery, automating the creation of Change Requests when code is delivered to the Staging environment means faster approvals and delivery to Production. When implementing DevOps, some organizations end their journey here. Regulatory compliance, including SOX, may prevent organizations from moving beyond the Continuous Delivery step, even though they still consider themselves a DevOps organization. 

Continuous Deployment

Continuous Deployment refers to code being in the hands of end-users continuously and in a safe and sustainable way. The series of commits, builds, tests, and merges (all throughout the process), means that code can go from the commit phase to functioning in Production in just minutes, as opposed to days or weeks. Real-time monitoring, test coverage that challenges your code base, and lightweight release notes all play a role in Continuous Deployment, which is why teams must be aware of their test coverage metrics and embrace testing as part of their day-to-day responsibilities.Teams can no longer support the "throw-it-over-the-wall" model when development is deployed to Production. In fact, the most successful teams support their code in Production, in addition to developing new functionality for their end-users. How? Because ownership of the business objective to the value delivered to the client is supported not only by the process and tools, but also by the teams' dedication to relentless improvement. 

DevOps: A Systems Approach

Struggling with embracing true DevOps? Because each of these steps builds on one another, it becomes critical to take a step back and review the system as a whole. While many organizations want to get to DevOps, common pitfalls may include lack of Test-Driven Development, extreme separation of duties, Story sizing, or even lack of tooling integrations. If you're struggling to advance from Continuous Integration to Continuous Delivery to Continuous Deployment, it may be time to review your entire development, testing, delivery, and deployment processes to ensure that they support the DevOps journey. At Praecipio Consulting, we guide organizations to embrace a true DevOps framework and help them implement the right tools and processes in order to support a full DevOps deployment, regardless of the industry. 

I had the distinct pleasure of traveling to Atlassian Summit Europe 2018 in Barcelona, Spain. Afterward, six of us headed to Cardiff, Wales for a colleague's (read: friend's) wedding. From there, my husband and I hopped from Ireland to England before heading home. Less than 24 hours later, I was back at the airport on a domestic flight to a client site.

While this seems like a lot, my trusty backpack held most of my essentials for the entire trip around Europe and acted as my go-bag when I was ready to hop onto my next flight. I've compiled a list of essentials I carry with me while traveling to keep not only my sanity, but to ensure I'm prepared for most, if not all, situations. 

Quality Luggage

After years of picking up roll-aboards at the local discount retailer, I finally invested in some new luggage. Don't get me wrong, my last roll-aboard traveled over 250,000 airline miles either in the overhead bins or checked and was only retired in August when one of the wheels finally fell off. My new one is soft-sided, expandable, lightweight, and has 360 degree movement. It's already traveled to Indianapolis and Cincinnati and will be in Vegas, Georgetown, Irving, Austin, and probably one more place I'm forgetting by the end of October. While I spent approximately $100 on the one piece of luggage, I am already pleased with its versatility and durability. Check out what I use here.

Shoes

Not just any shoes. Depending on what we were doing at Summit, in the evenings entertaining clients, or even attending the wedding, it is important to have good shoes. However, when packing light, it's important to consolidate when able. While tennis shoes were a must for an 8-hour day of training, they aren't exactly the right foot wear for an elegant Welsh garden wedding or roaming around the streets of Dublin. Durable, stylish, and comfortable: those are my requirements. Our HR Generalist turned me onto some of the best flats I've ever worn. Averaging 15,000 steps per day in Europe, I was concerned about their long-term comfort for traipsing around cities or attending the wedding where I could keep my footing on grassy surfaces and while dancing. I can't tell you how impressed I am with these shoes and how well they have survived the abuse so far. Best part: they're machine washable. A must after walking in...well...not sure I want to think about it. 

Flip flops are an essential for me for plane rides. I'm lucky my feet don't get cold and they allow me to wiggle my toes, arch and flex my feet, and perform other exercises while on the plane to keep the circulation moving. While it takes ~ 1 week of continuous wear to get them just right, once they're broken in, I can walk all day in them (and have). Just ask my buddy and fellow Principal Consultant, Brian Nye: 27,000 steps around San Francisco taking in the sights. In addition, they take up little space and depending on what I'm wearing during that week, I can choose from a load of colors. And they're easily replaced. Check out what I use here.

Reusable Water Bottle

While it may seem like a no-brainer, a quality reusable water bottle is an absolute must. Long plane rides, air-conditioned terminals and buildings, or visiting Jameson's Bow Street Distillery, hydration is key. I was lucky enough to receive one by Praecipio Consulting several years ago and I don't leave home without it. Many airports have bottle filling stations and if the restaurant has a bar, they're usually willing to fill it as well. I use this one because, other than it being free, has survived 200,000 miles in the air, several drops and falls, and keeps water cold for upwards of eight hours. Not that it usually lasts that long before I drink it all. 

Locking Pill Case

Like most folks my age, I have a few medications I take during the day as well as supplements to keep my body happy. On more than one occasion, the weekly pill case in my backpack has decided to open several days worth of pills into the bowels of my bag. While I was at my local drug store picking up a second case for the 16 days I would be out, I came upon a locking pill case that maintains my daily regimen. I can't tell you how thrilled I was and promptly bought two. I no longer had to worry about where I stashed the cases in my bag for fear I'd be picking fiber out of the bottom of my bag or, god forbid, the fish oil gel capsules were crushed. Traveling with my medications securely stowed in my backpack was a little extra relief as we moved from city to city. 

Travel Umbrella

While I have no preference on brand, the weather in Barcelona reminded me much of home: wait 5 minutes and it will change. It would go from absolutely sunny and gorgeous to rainy and back within a 20 minute period. I stashed this handy piece of equipment in my backpack about a year ago and promptly forgot about it. It has come in handy more times than I can count. When collapsed and stowed, my umbrella is approximately 8" long and weighs less than 6 ounces. It fits beautifully in the bottom of my bag and the wrist strap makes it easy to loop over my arm or clip to my bag when not in use. Mine also has a slip-cover, so stashing a damp umbrella in my backpack won't cause any problems. 

Travel Adapter

When headed to Europe and spending time in both Spain as well as Wales, Ireland, and England, switching or carrying multiple adapters and remembering plugs and cords and and and...ugh. Also, most adapters will offer you the ability to plug one item in then ask you to daisy-chain items to that one. For example, when plugging my laptop into the adapter, I might have to plug my phone and tablet into my laptop to charge those as well. Instead, I found a world adapter with USB charging ports. It also has a fuse for surge protection and each plug is retractable. It's lightweight, relatively compact, and mine survived planes, trains, automobiles, and boats. 

Portable Power Bank

Let's face it. When at a conference or on vacation, you're in for some long days and nights. There's also a significant amount of phone usage for pictures, posts, tweets, etc. It's not always convenient to carry the adapter, a cord, and a power bank. In fact, that puts me right back in the dilemma of "Do I really need a whole backpack to carry everything?" My husband found this one and I ordered one right before I left for Spain. While it's by no means light, it was compact enough that with an octopus (multi-use cable set), not only did it fit in my relatively small purse, I was able to keep my phone charged as we galavanted around the various cities. Best part: it has a solar charging option for the power bank itself. I tested this one sunny afternoon and was delighted to see the flashing LED indicator turn solid indicating it was fully charged. 

While I have many more things I keep in my backpack (probably too many things, to be honest), these items were and are a must when traveling domestically and abroad. If I have only one item to add, it would be something non-electronic to stimulate the mind. My preference is coloring, but a good novel (paperback), crosswords, Sudoku, or the compact multi-puzzle books are all good options. It should provide you the ability to disconnect from the world for an hour or two because, let's face it, travel can be exhausting and you can't pour from an empty cup.

Clients and potential clients ask us what sets us apart from other Atlassian Solution Partners. While I hate answering this question as I have good relationships with people from other Solutions Partners, I love the answer we have at Praecipio Consulting. 

We're people people. The relationship is the most important thing to our success. While we're working on the cutting edge of technology every day with every client, at the end of every day and every engagement, we're still focused on the people. The goal of every engagement is to make life just a little easier on the people through good process, well practiced. 

We're officially wrapping a nine-week engagement this week with a long-term client. This particular client has come back to us several times throughout my career here at Praecipio Consulting. The relationship and trust we've built with these folks have gone a long way to establishing both business and personal relationships around not only mutual interests but genuine caring about each other as people. 

This week, though, I was humbled by the other people I appreciate, but often overlook. When you stay at the same hotel for ~ two months, you get to know the staff as well. In particular, two employees stood out to me, not only for their excellent customer service, but their own openness and willingness to have conversations, debates, asking how the project team is doing, accommodating last minute changes, and making sure we were taken care of in whichever small ways they could. It's about the people and these two people showed us that what we drive with our clients is the right thing to do. 

Today was particularly poignant as this was my last night at this hotel. As a small gesture of my appreciation, I bought a simple bouquet and split it to give each of them a thank you for taking care of the project team. Not only taking care of the project team, but during a particularly arduous week, taking goofy pictures, discussing Netflix series, sharing their excitement of going to a Cavs game for the first time, or the excitement of the premiere of Black Panther. To put it plainly, they treated us like people...not consultants. 

At the end of the day, it's about people. It's about our day-to-day interactions with people that make what we do so amazing. Good days or bad days, people are people: interacting as a person and not as a title can bring great things to clients and friends. I, for one, am super proud to know these two amazing gentlemen and sincerely thank them for all they do!

Want to connect your business strategy to development reality? Jira Portfolio, Atlassian's newest product, allows for easy and accurate planning across multiple projects and teams. Get an inside look at the latest offering and learn how to connect strategic goals to development reality with Jira Portfolio.