Waterfall and Agile are both process methodologies with very different approaches to achieving the same goal: developing high-quality products. Where Waterfall focuses on strict requirements and planning, Agile provides a more adaptable approach where it's much easier to adjust requirements and timelines as the product develops. Both methods have their pros and cons, hopefully this article will help clear up which one is right for your project!

What is Waterfall?

Waterfall is a linear and sequential process methodology. It breaks up projects into several distinct phases, with a complete product being delivered only after the final phase is successfully finished. An example of these phases may be something like: 

Requirements > Design > Development > Testing > Implementation

These phases are completed in order, where all tasks associated with that respective phase are complete before the next phase can begin. The teams required in each phase can be distinct, and may require only slight overlap between phases. Both the customer requirements and timeline are established early on within the product development life-cycle. The Waterfall methodology really excels when product requirements are strict, and the goal is to provide complete product within a specified timeframe and budget.

As someone that comes from a background developing manufacturing processes, the waterfall methodology was basically a way of life. Every new product life cycle began with Advanced Product Quality Planning (APQP) and its phases:

Planning > Product Design & Development > Process Design & Development > Product & Process Validation > Production

These processes are followed in order, with a review at the end of each phase by their respective team. In most cases, shortly after beginning production for one project, the planning phase for the next project would already have started, and so on. The strict product requirements, tight deadlines and long lead times to design and build manufacturing equipment lends itself well to waterfall. Lead times for manufacturing equipment can range anywhere from 3 months to over a year depending on complexity, so establishing clear product requirements early is imperative. Any change to the product or process requirements could result in extreme delays to the project.

Pros

• Project timelines, budget and progress are easier to manage and measure throughout distinct phases.
• More hands-off for customers after initial requirements and timelines are established.
• Detailed documentation is more readily available.

Cons

• Need strict requirements very early on, changes to these requirements can be costly.
• Less overlap and communication between teams makes collaboration more difficult.
• The testing phase occurs much later in the project, so any issues found can be expensive and delay projects drastically.
• Distinct teams, rigid timelines and budget constraints make it difficult to move back to a previous phase if issues arise.

What is Agile?

Agile is an iterative and highly adaptable process methodology. Agile focuses on breaking down projects into small product releases that can then be iterated on to make improvements. These iterations go through all phases of a project simultaneously. This allows a team member to be testing out one feature, while another is designing a different feature. With all of the phases of a project moving simultaneous, having a fully cross-functional team engaged throughout each iteration is imperative. After each iteration is complete, clients can review the most recent release and set priorities and goals for the team in the following iterations. The Agile methodology excels when requirements may need to adapt as the customer's needs develop, and there aren't strict requirements for timeframe and budget.

Software development is one of the key uses for the Agile methodology. With new product requirements frequently coming up and an on-going timeline for completion, breaking the project down into continually improving iterations is a much better way to control changes. With each new iteration, clients will find new beneficial features they'd like implemented, and these feature requests will be turned into tasks to be planned for future iterations. The average time for an iteration is usually between 1 and 4 weeks, so clients frequently get a look at the current state of the product and are able to evaluate priorities for future iterations accordingly. Agile works incredibly well when requirements are not fully established up front, which is usually the case with software development projects.

Pros

• Highly adaptable and works well when customer requirements are not completely established up front.
• Fully cross-functional teams promote higher collaboration than distinct teams.
• Frequent customer communication helps ensure requirements are being met and customer satisfaction is high.
• Testing is performed concurrently with development during each iteration, leading to faster identification and correction of issues.

Cons

• Tracking timelines, budget and project progress is more difficult across multiple iterations.
• Additional iterations can lead to lengthened timelines and increased budget.
• Documentation is usually lacking between iterations.

At Praecipio Consulting, we have more than 15 years of experience helping clients big and small become the best version of themselves; if you have questions on Waterfall, Agile, or any other process methodology, reach out and let us know, we'd love to help!

It’s a dream we all have: To be the founder or early employee in a company so disruptive that it has a real chance to hit it big. With success comes prestige, security, respect, and of course, lots of money. 

How can you set up your small business to become the next big thing?

The key is to learn from others who blazed the path before you and not make the same mistakes they did. 

Jim Collins, author of the iconic business book Good to Great, suggests that one of the most important factors in building a great company is to adopt the right technology early in your business lifecycle.  

“When used right, technology becomes an accelerator of momentum, not a creator of it.”

-Jim Collins

Whether your business is the manufacturing of widgets, service, or software development, technology is what allows you to spin up faster, pivot, and gain a competitive edge through efficiencies. Praecipio Consulting specializes in helping organizations leverage technology through the use of Atlassian’s suite of products and leading frameworks like Agile and Scaled Agile, ITSM, DevOps, and Enterprise Service Management. EVERY company is a technology company or is currently undergoing a transformation to operate with those capabilities and mindset.

Michael Corbat, CEO of Citi, agrees. In a recent keynote at Mobile World Congress, he said, “We see ourselves as a technology company with a banking license." Capital One’s CIO, Rob Alexander, says they are a “software development company that does financial services.” Mary Barra, CEO of General Motors, says she wants the public to “see GM as a technology company rather than an automaker.” Uber, Amazon, and other high-profile companies have made similar comments. It’s a common theme from organizations that have already had their IPO. Pre-IPO companies should take notice and follow their lead because it's what investors are looking for. 

Early investors want to see customer growth, not necessarily profitability. Having a plan to scale using technology can help a company get to a critical mass. For example, Twitter had 321 million users before they turned an annual profit in 2018. That figure would have been impossible to reach without cutting edge technology and processes.

But before you’re a big company eyeing a public offering, you have to start somewhere. When a business first starts, you usually have a founder or two with a good idea and the ambition to match. In a few months, when the concept is market-validated, a few motivated employees are hired. The excited team runs hard and fast but without established processes. Good ole’ fashioned hustle covers up any existing weaknesses. But eventually, the lack of infrastructure and tools catches up with the founders, and the business will begin to falter. If not acted upon quickly, failure is imminent. 

It’s at this point in a pre-IPO’s lifecycle that technology infusion becomes so critically important. It’s smart to set up your small business like it’s going to be a big business and plan for success.

We recommend moving toward standardization and being a cloud-first business. Utilizing platforms like Jira and Confluence keeps projects moving forward and with a high degree of predictability and reliability. Tools like these allow you to scale and will never be a choke point in your growth.   

It’s not just about growth either. It’s about sustainability and resilience. Even established companies like General Electric, Kroger, and Fitbit have found cloud computing success. Investors and boards of directors appreciate the risk mitigation in times of crisis and the flexibility that comes with the updated IT strategy. 

As a startup-founder myself, understanding the cost-benefit technology can bring you is just the first step. The details lie in implementation and design. It will always be worth the investment to bring in an outside consulting firm to design a workflow to reflect your desired processes. Training your team on how to use this technology as the backbone of your operations means you have a system for accountability and quality. Once in place, you can concentrate on building more, selling more, and not worrying whether or not your IT infrastructure can keep up.

Getting to the IPO means your company has joined a very select group of highly-efficient and promising companies of a generation, and the proper technology tools can help you get there faster.

At Praecipio Consulting, we are total Atlassian enthusiasts, so if you want to know more about how Atlassian products can help your business grow while becoming more resilient, we can answer any questions you may have!

Level Set of Terms

Before we dive into today's blog post, let's get familiar with these terms:

• DevOps: A mix of cultural and technology practices to improve the use of software and technology-servicing customers.
• Continuous Integration (CI): Traditionally, a developer spends their day coding, and at some point, they save (commit) their efforts within a development environment or an application branch. Think about a tree. Do you want one full of intertangled branches (loads of developers, all doing something, but getting in each other’s way), or do you want a well-balanced tree with a solid trunk? The same is true with coding, and CI allows for the integration of code to the trunk as fast as possible via agreed testing success. If the system fails (a diseased branch), then the feedback is fast enough that the code can be fixed and resubmitted. Note that the approval and commit steps are manual but the expectation is that they are performed daily at a minimum.
• Continuous Delivery (CD): Removes the manual step and introduces automated approval based on testing success to push software to the trunk. CD eliminated the authorization wait time found in CI, thereby decreasing the feedback time. Faster feedback equals faster fixes, which underpins the culture of “if no defect found, then proceed to the next step in the software value stream.”
• Continuous Deployment: I call this the ‘Trust My Developer’ process. Testing, packaging of code, release, and deployment (to the correct trunk or environment) are as automated as possible. We trust the process, the tools, and the quality of the code, and therefore we know that if there is an issue, we can also remove any code causing problems as quickly as possible. Feedback from the customer on the new applications or features is immediate.

How we created these practices: A bit of history

Software is what makes technology exciting, as it is often the software elements that make things happen, solve problems, or fulfill needs. It stands to reason then that the flow of software to a customer needs to be as fast as possible. Unfortunately, in many businesses today, that flow is a mixture of work, wait time, approval time, and probably rework. 

Does your software stream look like this?

• Receive the request for something to be changed (new, feature or fix)
• Wait
• Get it approved
• Wait
• Pass it to a team as something to do
• Wait
• The team at some point begins to work on it
• They finish their work and pass it to another team to add their code, or they give it to a test team
• Wait
• The test team schedules the environments for testing: code, security, performance, business continuity
• Wait
• After authorization, the code is deployed at the pre-set monthly or quarterly release
• Wait
• The code is released
• Pray that it works and that things have not changed so much since the original request

Do you recognize your lengthy cycle of innovation? It doesn’t have to be this way, thanks to the practices of DevOps: Continuous Integration, Continuous Delivery, and Continuous Deployment.

Timewarp to today

What do your staff or customers want? Quality, fair cost, sustainability, resilience, and practicality. They want technology that helps them and, preferably, they want it now. Given the interconnectedness of the world, if a customer does not find satisfaction with you, then they go elsewhere within a mouse click. Your business peers can also do the same, hence this is how Shadow-IT (when peers circumvent formal IT processes) begins.

But what if:

• Requests are assessed within a short time of receipt?
• When the team began working on the request (either some aspect, if not the full request), was ready it for use within a sprint (two weeks to a month)?
• As much as possible, the culture is that if no defect is found, the request moves to another team or goes live?
• If the request can be improved, then how?

Jez Humble and Dave Farley best explained these practices in their book Continuous Delivery. Major software vendors such as Atlassian built their products based on these concepts (and have an excellent series of blog posts showing the why and how). It is becoming more and more difficult to find a business that does not depend on software, so why have processes that limit the use and improvement of your products or services? Sounds like nirvana (or a significant culture change).

Some of you by now are thinking that this can never happen where you work. I won’t quote how many times a day banks, Amazon, or even the latest start-ups that were born during the pandemic, deliver software to customers.

Tip: Look at sites from mature DevOps companies like Netflix and Amazon, and make that your goal so that you can work towards creating meaningful change within your organization. 

The CICDCD+ culture:

• No defect goes live
• No defect goes to the next environment
• Ideally have no more than three environments; two is even better
• Automate as and when we can
• Test multiple times, as often as we can
• Trust in the tools we use
• Trust in the people that use those tools
• Ability to roll back (uninstall code) as quickly as we can promote code
• Limit the amount of work performed at any given time
• Limit the size of our changes (make smaller changes?)
• Changes are independent of the application or data (yes this is hard)
• Every day is a new day during which we strive to improve the process

The Gap of Change: Are you ready?

CI implies that your organization wants to create and improve a pipeline of software to your customer. You also agree that management is going to allow the technology and governance processes to be available to develop, maintain, and improve the pipeline. CD also implies that you are satisfied with the flow of software, the timely feedback of information related to software value, and issues are resolved before working on other code. Automation is used to automate the approval of changes and the delivery to the appropriate environments or customers.

CD+ implies that you are content with both the culture and technology of software and how development and deployment have matured. You are ready to automate as much of the process as possible. Changes are small and independent enough that if there is an issue, they are quickly revoked. Minor changes also mean that customers get spoon-fed new software, one feature at a time. Documentation and recovery are both simplified, and the cost of software reduced.

Remember that there is no value in anything you do in technology until it is used to help someone fulfill a need or solve a problem. Until that time, everything you do or spend money on is a waste. Limit your waste by trying these practices. In the next blog, we will explore the metrics of CICDCD+, and the final blog of this series will provide tips from the leadership aspect.

If you have any questions in the meantime about any of the concepts discussed in this post, let us know

What is ITIL? The Five Stages of ITIL

As a process consultant for a Platinum Atlassian Solution Partner, my responsibilities include helping our customers set up their ITSM solutions and providing guidance in-line with best practices and industry standards. The ITIL framework has been accepted as a collection of best practices for ITSM and the ITIL processes are designed in a Plan-Do-Check-Act cycle with the end goal being continual improvement. The Five Stages of ITIL are as follows:

Stage 1: Service Strategy - Understanding customer needs and determining which services and capabilities will provide the most value

Stage 2: Service Design - Designing new services or changes and improvements to existing services 

Stage 3: Service Transition - Coordinated effort to build and deploy services

Stage 4: Service Operation - Fulfilling requests, fixing problems and performing maintenance tasks

Stage 5: Continual Service Improvement - Capturing lessons from successes and failures and incorporating those learnings in the process

Getting Started with ITIL and the Atlassian Suite 

Based on the Five Stages of ITIL, I'll walk through how the Atlassian suite of products can help you and your company continuously improve your ITSM offerings.

Stage 1: Service Strategy - Confluence and Jira 

In the strategy phase, you are gathering market research and determining customer needs. Confluence is a great place to document these ideas and requirements. When integrated with Jira, you will be able to create a Jira issue for each requirement from the Confluence page.

Stage 2: Service Design - Confluence

In the service design phase, you are determining the services and service levels based on the decisions made in the strategy phase. You will want to document these design decisions in Confluence. Confluence also has built in diagram capabilities for modeling processes.

Stage 3: Service Transition - Jira and Jira Service Management

In the service transition phase, you will use Jira to track the work on the requirements while you build the services in Jira Service Management. Jira Service Management will allow you to create different services, workflows, permissions, SLAs and automations. You can also customize the portal and what the customers see.

Stage 4: Service Operation - Jira Service Management and Confluence

In the service operation phase, you will use Jira Service Management queues to manage requests and you can communicate with customers through the Jira Service Management tickets. Confluence will be used to document fixes and how-to articles. Customers will also have access to Confluence's Knowledge Base – as a way to identify or resolve in a self-service manner.

Stage 5: Continual Service Improvement - Jira Service Management and Confluence

In the continual service improvement phase, you will use Jira Service Management's satisfaction surveys and documented lessons learned in Confluence to help determine how to improve services. 

After all of this - Rinse and repeat.

Building an ITSM Solution

By utilizing the Atlassian tools, you have many of the recommended capabilities to create a great ITSM solution that is continuously improving. If you don't have the time, resources, or experience to do this yourself – Praecipio Consulting offers an ITSM QuickStart that can set you up with many of these recommended practices (in a fraction of the time it would normally take to design and develop your own ITSM solution). To learn more about the ITSM QuickStart or other services please visit our ITSM consulting offering.

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!

Using Atlassian tools for your DevOps endeavor sets your teams up for success. While there are many challenges in a new DevOps implementation, the tools you use don't have to be one. A quick search will show you that there are many ways to fail at DevOps - it requires massive organizational change and lots of moving pieces to function, so getting started can be tough. It might be a painful process to initiate, but as we've seen, it's absolutely worth it. With that in mind, while you focus on the big questions (Like how in the world can I deploy daily/weekly/hourly?), the Atlassian stack helps you out in some ways you may not have even considered. With one (or all) of these questions out of the way, you can get back to focusing on what matters: the people and processes that you're revolutionizing.

Below are a few common DevOps mistakes that Atlassian can help you avoid:

1. Failing to Automate Effectively

Automation is an essential component of DevOps - and one of the hardest. Rather than finding one product that tries to do a million things well, with the Atlassian stack you've got the killer combination of several awesome products that integrate seamlessly. The native integrations mean that in just a few clicks, your Bitbucket branch creation or pull requests, your Crucible code reviews, or even your Bamboo builds can move your Jira issues through their workflow. This is essential when you're working with several different tools - trying to keep track of where the work is will slow you down and has the potential to delay important milestones. Additionally, while the Atlassian tools work together like one product, if your team uses an alternative to one of the options, you can integrate them as well with the same ease.

Don't let your work tracker become just another bottleneck - make sure your tools are effectively integrated and refocus your energy elsewhere.

2. Ignoring HA Principles

The best systems aren't worth much if they're not up. When you're committed to High Availability (HA), you need your systems to be up as much as you (and your users) are - avoiding single points of failure, focusing on redundancy, and immediate failure detection. Jira and Bitbucket Datacenter products provide high availability so you can trust your systems will be up when they need to be (which is to say, always).

3. Mishandling Incidents

DevOps isn't just deploying quickly, but managing your code in an intentional way. This means making sure that if something goes wrong, you know it. Jira Service Desk has built in automation to keep work up-to-date and moving through its lifecycle. When you pair that with real-time build information, accurate visibility into things like pull requests and open incidents, then staying up to date is a breeze. Tracking incidents and development work in the same tool means you don't have to jump between issue trackers to know what's going on, and you can set up Jira Software and Jira Service Desk to keep everyone on the same page.

You'll often hear that DevOps is too focused on tools, and that you need to refocus on people and processes. This is absolutely true - the key is to work with tools that help you get out of your own way so you and your team can Get S@!# Done.

To read more about how Atlassian works with DevOps, read DevOps + Atlassian = Doing it Right by Senior Consultant Michael Knight or Top 5 Ways Atlassian Facilitates DevOps by Bryan Robison, Principal at Praecipio Consulting.

NOTE: The following is a guest post by Tricentis Director of Product, Ryan Yackel.

A modern testing platform is a critical, but often overlooked, element of successful agile transformation. Could QA (Quality Assurance) be the missing puzzle piece in your quest to deliver higher quality software faster?

The pace of software development is accelerating, and technology teams face increasing pressure to adopt agile development and continuous delivery models so that their businesses can more quickly respond to customer demand.

But your first-mover advantage will suffer if you are first to market with mediocre software.

If you fail to deliver high-quality digital experiences at the pace today’s users demand, you risk alienating customers. In the case of defect-ridden software, poor user experience, or a catastrophic bug, you risk losing significant market share and damaging your reputation.

Software Testing

In the rush to beat the competition to market, organizations are transforming software development and delivery processes. But too often, business leaders fail to prioritize QA transformation, and QA teams are stuck using ineffective legacy solutions that were built for outdated waterfall environments. The reality is that as long as your testers are using legacy QA tools, your transformation will remain incomplete.

Legacy QA tools like Micro Focus Quality Center cannot accommodate modern development workflows. (Year over year, Micro Focus Quality Center (HPQC) has been among the least recommended testing tools for agile teams in VersionOne’s State of Agile Report.)

Legacy tools do not integrate with open-source automation tools, which limits testers’ options for accelerating test cycles and makes it impossible to integrate QA into continuous delivery pipelines. This means QA teams lack visibility and are not able to test new code as it is written. Development is further delayed when developers cannot quickly access test results and mitigate issues QA has found. As a result, releases are delayed, and quality inevitably suffers.

When testing occurs at the end of a development sprint, bugs are often embedded in the code, where they are significantly costlier and more time-consuming to correct. As a result, the myth of the QA bottleneck persists. Or worse, the QA process is rushed, and organizations end up with defect-ridden releases that fail to provide the high-quality experiences their customers demand.

Development and QA

If you can integrate quality into agile and DevOps processes, instead of treating it as an afterthought, testing can occur almost simultaneously with development. When a tester finds a bug, he or she can alert a developer to address it right then, instead of after lines of dependent code have been written on top.

With the right approach QA can help speed development by helping developers identify potential defects early. That means that QA is no longer pressured to complete testing quickly as the last step in a sprint. With a truly agile testing approach, QA can become a strategic enabler of business success, rather than a bottleneck.

Integrated Testing

Successful agile organizations have adopted modern test management tools like Tricentis qTest to successfully integrate testing into modern development and delivery processes. Tricentis qTest offers a real-time Jira integration and centralizes test automation management across frameworks and tools – including out-of-the-box integrations and a robust API for test automation management. qTest also offers testers in DevOps environments a single platform for unifying tests that run through continuous integration with other tests.

Contact us to learn more about how we can help you accelerate your agile transformation by modernizing testing.

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. 

Our partners at Puppet and Splunk recently released the State of DevOps Report 2018 which mirrors many of the same observations that we see when working with our customers. DevOps isn't a sprint, it's a journey, depending on the organization's size, that can take organizations months or years to master. Instead of focusing on statistics like in prior years, this year's report introduces the five stages of a successful DevOps evolution and identifies and describes the practices successful, mature organizations have implemented during their journeys. The report has something to offer to organizations no matter where they are in their process. Even if your organization has employed DevOps for some time, you may be missing a critical component of your implementation.

Five stages in a DevOps evolution

The major takeaway from this year's report is that while there is no single path to a DevOps transformation, there are five foundational practices and five distinct stages of a successful DevOps evolution. Each stage is comprised of a set of practices broken down between "defining practices" and "contributors to success" which are identified and described for each stage of the process in the image below.

(State of DevOps Report 2018)

As organizations evolve from stage to stage, they refine and expand on the practices they implemented in prior stages. The report dives deep into the identification and makeup of each practice and describes how establishing practices identified as contributors to success in earlier stages such as "test infrastructure changes before deploying to production" in Stage 1 become mission critical defining or associated practices in later stages. DevOps is not a sprint, but a marathon, and requires organizations to have effectively executed each stage before advancing to the next one. Quite often we see that even the foundational practices such as monitoring, testing, and configuration management described in Stage 0 are missing from our customer's toolchains.

DevOps starts with a ripple

We frequently hear stories from our customers about how they began using Atlassian tools. These stores often begin with when a single team purchased a Cloud account or installed Jira onto a server sitting under someone's desk. Usage evolves and expands over time and eventually, the whole organization is reliant on the application for mission-critical operations. The report found that the DevOps evolution begins in much the same way: starting with a single team who defines their own practices for DevOps and shares them with other teams within the organization.

Where do I start?

The State of DevOps Report 2018 recommends starting with production by choosing an application with an, especially painful deployment process. We often describe DevOps as breaking down the wall between Development and Operations and deployments are where frictions between the two often occur. By automating deployments teams can improve collaboration and communication while reducing the friction caused when things go wrong. 

Since 2010 (before DevOps was called 'DevOps), Praecipio Consulting has been fortunate to work with customers at all stages of the DevOps evolution and guide them in using Jira, Confluence, Bitbucket, Bamboo, and other tools like Puppet, Splunk, New Relic, xMatters, qTest, and AWS as part of their technology standard. 

To learn more about how Praecipio Consulting can assist you with your DevOps journey, be sure to register for our upcoming webinar "DevOps: An Interpersonal Approach" on October 10!

As with life, the only constant in DevOps is change. To position your teams to seamlessly flow with the changes and to empower them to innovate, some of the old ideas on Operations and Development practices must be left behind. An integral component of DevOps is culture. An iterative approach to a collective ownership should be taken when planning your move toward a DevOps environment. You can start your DevOps journey by advocating for the adoption of a consolidation of tools designed specifically for DevOps, which provides an environment of transparency and ease of use.

Agile

Adopting Agile development practices, iterative planning and short cycles can alleviate the frustrations that fester as ill-planned deadlines are not met. Developers will be more empowered to meet shorter competitive deadlines while working appropriately planned sprints and have more time to innovate and experiment. Agile development will also be far less likely to produce bugs that are difficult to locate and fix.

Continuous Integration

Adopting the use of CI, you can avoid code that may have to be completely redone when it fails in production. Tests performed on small changes to the code, committed several times a day, have proven to be less prone to failure. Smaller changes lead to higher quality, have less risk, and allow for easier code reviews and locating problems.

Infrastructure as Code to define test, prod, and other environments has proven very successful. Self-service infrastructure for developers to have provisioned, tested against, and disposed of, can bring your team to a place of continuous learning and experimentation and make reactive scrambling to determine what is broken a thing of the past. Utilizing these methods, environments can stay in closer parity with fewer differences and remove the surprises when tests pass on the test environment, but fail in production deployments, as tests are more complete and valid.

Monitoring

Monitoring infrastructure, operating systems, application, and third-party cloud services are crucial in observing trends, understanding the health, and receiving an important feedback loop. Tying all of the monitoring together with a tool specifically designed to do so, and having alerts visible to everyone involved will provide transparency, trends to act proactively on, and ensure that the end user is receiving the highest quality product.

ChatOps

ChatOps is not the same as IM, or instant messaging. ChatOps tools have the capability to integrate with other tools. Seamless integration makes statuses of all the components transparent at all times. Utilizing ChatOps in your DevOps environment provides faster and continuous communication at all phases, from planning to a commit to a production deployment and its effect on the end users.  

Continuous Communication

Select tools that enable continuous communication.

Feedback loops should be real time and visible to teams at all times.

To consider your environment DevOps, you should be in a state of constant and iterative improvement. Agile practices, CI, Monitoring, ChatOps, and the flow of Continuous Communication are all necessary steps to reach this goal.

If you're still interested in our approach to DevOps, be sure to register for our upcoming webinar "DevOps: An Interpersonal Approach" on October 10!

Investing in technology should be exactly that: an investment. Technology should accelerate your business and allow you to deliver products and services to your customers more quickly. In a word, DevOps. At Praecipio Consulting, not only do we help organizations adopt DevOps best practices, but we work in it every day with our products and even within our services organization. Investing in the right technology to drive your DevOps initiatives should net you a significant ROI, but why?

At Praecipio Consulting, here's why we believe in DevOps:

• Deliver value faster and more efficiently
• Deploy more frequently, fail less, and recover faster
• Unleash the power of high performing employees

But how do you measure the ROI of that investment? Start by measuring the bottom line of your employee's impact.

You can measure the potential impact of savings and value by calculating the Cost of Downtime and Cost of Excess Rework happening in your organization. DevOps helps companies reduce waste by eliminating costly hand-offs and rework. The best way to measure this impact is to calculate these costs and establish a Key Performance Indicator (KPI) that focuses on reducing these costs. First, let's look at how these two are calculated:

Cost of Excess Rework

Cost of Excess Rework = Technical staff size × Average salary × Benefits multiplier × Percentage of technical staff time spent on excess rework

At a moderately performing small- to medium-sized business with 250 engineering staff, times $105,000 average salary, times an average benefits multiplier of 1.5, times 22% of technical staff time spent on excess work equals $8.66M (cost of excess rework) *

250 * 105,000 * 1.5 * 22% = $8,662,500

Rework can come in many forms: Defects, missed requirements, unused or poorly written tests or test cases, repetitive manual actions, etc.. While there is no way to completely eliminate rework, there are ways to reduce it through the automation of processes in key points of your DevOps lifecycle. Assuming the Technical Staff size, average salary, and benefits multiplier are fixed, the reduction in the Percentage of technical staff time spent on excess rework will have the greatest impact in moving the KPI to reduce this cost. Review your current manual or repetitive processes and automate them. Even small changes can make a big impact. If we reduce the rework percentage by five percent: 

250 * 105,000 * 1.5 * 17% = $6,693,750

That's a reduction in cost of $1,968,750! 

Cost of Downtime

Cost of Downtime = Deployment frequency × Change failure rate × Mean time to recover × Hourly cost of outage

At a moderately performing organization that features 32 deploys per year, times 38% in change failure rate, times 2 hours mean time to recover, times $500,000/hr cost of the outage, equals $12.16M. (cost of downtime) *

32 * 38% * 2 * $500,000 = $12,160,000

While you instinctively know that downtime is expensive, you also know that downtime is inevitable. Instead of implementing complicated or burdensome change control processes to eliminate this risk, focus on the change failure rate. While there are other ways to reduce costs by reducing the mean-time-to-recovery, which we address here, allowing teams to continuously deploy to production-like environments automatically means a reduction in the change failure rate. As we saw above, even a small change can make a big impact. If we reduce the change failure rate by five percent: 

32 * 33% * 2 * $500,000 = $10,560.000

That's a reduction of $1,600,000!

Keep in mind, the examples above are based on a moderately performing organization. These are ‘on average’ numbers, and it is important to take the costs of your organization and apply them to these formulas. The costs will only go down as performance increases when you streamline processes and adopt DevOps.  Also, remember that every organization is different, and every organization has its own business model, but you get the idea.

Knowing these formulas will help you establish a greater cost savings and a higher value proposition to your organization and customers. You need to start looking for the right tools and training to make your technology transformation a reality.

What could your organization do by recovering this lost time and resources?

• Allow additional brainpower to be dedicated to innovation? DevOps training, with proper implementation, will increase your organization’s productivity and create a culture of high-performing, innovative teams.
• Purchase tools that allow for tighter integration and automation? DevOps tools, when using agile methodology, work best to track planning, building, continuous integration, deployments, operations, continuous feedback and team collaboration. Giving a better view of the Big Picture. 
• Deploy quality products and/or services quicker, with fewer bugs? High performing DevOps teams deploy 200 times more frequently with 2,555x faster lead times.
• And the list goes on…

Knowing how to determine the cost of downtime and excess rework are two key factors in calculating your DevOps ROI. Add this to the right tools and training and you have a formula to streamline processes and improve outcomes while saving on cost.

The Praecipio Consulting formulas:

Tools + training = process improvement

Process improvement = cost savings and increased value (goal)

Our knowledge and expertise of DevOps processes and the Atlassian Suite can help our clients operate more efficiently, at a lower cost, and with greater results. Our time-tested delivery model ensures you see measurable ROI from your Atlassian tools.

Looking to make a DevOps transformation? Contact us today.

* = 2016 DevOps Data Report

https://www.praecipio.com/webinars/portfolio-for-jira-best-practicesIn our last blog post, we shared with you how Portfolio for Jira can be used to plan and visualize work for any department or line of business. Now that everyone has a seat at the table, let's make sure the meal is excellent by following a trusted recipe for Jira Portfolio best practices.  

There are only two simple ingredients for a successful Portfolio implementation: Jira configuration and data integrity. 

Jira Configuration

It's important to make sure your Jira entities — workflows, projects, boards and filters — are configured correctly. While this may seem like common knowledge, some organizations overlook even the simplest mistakes when configuring their Jira instance - it's important to make sure you cover all the basics early on.

 In addition, Portfolio entities must also be determined, such as hierarchy and parent links, dependencies, and permissions. Portfolio is customizable to fit your organization's needs, and like the importance of making sure your Jira instance is configured correctly, the same goes for Portfolio - its imperative that the time is taken to set up your instance that best serves your organizations needs. 

To start, you should determine a level of organization that is larger than an Epic. If an Epic is 3-5 Sprints, this larger concept should represent a longer timeline: perhaps 6 months. You can call it anything you want, but we commonly use 'Initiative,' which is Portfolio for Jira's native language. With the Epic Parent created, Portfolio's configuration needs to know you're adding a level, and then have it mapped appropriately to the issue type. The next issue type to be created is called a 'Story,' which will include all other standard issue types, and will live between an epic and a sub-task. You can use whatever taxonomy works best for your organization; however, we have one recommendation - keep it simple! 

Adding the 'initiative' level allows your team to not only get a birds-eye view of your entire plan, but also how it aligns with overall business goals

Also part of your configuration recipe is the creation of a scrum board. Boards in Jira Software are driven by filters, and you should group them into a project or project category.  A word to the wise: Don't append your query with clauses that would remove workflow statuses or remove a specific tag of work. Let the board drive what your plan would display. Keep in mind if it's on your board, it's going to be in your plan.

Now that your Jira configuration is cooking with gas, let's dig into data integrity.

Data Integrity

Portfolio brings projects and plans to life; however, its powered by the data inputted into Jira. You've heard the saying 'garbage in, garbage out', right?' Avoid bad data at all costs and follow these simple steps to keep you Jira data clean.

You can start with keeping your backlog groomed by simply resolving and closing your issues. Closed issues will disappear from your backlog and will no longer show on your board, which means the Portfolio won't display them in the plan, either. Not only is this good practice in general for Jira Software, but it will keep your Portfolio plan accurate. If you have a task or issue that has been sitting in your backlog for a year or two, it's time to clean the pantry.

Maintaining hierarchy in Jira software is critical when using Portfolio. You must close out lower-level items before closing the parent - if you complete sub-tasks and close them out, it doesn't mean you're 'in progress' in the hierarchy. No progress will be seen on the story, epic or initiative just because you close or resolve a sub-task. You should be focusing on story completion and story throughput, instead of progress at the sub-task level. Make sure you are closing and completing story level to show progress in your plan overall - again, this will maintain accuracy in planning and forecasting.

Closing your story-level tasks will show your plan's overall progress

This blog post is full, but you can come back for tasty seconds and thirds in the Portfolio for Jira: Best Practices webinar coming up on November 30 at 11 a.m. CST.

It's only a few days into the new year, but already we see the latest tech crazes for the next 346 days in the headlines: DevOps, ITSM, and SAFe. With Atlassian, the world's industry leaders have had great success in these frameworks (many with our expert help) and technology is producing the most ground-breaking things in human history. Everybody wants to put a proverbial man on the moon with their next release, and these are the proven methods to do so. 

But one integral factor in the equation remains- beyond products, beyond methodologies: human beings. Behind each of these revolutionary web applications, overseeing each of these cutting edge processes, are our most important resources: our team. We must automate our technology to give us more time to collaborate with each other; to facilitate the tribal knowledge sharing that allows a community – a business – to thrive and grow. 

In a recent presentation, Praecipio Consulting partner, Christopher Pepe remarked on the paramount asset of human knowledge within organizations. Behind each great innovation is a team who did their work to the best of their ability to reach this next level. People are the ones who make DevOps, ITSM, and SAFe the successful frameworks they are. People are the ones who developed Puppet, Splunk, Tempo and Atlassian to help us do our jobs more efficiently. We choose and configure our tools in the most advantageous way to give us both the best competitive edge and to, ultimately, free up our resources (our people) to come up with the next, history-making idea.

Each of these products and frameworks enables us to be more efficient. To build things faster, better, and smarter that help us (and others) do the same. With that time we save - be it programming an application to triage errors to give back support time, or an app that helps you order groceries for pickup so you have an extra hour to spend with your family. The things that will move our industries (and our world) to the next phase are being created by the companies that configure their tools to give them that time. We know - we've helped them.

Everybody says they will give you your greatest technology ROI. When we say that, we mean that we're sending the best team in the world to help YOU be the best team in the world. We have the knowledge and the expertise to put your proverbial man on the moon - whether that's breaking the Fortune 500 or doubling the size of your new business in a year. Our clients and partners (like DocuSign, Splunk, and Tempo) are a testament to our commitment to delivering this ROI to you at exponential rates. We don't just care about you getting a functional product - we want to see you use it perform optimally so you can go back to what you're passionate about. 

Give us a shout and let's talk about your most valuable resources- your team- and how we can get you the technology solutions to focus on their best work. We're ready to help you get to your proverbial moon. 

As Development and IT Ops teams look to be more efficient, decreasing their time to market and increasing product support, DevOps has become the predominant industry solution. There are many resources that paint a picture of the ideal processes for Development and Operations working harmoniously together- but how do we actual get there? Where should we start? 

We need to begin with the end in mind. Our end goal is to deliver customers the software they need as fast as possible. The software industry is faster and more dynamic than the businesses of physical products. We need to get our customers features so they can give us crucial feedback while beating our competitors to market. The faster release development goes from concept to code, the quicker we can make customer happy. DevOps is a broad term with a variety of meanings, but at the end of the day, it seeks to increase the collaboration and automation between Development and Operations so we can get more frequent and higher quality releases into the hands of our customers.

When it comes to collaboration and automation, a focus on process and the use of the Atlassian suite are the best way to get there.

 The infinite loop of developing and supporting products that customers need and want with DevOps and the Atlassian Suite.

Image source: Atlassian 

Selling DevOps

The pain of hectic firefighting and troubleshooting make the need for DevOps obvious on the frontline, but getting alignment and investment at the organization level can be pretty difficult. Successful implementation is going to require buy-in and support from a variety of stakeholders and many levels. Before we can get our hands dirty, we need to convince everybody to spend the time and money to get these processes and tools in place.

Here are three ways to get the ball rolling:

One for the Book Club: Phoenix Project

Everybody has those business books that revolutionize the way they manage their work and companies. The Phoenix Project by Eugene Kim narratively addresses and exposes the gaps in processes between teams and points to a DevOps prescription to unblock cross-team work. We highly suggest recommending it to your teams, as it's a great way to get everybody on the same page and really see the value of DevOps.

Build a Business Case

At the end of the day, businesses exist to make money. To invest time and effort, we need to calculate the business return. The 2016 DevOps report from Puppet Labs does a brilliant job showing the financial reasons to adopt this shift.

The ROI of reducing excess work with DevOps according to 2016 DevOps report from Puppet Labs

Image Source: Puppet Labs

Phase 1: Go Agile

To get the real benefits of DevOps, it requires a shift in mentality and how we manage work through our teams. As we break down our requirements into smaller individual user stories, we can flow the work through the features through the process faster. By having the structure, ceremonies and processes in place to accommodate smaller pieces of work, we can get our customers the features they need and incorporate their feedback to iterate the next, improved release faster.

Here are some helpful ideas to help your teams go more Agile: 

• Educate | Get your team up to date with the basics with Atlassian's wealth of knowledge and how to do Agile in the Atlassian tools (for Product Owners too!)

• Get Up, Stand Up | Simply doing stand-ups doesn't mean you're all the way agile, but it's a great way to get our teams into the mindset. Keep them short and reduce the headaches of status updates and emails. Fill everybody in on what you did yesterday, what you're doing today, and what pesky blockers are in your way. It's facilitates more agile and responsive team collaboration and support (the heart of DevOps).

• Iterate Everything! | Speed up that Agile transformation, breaking down your waterfall projects into smaller sprints so you can always reprioritize and adjust as needed. Start with your software teams and spread out to your IT Ops projects and even marketing projects. Start in your own department: find the planning spreadsheets with those idealistic due dates, set up a backlog, and start sprinting!

• Agile Boards | Once you're planning and executing in sprints, track and visualize it on a Jira Software board. Avoid those dreadful status meetings and send out the link to the board to keep everybody informed. Also, throw some wallboards up around the office so everybody can see your team killin' it. 

You'll know you're a lean, mean, agile machine when your software teams are cranking out stories in a steady cadence of sprints. Over time you'll see that velocity stabilize - then you can accelerate!

Phase 2: Get with Gitflow 

Git and Gitflow is a great way to help our dev teams increase velocity. As we're working with smaller stories, we need to be able to collaborate effectively with on our code base so we're not stepping all over each other. Version control systems of the past aren't going to be able to keep up with our blazing fast development teams. Bitbucket and the underlying technology of git are going to let our teams build user stories and merge them into the code base without wasting time messing with annoying versioning issues and costly code conflicts. 

• Start with the Basics | Start by learning (allthethings) about how to effectively manage your branches and build in code quality with Atlassian's Git Tutorials and the Git Getting Started guides. Share them with your team so everybody's on the same page and knows the difference between a commit and a pull request.
  
  
• Move to Git | If you haven't made the cutover to Git quite yet, get your team and managers onboard by sharing the benefits and how it will help ship more code. Once folks are convinced, learn why Bitbucket is the Git solution for professional teams and helps with pull requests, branching strategies, permissions and scalability. When it's time to actually move all that code over, see how we helped Splunk get git and 4 times the number code reviews completed. 
  
• Start Branching | With the tools in place, it's time to start branching! Learn more about some common workflows to better handle branches here. Utilize those pull requests to build in code quality as you go. Eventually your Dev team will be humming with full Gitflow and your Ops teams will be in love with the clearly designated branches.
  
  
• Automate, Mate | The marvelous integration between Bitbucket and Jira Software lets us automatically update the Jira issues based on what's going on in Bitbucket. Developers don't need to switch context anymore to keep the ticket up to date, and the whole team gets an accurate idea of what's actually going on. Check out our Automation Webinar to learn more about the powerful workflow triggers that make this possible.

The Gitflow branching strategy shown above utilizes different branches for specific roles like hotfixes and releases to help manage larger and more complex projects. 

 Image Source: Atlassian

Phase 3: CI/ CD

The next phase is how we define the crucial handoff between Dev and Ops. When our units of work and code changes are smaller, we're going to need to deploy more often to get those features to our customers. Before we ship it to the ops team and production, we need to ensure quality as our individual features come together. This is where good Continuous Integration/ Continuous Deployment practices along with Atlassian's Bamboo are vital to successfully shipping our product. Catching bugs and issues before they go to production is going to help both the Dev and Ops teams sleep better at night.

• Learn about Bamboo | For on-prem Atlassian users, Atlassian's Bamboo is the CI/CD solution that allows professional teams to build their CI/CD pipeline. You may be using Jenkins or other open source teams, however the deep integration points and improved build management make it the right choice for professional teams.
• Integrate with Jira | Once you have Bamboo up and running, leverage the integration between Bamboo and Jira Software.
  
• Bitbucket Pipelines | If you're an Atlassian cloud user, Bitbucket Pipelines is a new, powerful solution in Beta that lets developers build, test and deploy directly from Bitbucket. Developers have the power as they can define the environment and tests for their specific branch with YAML file style configuration.
• Dockerize Everything! | Docker and containerization is the latest craze sweeping the IT world as teams look to deploy applications to any environment faster and easier. Check out our Docker +Atlassian webinar to learn more about how. As partners with Docker, we love to helping teams harness this cutting-edge technology.
• Automate Testing | Automating testing with tools like Charlotte, QA Symphony, and Zephyr (which integrate with Bamboo and Jira) gives your development team an even more agile edge. Get efficent, high-fidelity testing to expedite the finding and squashing of bugs to ensure your next iteration is the best version.

Phase 4: Harmonize with Support

Once the story is shipped, the process does not end. Now it's time to keep the product working and collect that vital feedback we need.

• Check out our webinar, DevOps with the Atlassian Suite, for a full picture of how development and operations are going to work in harmony.
• Set up a product feedback service desk in Jira to really hear your customers and integrate directly with development teams.
• Learn how to set up your Service Desk teams for success with our ITSM webinar.

By implementing the right DevOps tools and processes, you'll see the faster shipping of higher quality and better supported releases. As your Development and Ops teams continue to execute these lock-step processes, you get more agile by good practice. Take the steps to start implementing DevOps today by contacting us to get up and sprinting.

The value of this practice is that the traditional power struggle and finger pointing between owners of two different phases of the delivery process – building vs. supporting – is replaced with a faster and more flexible team that delivers higher quality output. In fact, Puppet Lab's 2015 State of DevOps Report found that high performing IT teams who embraced DevOps reported 60 times fewer failures and 168 times faster recovery rate. They also deployed 30 times more frequently with 200 times shorter lead times!

In order to maximize and reinforce DevOps best practices, teams need the right tools and infrastructure to support their mission. What started as a software company for software companies that now serves 50,000+ organizations like Facebook and NASA, Atlassian offers a suite of products that support the most agile development processes, including DevOps. By encouraging visibility, prioritization, automation, continuous integration, and documentation, Atlassian empowers DevOps to deliver the most value to the end customer.   

Visibility

The Atlassian suite promotes visibility and transparency internally within the company and externally for clients. This ensures that no one is left in the dark about issues that may arise and encourages accountability for all. Let's say, for example, that a customer has reported a software bug by submitting a Jira Service Desk ticket. A customer support representative then updates the status of the ticket to "Investigating" and begins to explore the problem. (This act notifies the customer that her problem is being looked into.) When the rep tracks down the problem and realizes that it's a replicable bug, he marks the issue as high priority, adds internal comments describing the problem, and transitions the status of the ticket to "Confirmed." Using the Jira add-on, Bob Swift Create on Transition, the status change automatically creates a new bug issue in the dev team's Jira project, copying over relevant information and linking it back to the original issue. This transparent process benefits the customer in that she stays informed about what's going on (and feels that her problems are important to the company and being resolved), and it benefits the DevOps team because they have end-to-end understanding of the problem at hand.

Prioritization

With a constant stream of requested work coming from both internal and external sources, it's sometimes difficult for a DevOps team to prioritize effectively. Huge and costly problems can arise when fires aren't triaged appropriately and put out in time. Atlassian can help with prioritization through filters that identify different issue statuses during a workflow and automated alerts using email or instant messaging. Going back to our example, the Create on Transition add-on serves as a filter between customers' service requests and the DevOps team's Jira project. Instead of getting flooded with tickets, the team can rely on customer support to verify and submit bugs on behalf of the customer, embedding prioritization into the process. If issues are automatically assigned, Jira can notify team leads by email when a new bug issue enters the team's project. If newly created issues are not automatically assigned, the team can rely on ChatOps using dedicated HipChat rooms for individual projects or even priorities within a project. Jira can create automatic notifications that appear in HipChat, and devs can click through the message directly to the Jira ticket. This integration allows for immediate response and keeps the team focused on what's important now. 

Continuous Integration 

Continuous integration (CI) is an agile practice that requires devs to consistently integrate code into a shared repository, allowing teams to detect problems sooner and without the extensive backtracking. Atlassian's suite of products work in unison to make continuous integration happen seamlessly. After fixing the aforementioned bug, a developer can commit her changes in her Git feature branch and push them up to Bitbucket, which then kicks off a build in Bamboo. When her build and test come back clean, she creates a pull request to merge her code into master. Once her change is approved and merged into master, the release manager builds and deploys the updated master branch to Bamboo. This tight integration of Git, BitBucket, and Bamboo – paired with some marketplace add-ons – allows for a seamless hand-off from development to operations and back again.  

Automation

With complex and intertwined workflows involving multiple stakeholders, automated triggers save teams valuable time and energy by taking care of redundant or peripheral tasks. Going back to our example, when a workflow trigger picks up on our developer's merged pull request, it transitions her issue from "In Progress" to "Done." This status change then triggers a post function that invokes the Jira add-on Bob Swift Update on Transition. The add-on updates the original Jira Service Desk issue submitted by the customer and adds a comment that says the fix will come in the next release. Automation allows our developer to maximize her time completing actual work, like squashing bugs and creating hot fixes, instead of devoting time to process compliance. (A DevOps team can even create automated CI builds in Bamboo to ensure code quality.) Automation keeps the customer happy and in the know, while taking out an unnecessary layer of communication between development and customer support.

Documentation 

During the entire end-to-end process, Atlassian tools capture and log information at every point in the workflow, including hand-offs, in the form of status changes, comments, or the like, and this history is archived by versions. By leaving behind a well-documented trail of breadcrumbs, teams can better understand the complete story of a workflow. They can identify what went well and what didn't in order to plan for continuous improvement. Furthermore, documentation helps the next developer pick up where a previous developer left off or replicate their workflow, leading to scalable organizational knowledge. 

By adopting DevOps and supporting the effort with Atlassian tools, teams can create conditions for delivering value faster, more sustainably. By improving quality – and thus value – through visibility, prioritization, automation, continuous integration, and documentation, organizations are able to increase profit without increasing operation costs and encourage a culture of continuous improvement. To learn more about how DevOps and Atlassian can empower your organization to work faster and smarter, contact Praecipio Consulting.

ABOUT BRYAN ROBISON

Bryan is Principal of Technical Delivery at Praecipio Consulting where he helps clients implement Atlassian's developer tools and provides technical guidance across Praecipio Consulting's lines of business. When Bryan isn't delivering best-in-class business technology solutions, he enjoys a good crawfish boil and some quality time strumming his guitar.