7 min read

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

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

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

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

Strong fences make great neighbors

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

 IMG_4511IMG_4512

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

IMG_4507

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

IMG_4508

Not in my back yard...

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

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

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

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

IMG_4509

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

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

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

What happens if I keep asking why? 

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

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

Actions speak louder than words

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

For me and my puppers, it's simple. 

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

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

BRB, gotta run and get some more fence planks.

IMG_4510

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

Tips for Performing a Successful Root Cause Analysis

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

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

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

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

What is Root Cause Analysis?

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

Root Cause Analysis Blog Post

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

Why Does It Matter?

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

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

How Can I Help My Organization Embrace RCA?

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

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

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

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

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

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

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

2020 Blogposts_Praecipio is live in Workatos automation marketplace

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

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

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

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

How Workato Helps Remote Teams Rapidly Resolve Incidents

By Courtney Pool on Apr 28, 2020 9:15:00 AM

2020 Blogposts_Workato

It's 2 AM. You just pushed out a major release, and then it happens. You're alerted to an Urgent bug. Lights start flashing, the sirens are blaring, and in the distance, someone yells, "Get the president on the line!"

Ok, so maybe it doesn't happen like it does in the movies, but that doesn't mean you can't have any bells and whistles.

WFH Incident Management 

When dealing with escalated issues, a swift response is absolutely critical – any delays in addressing an issue can severely impact a company, whether in time, satisfaction, or revenue lost. As such, many companies are quick to set up at least basic alerting through Jira in an attempt to rally the troops as quickly as possible. While relying on notifications from Jira may be enough to mostly get the job done, though, you're still risking some immediacy of response, as many people don't check emails the moment they're received (and some may even filter them directly to junk if the instance is too noisy).

A two-pronged approach is often needed in these situations, with town-criers tasked with alerting others on apps like Slack as well. This approach does work better, but it still relies on a human component, which again, introduces risk. Mitigating these risks is especially important now that most teams are fully remote due to COVID-19, preventing any quick updates over the cubicle wall. Automation can remove these risks while also alerting others as quickly as possible.

Enter Workato.

Mitigating Risk With Workato

Workato is a middleware tool dedicated to making APIs and automation more approachable to the Everyman. It’s also a powerful teammate in the ever-raging battle against mission-critical issues.

To best illustrate this, consider the following use case:

You have a team of internal stakeholders who need to be notified immediately for every Urgent or Critical issue entered into Jira. While the teams that work on the issue need immediate notification,  which team that is is notified will differ by product. You use Slack internally, so notifications typically happen there.

Workato can help accomplish this.

The recipe needs to be built to trigger conditionally based on priority, as identified above. From there, you also know that you'll want to push to Slack, and that which group receives alerts will differ differ based on values selected.

BONUS TIP: If your teams use Zoom, you can even leverage Slack's integration to have a Zoom meeting available when you need it, without having to spin one up yourself.

Expanding on the use case above, if you want Critical issues to notify in Slack and set up a war room in Zoom, have Workato send the command /zoom meeting [ISSUE ID - ISSUE SUMMARY] and wait for the fireworks. Once your recipe is built out and thoroughly tested, you can sit back and relax – at least until the next Urgent issue comes in. Automation will take care of the rest.

By letting Workato take the wheel, you can remove a lot of the risk from addressing escalated issues — and get to enjoy some of the bells and whistles, too.

Topics: workato incident-management work-from-home
6 min read

From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development

By Praecipio Consulting on Feb 15, 2013 11:00:00 AM

The following content was taken from Atlassian.com  

In this the first of a three part blog series which focuses on migrating the Jira code base from Subversion to Git. We wanted to share Atlassian’s migrating experience to those of you who are contemplating moving a large project to Git – without sacrificing active development. In our first post we discuss why we decided to make the switch to Git. In our second post we dive in the technical details of switching from Subversion to Git. In our third, and final post we will discuss how we managed the “human” angle to migrating.

Atlassian has been extremely excited about DVCS for a number of years and has invested heavily in DVCS. Atlassian has acquired Bitbucket – a cloud DVCS repository host, developed Stash – a behind the firewall Git repository manager and added DVCS support to FishEye, Atlassian’s code browsing and search tool. They have also added a myriad of DVCS connectors to Jira.

Along with Atlassian we believe DVCS is a great leap forward in software development. As part of this, Atlassian migrated the codebases for their own products and libraries from centralized version control systems (generally SVN) to DVCS. Some of these have been big migrations!

In this three part blog series we will  focus on the biggest migration Atlassian has done – migrating the 11-year-old Jira codebase from SVN to Git. What obstacles did they encounter? What lessons did they learn? And most importantly, how did they do it without sacrificing active development on Jira? We hope that sharing this experience helps anyone approaching a similar migration.

We’ll focus on Git, because Jira moved to Git, but everything in this series applies equally to Mercurial. At Atlassian, they use both.

Why DVCS?

Migrating a big code base is not without cost. The first thing you will need to answer – both for yourself, your bosses, and the people who work for you – is what will DVCS bring us, and why is it worth the cost of migrating?

We have used SVN successfully on many projects.  So has Atlassian.  And I am sure many people reading this article have also used SVN successfully. Since there is always a cost to migration, you may be inclined to ask, “If Subversion has met my version control needs for many years, why should I change?” To me, that is the wrong question. The real question is, “How can DVCS make what we do today even better?”

Git is known for several things.  For a developer working with code, it’s faster.   It allows for advanced workflows like feature branching, forks and pull requests – in theory, these workflows are all possible with SVN, however the difficulty of merging in SVN compared to Git makes them untenable.  But for anyone moving from SVN, the main benefit of Git is that because of its lightweight branching and easy merging, Git allows you to do your default SVN workflow better than SVN.

What do we mean by this? Let’s talk about how we actually develop and release software. Most of us work in a world where we have at least one released version of our software in the wild, which we call a “stable” branch. We maintain and contribute bug fixes to a stable branch while developing new features on a “development” branch (which is called trunk/master/default depending on which VCS you use).

When we commit bug fixes to stable, we need to get them into master too. SVN merge is known to be a pain and works solely on revision history – not actual content.  As a result, a lot of people avoid it, or they do it infrequently and not as part of their day-to-day workflow. How many projects have you worked on where stable and development branches have started to diverge, or diverged so significantly that the effort to bring them back together is a real project cost? Many have certainly been in projects where this has happened, and when we speak to other developers it’s a frequent occurrence with SVN. There are some strategies to deal with it.  For example, with Atlassian’s issues and tracking software, Jira, they ignored merging and required developers to make each commit individually to each stable and development branch, relying on QA to make sure that it happened correctly.

Git allows you to remove this pain. Git makes merging so easy that merging the entire stable branch into the development branch on each commit is a reality; it’s now Atlassian’s default workflow. So even if you don’t want to use feature branches or forks or pull requests immediately, Git provides advantages from day one.

And when Atlassian was ready, they were in a position to take advantage of the advanced workflows that Git allows. Before the switch to DVCS, Atlassian’s major products targeted 90-day release cycles. These 90-day releases went to two platforms: downloadable products for clients to install on their own servers; and a release to Atlassian’s  hosted cloud platform (Atlassian OnDemand) for which clients pay a monthly fee. Using branches as a core part of development workflow has allowed Atlassian to shorten this to the point where they now release major products to the cloud every 2 weeks.

The Switch

Jira is a decent size code base to move – 11 year’s worth of history, 47,228 commits across approximately 21,000 files. Atlassian averages about 30 different committers over a two-week period. More than that, the VCS is a real work-horse for a project like Jira. Builds, code reviews, scripts for releasing both product distributions and source… all these things have a rich tapestry of dependencies on the source code management system.

Their main goal in the migration was to minimize interruption to developers. This is about more than just the ability to commit code; it is about the infrastructure surrounding software development.

Atlassian has 3.5 years of history in Jira’s code review system.

Jira has a lot of CI. Atlassian runs approximately 60 build plans over different configurations and branches.

They have some other dependencies too – Jira has a somewhat complex release process that involves pulling together code from multiple sources. Atlassian also releases their source code to customers, which involves a different set of build scripts.

There is a tradeoff here between how fast you can migrate and how stably you can do it – Atlassian’s guiding principle was to optimize for stability over speed. If you set a deadline for your migration and it slips, what’s the worst that happens? Developers have to commit code to SVN for another week or so. Not the end of the world. It’s far worse if the migration interrupts developers’ ability to work and meet their own deadlines.

In the end, the migration took 14 days in total, with only a total of two hours where developers were unable to commit code. Atlassian were nearing the end of the development cycle for their latest release, Jira 5, and at no point were they unable to cut a release candidate.

Preparation

When preparing the migration, there are a couple of things to be aware of.

First, it will take time. The actual git-svn clone, which takes all of the commits in the SVN repository and replicates them in Git, took three days for Atlassian.

Second, you should prepare and think of all the dependencies your infrastructure has on your VCS. And know that if your infrastructure is sufficiently complex (like Atlassian’s), there will be things you never dreamed of and only discover when they break. So don’t beat yourself up when you encounter a dragon. Just slay it, and continue on your quest.

A migration like this is not something you can do overnight, or even over a weekend. It needs to be managed for a sustained period of time.

Migration – The Technical Side

Stably migrating is daunting but it is not brain surgery; there is a process Atlassian has employed to make it manageable. In part 2 of Atlassian’s Switch to Git series we walk through, step-by-step, the technical details on migrating from Subversion to Git.

Topics: atlassian blog management migrations svn technology git incident-management information
2 min read

Jira: Not Just for Software Development

By Praecipio Consulting on Aug 17, 2012 11:00:00 AM

Jira’s an issue tracking application, but its core flexibility and strengths mean it can become much more than a tool limited to a development group. Jira’s incredibly adept at helping teams track and accomplish tasks. Jira also has a masterful ability to manage life cycles - and it’s found great success in numerous use cases.

Use Cases

The following use case guides are meant to explain a bit of the details related to using Jira for a specific use case. The info you’ll find in here highlights much of what we’ve learned from working with clients in a variety of different industries, as well as our internal expertise and use of Jira.

For each of these use cases, we’ll attempt to highlight:

  • Particular Jira functionality specific to the use
  • Related plugins we’re aware of
  • Customization and tweaks
  • …and sometimes a sample file to help get you started

General and Non-Software Uses

Agile Software Development

Project Management

HelpDesk / Support / Trouble Ticketing

Test Case Management

This can be done by using either of the following approaches:

Requirements Management

Change Management

Topics: jira atlassian blog scaled-agile austin automation business efficiency enterprise issues management process services technology value tracking change cloud collaboration computing continuous-improvement incident-management information integration it itil itsm operations
3 min read

The ABC's of Agile

By Praecipio Consulting on Jun 7, 2012 11:00:00 AM

The Agile school of software development’s currently one of the most accepted methodologies for improving productivity. Targeted mainly towards IT managers and CIOs, Agile methods promote an interactive approach which have the ability to help flatten your organization’s cost of change curve.

The Manifesto for Agile Software Development was first introduced in 2001, and outlines the foundation of Agile in twelve principles:

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Working software is the principal measure of progress
  5. Sustainable development, able to maintain a constant pace
  6. Close, daily co-operation between business people and developers
  7. Face-to-face conversation is the best form of communication (co-location)
  8. Projects are built around motivated individuals, who should be trusted
  9. Continuous attention to technical excellence and good design
  10. Simplicity- the art of maximizing the amount of work not done- is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances

Cost of Change Curve

First introduced by Barry Bohem in 1981, the cost of change curve represents the exponential increase in cost as it relates to making a change during the normal development phase of a product. This means that as your product moves farther down the developmental pipeline it becomes more costly to make changes and remedy errors.

That’s a good argument for Agile since it ensures you leave the current production phase with a product that’s as close to perfect as you can make it – particularly because Agile methodology calls for testing and up-front integration which translates to rapid production and minimal initial design. Since the test code’s written before functional code and automated test suites are built around the evolving code, developers are allowed to make rapid and aggressive changes.

The ability to make these changes is one of Agile’s key features and the result is a reduction in the amount of product errors late in the development phase, reducing the cost of change. Even if your organization enjoys a rather flat cost of change curve, Agile ideals can be applied to reduce the cost of change throughout the software life cycle.

Scrum

Scrum’s another widely accepted approach to implementing the Agile philosophy, which includes both managerial and development processes. This approach relies on a self-organizing, cross-functional team supported by a scrummaster and a product owner. Scrum makes your organization Agile by ensuring quick progress, continuously creating value, and by keeping projects on track. The most important concepts of Scrum are:

  • Product backlog - A complete list of requirements that are not currently in the product release. Typical backlog items include bugs and usability/performance improvements.
  • CI - Also known as continuous integration; allows for scrum teams to continuously integrate their work. This will often happen on a daily basis.
  • User story – Describes problems that should be solved by the system being built.
  • Scrummaster - The manager of the Scrum project.
  • Burndown chart - The amount of work remaining within a sprint, i’s updated daily, and also tracks progress.
  • Sprint backlog - A list of backlog items assigned to a sprint, but not yet completed

Kanban

Kanban means visual board – and that’s just what it is, a development process that revolves around a board to manage works in progress (WIP). A Kanban board includes “lanes,” each denoting different phases a project might take. It moves WIPs across the board and deploys them into production when they reach the done column. Since Kanban development practice revolves around WIP management each state of progress is limited to a set number of projects. Organizations able to leverage this high frequency of delivery typically enjoy a large financial benefit.  The most important concepts of Kanban are:

  • Swim lanes - The horizontal lanes of a Kanban board represent the different states in which a WIP or task can exist.
  • Backlog - A list of backlog items awaiting deployment, but not yet completed.
  • Stories – A particular user need assigned to a development team.

Atlassian and You 
Atlassian specializes in robust, easy-to-use, affordable internet applications that seamlessly integrate Agile and Lean methodology  with your business processes to support your organizational goals.  Simply put, success breeds extraordinary performance – and  extraordinary performance breeds success. Atlassian’s suite of products are designed to boost your organization’s performance by providing tools that are easy to use, allowing your business to build its own solutions.
Topics: jira atlassian blog scaled-agile central business confluence efficiency issues management process process-consulting scrum technology texas value tracking change continuous-improvement greenhopper incident-management information it lifecycle operations
2 min read

Jira + ITIL Working Together

By Praecipio Consulting on Jun 24, 2011 11:00:00 AM

Atlassian Jira's a remarkably flexible tool. For most who hear “Jira,” things like issue tracking, project management, and software development come to mind. Very rarely do people think of ITIL in relation to Jira. But then again, many don’t know what ITIL is.

If you’re a developer or in IT and don’t know what ITIL is, you should. It’s a set of processes for managing lifecycles with relationships to one another. It’s the most widely-accepted approach to IT service management in the world – a set of best practices drawn from public and private sectors around the world. ITIL doesn’t just apply to IT service management (ITSM), though – it’s a reliable methodology for managing any type of complex technological process.

Jira’s an Atlassian tool that’s phenomenal at lifecycle management (workflows, custom fields, etc). It’s designed to be issue-centric, built around managing issues or bugs that pop up within a product or service’s lifecycle. This functionality extends far and wide when you expand how you define an “issue.” On the surface, an issue is more like a problem – but considering an issue’s attributes, it can easily qualify as a task or milestone. With that in mind, Jira can facilitate far more than simple issue tracking. It can support complex process lifecycles.

Every process is a web of highly dependent relationships between regular and conditional tasks – including ITIL processes like Incident Management and Problem Management. The huge breakthrough here is making Jira projects and workflows represent (and support) ITIL processes. Let’s take an incident for example. An incident goes through several states:

(1) detection and recording
(2) classification and initial support
(3) investigation and diagnosis
(4) incident closure

A good Incident Management process within a good technology helps reduce meantime to recovery – i.e. recover from an incident. We all know how well Jira facilitates transitions and workflow. Let’s take it a step further…in ITIL-based Incident Management, we are supposed to designate incident ownership, actively monitor, track and communicate. BINGO! This what Jira does.

Let’s take this another step further. Problem Management is a process used to identify root cause to reduce the number of incidents – thereby increasing the meantime between failures. Using Jira, we can manage root cause analysis and associate the individual incidents (manifestations) back to the Problem Management record we’re analyzing. This ability to link records and collaborate makes Jira a great Problem Management solution. Add Confluence to the mix and the effectiveness is improved further.

Going another step further – having ITIL-based ITSM processes running in Jira alongside your organizations SDLC further helps IT align its capabilities to deliver the highest, best quality software and service delivery.

We’ve helped clients implement Jira to manage Incident Management, Change Management, Problem Management, Asset Management, Software Development, Testing… we love the Altassian products and so do our clients.

Topics: jira atlassian blog asset-management confluence issues management problem process reliability sdlc services software workflows tracking change development incident-management it itil itsm lifecycle methodology bespoke
2 min read

5 ITIL Change Management Tips

By Praecipio Consulting on Mar 19, 2010 11:00:00 AM

In order to remain competitive, a firm’s IT environment must be aligned with the firm’s business strategy – meaning IT should share responsibility in delivering value to the customer.

This is why Change Management is so important: changes to the IT environment must not disrupt the value delivered to the customer. IT must maintain stability even during change. ITIL’s Change Management methodology provides a clear framework (with defined roles, responsibilities, and processes) that can facilitate success.

Change Management should be considered a major undertaking. Determining where your firm stands in terms of ITIL maturity and developing a realistic project plan will improve your ITIL effectiveness.

Here are 5 Change Management tips to consider:

1. What’s a change, exactly?
Reality check: changes happen all the time. Nearly everything in IT involves some sort of frequent change. That being said, it’s important to figure out just what you consider to be a change. You can then determine when to apply ITIL Change Management principles.

Every change (even small installations and deletions) should be handled in terms of Change Management. The smallest of changes could cause major disruptions if no one knows about them.

2. What, specifically, will Change Management accomplish for my organization?
It’s no surprise that some firms have trouble defining ITIL in general. Since ITIL methodology isn’t something you can learn on a coffee break, most IT and non-IT folks alike don’t have the time to study ITIL for days.

Even if someone understands ITIL, they may not understand how it applies to efficiency. Someone might think implementing Change Management will fix issues related to Release or Incident Management. Pinpointing what Change Management will accomplish for your organization is therefore vital to understanding what it’s actually doing – managing the oversight and approval aspects of the change process in a unique organization-specific environment.

3. Articulate the benefits of Change Management to each level of the organization.
This goes right along with our last tip. Once you pinpoint the applicative benefits Change Management will have for your organization, advertise them. Getting buy-in at every level of the organization is critical to the success of your ITIL implementation.

There are multiple stakeholder groups within every organization – that is, folks personally and organizationally affected by the change. They’ll want to know “what’s in it for me?” in order to judge whether they’re on board with the change. Presenting accurate change information tailored for each stakeholder fosters better accountability from stakeholder groups – and improves buy-in.

4. Don’t Buy a Tool Until You’ve Determined What You Need.
While it may make sense to buy software to guide your Change Management implementation, doing so before laying out your process framework is counter-productive.

A more productive approach includes determining your needs before adopting a tool, so you can better evaluate which tools fit your needs instead of adjusting your needs to your tool.

5. Use Change Management Success to Promote Other ITIL Initiatives.
Folks are usually familiar with the Change Management component of ITIL – and oblivious of its other processes. If you track your Change Management successes and gather supportive data from Key Performance Indicators (KPIs), you can use success stories to promote the benefits of other ITIL processes like Release Management, Incident Management, etc.

One final tip: It’s worth noting the incredible value and need for leadership/executive support in the Change Management process. It’s important for company leadership to sell and support the change despite resistance in the company to organizational and cultural change. Often times, Change Management implementations are resisted since they uncover underlying issues that some within the company don’t want to uncover. Ultimately, though, Change Management helps make everyone proactive and out of the reactive, fire-fighting mode.

Thirsty for more? Contact us here.

Image courtesy of Patrick Lane Photography.

Topics: blog implementation library management process release technology tips tricks change continuous-improvement incident-management information infrastructure it itil operations
2 min read

Wave as a Customer Support Platform

By Praecipio Consulting on Dec 4, 2009 11:00:00 AM

Businesses are already taking advantage of Google Wave’s wide-open door of innovative opportunities. This blog highlights Wave’s ability to support client needs and solve real customer service issues.

Wave is capable of allowing customers to interact with automated support robots produced by their service providers to help guide customers to answers to their issues. Billed as the next generation of collaborative software, Wave is—in this instance—allowing customers with problems to collaborate with support teams instantly.

When a customer contacts their provider’s support tool via Wave, an instance may be automatically generated in the provider’s issue tracking system. Human-to-human interaction is not necessary at first, since an automated support robot may be designed to reply to the customer’s Wave with relevant support articles based on the customer’s input. If the customer is not led to information needed to solve the issue, they may (at any time) choose to engage in a dialogue with a company representative. These operations are executed behind the scenes by the robot, thanks to appropriate coding.

When an issue is solved, a company may easily extract Wave’s support dialogue and embed it into the issue’s archive in their issue tracking software. It’s almost to good to be true. For example, Issue 92A is listed in a company’s issue tracking server—complete with its submission time, status reports, etc. In addition to this key data, the entire dialogue with the customer can be embedded into the records.

Mashable recently featured a post highlighting Salesforce’s use of Wave to save clients money on customer service support while actively tracking issues.

The technology and coding methods necessary to execute something like this are being shared more publicly. After all, Google wanted Wave to run off user-generated content. They’ve already generated a Wave developer’s guide to walk you through what it takes to use Wave for…well, whatever you want to. There may even be a way for Wave to make you coffee.

The team at Praecipio Consulting is ready to tailor Wave to fit any process, project management, issue tracking, or collaborative model you need to make your business more efficient and innovative. Wave’s just emerging into enterprise collaboration. Now is the perfect time to gain an innovative edge over competitors with Wave technology.

Would you like more from us? Contact us here.

Topics: blog bpm business enterprise google issues management process project services tracking wave collaboration incident-management
1 min read

Jira and Confluence: Hand-in-Hand Collaboration

By Praecipio Consulting on Dec 3, 2009 11:00:00 AM

Atlassian claims Jira and Confluence were “designed to complement each other.” What some don’t realize, however, is how easy and convenient this integration really is.

Confluence has proven itself as an effective project management tool, flexing its muscles as an innovative wiki allowing users to create and share rich content. Jira manages workflows and tracks issues in a well-designed, coherent user interface (UI).

For IT professionals using Jira to track issues, Confluence provides a fertile ground to collect a team’s knowledge. In Confluence, the team may collaborate by embedding Jira content (including graphics) into a collaboration space—and easily link Confluence and Jira pages. They may also embed Confluence pages into Jira. The 3-minute explanation shows you everything you need to know.

The embedding process is remarkably easy. We believe teams using Jira and Confluence can bank on this integration, from a project management perspective.

Would you like more from us? Contact us here.

Topics: jira blog bpm business confluence efficiency enterprise issues library management process services technology tracking collaboration incident-management information infrastructure itil
1 min read

Jira 4's 2.0 UI Makes Issue Tracking Simpler, More Nimble

By Praecipio Consulting on Sep 26, 2009 11:00:00 AM

Australian-based Atlassian debuts Jira 4 today, October 6.

Atlassian first debuted Jira in 2003 as an innovative issue tracking and project management software. As we mentioned in our previous blog Jira - Complexity Made Simple, Jira is a huge asset in enterprise collaboration. It’s completely permission/Java/web-based, highly customizable, and amazingly simple to use.

The key news about Jira 4? Atlassian has worked hard on integrating Web 2.0 capabilities into its latest version– and appears to be most proud of its new, “dynamic” user interface (UI).

  • Jira 4′s home page will feature “click-and-drag” windows showing content the user chooses. It also includes widgets from other websites like Google. For example, a Jira home page may feature five boxes in three adjustable columns: current issues, priority issues, resolved issues, project folders, and local weather (via Google). These five boxes may now be dragged around to any location on the home screen, and color-coded for organization.
  • Jira 4′s search function has been  ”2.0-ified,” so to speak. Now search results pop up below the search bar after each character you type, much like in the “to” box in most email interfaces. This will likely make the search for a particular issue simpler and more efficient.
  • Jira 4′s Greenhopper plugin adds a broad collection of project management capabilities to Jira– great for development teams. GreenHopper represents issues as color-coded “cards,” sorted with what Atlassian calls “drag-and-drop simplicity”– which we consider a powerful organizational capability.

    We highly recommend Jira for your business’ issue tracking and project management processes. Our team is experienced in implementing and using Jira to its maximum potential. Jira 4′s 2.0 capabilities should make using the software more simpler and efficient than it’s ever been before.

    Would you like more from us? Contact us here.

Topics: jira blog bugs enterprise issues library management services technology tracking collaboration help-desk incident-management information infrastructure it itil
2 min read

Incident Management: The Responsible Way to Gold-Star Customer Service

By Praecipio Consulting on Jul 14, 2009 11:00:00 AM

Incident Management is debatably the most important area of IT Service Management because of its direct impact to the Services customers rely on. One of the ITIL disciplines, the focus of Incident Management is to restore services following an incident as quickly as possible—be it a business operations issue or merely an internal or external lack of technical understanding. Incident Management activities, often executed by a Service Desk, include:

  • Discovering details of an incident
  • Matching incidents against known problems
  • Resolving incidents quickly
  • Prioritizing incidents according to their impact and urgency
  • Escalating incidents to other teams when needed to ensure timely resolution

Incident Management is one of the most difficult ITIL disciplines to maintain—operating a Service Desk for anyone struggling with technology can be a daunting task given the consistent learning curves existing as businesses adopt new technologies and optimize old ones. This is why Incident Management should be a big deal to businesses.

ITIL Incident Management aims to minimize disruption to the business by restoring service operation to agreed levels as quickly as possible. The total Incident Life Cycle is described as follows:

  • Occurrence
  • Detection
  • Diagnosis
  • Repair
  • Recovery / Restoration

The above steps of the Incident Life Cycle serve as key data points that, when measured, provide a great deal of value. The intelligence that is derived from these data points helps IT organizations focus and invest their time in those projects and activities that will shrink the Meantime to Recovery (aka Mean Time to Repair). In the event the time it takes to detect an outage is long (Detection Time Stamp minus Occurrence Time Stamp), an IT organization can focus on automating outage detection or increase the ease of reporting issues by clients to the Service Desk. In the event the Diagnosis time (Diagnosis Time Stamp minus Detection Time Stamp) is long, the IT Organization should focus on training, escalation path definition/automation and/or tool sets to ensure IT staff has the adequate means to make an accurate assessment. Without going into more detail, it is clear that a well-defined process like Incident Management can help streamline and shorten the Incident Life Cycle thereby minimizing the Meantime to Recovery.

Incident Management is often the first process instigated when introducing the ITIL-quality framework to a Service Desk, and offers the most immediate and highly visible cost reduction and quality gains. Some brief reasons why you should consider implementing ITIL-based Incident Management:

  • Achieve and maintain impressive levels of customer service
  • Provide outstanding service availability
  • Achieve overall staff efficiency and productivity
  • Significantly improve customer satisfaction

Praecipio Consulting has a proven track record of excellent Incident Management/Service Desk support for its clients, and intentionally aims to minimize disruption to their clients’ business by restoring and applying ITIL framework to incident recording, tracking, and resolution.

Would you like more from us? Contact us here.

Topics: blog library management services technology incident-management information infrastructure it itil itsm

Praecipio Consulting is an Atlassian Platinum Partner

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

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us