SAFE_Case_Study

Stay SAFe® with Jira: A Case StudyNavigating the Perfect Storm with Isos TechnologyIntroductionWhile Agile may have been seen as anexperimental replacement to the traditionalWaterfall approach of delivering projects a few shortyears ago, it has now become an industry standard.As with any methodology that gains traction,imperfections can begin to show. In the case of Agile,one of the most obvious shortcomings is operation atscale. While Agile shines among smaller teams, it canbe complicated to implement at a larger scale.Fortunately, with the maturity of Agile, there has beenmuch theory crafting into how to operate at scale,resulting in approaches such as Scrum of Scrums (SoS),Disciplined Agile Delivery (DaD) and Large Scale Scrum(LeSS). The most popular of these approaches is theScaled Agile Framework (SAFe®).Paralleling the rise of Agile is the rise of Jira from Atlassian.Initially a bug tracking tool targeted to the needs ofsoftware developers, Jira has evolved into so much more.As new features have been added over the years, Jira hasmoved beyond its bug-tracking roots to become apowerful tool for managing all types of projects, fromsoftware development to business practices to servicedesks. It is because of this that 78k+ companies use Jira.What follows is a discussion of one of Isos Technology'sclients and their desire to transform their use of Agile.This client, a large geo-distributed organization with30+ active products and an immediate need for Agileat scale, required the right tooling to properlymanage Agile. With an Agile transformation loomingand a management team energized by thepotential seen in their recent SAFe training, theywere ready to move full-speed ahead. Step one:get the right tools for the job. In this case, Jira.Before we delve into our client's goals, let’stake a step back and elaborate on SAFeand Jira. Copyright © 2018. Isos Technology. All Rights Reserved. SAFe and Scaled Agile FramCoepwyorrikghatre©r2e0g1i8st. eIsroesdTteracdhenmoloagrkys. AofllSRcigahletsdRAegsieler,vIendc.. All othAelrl ttrraaddeemmaarrkkss aanndd rreeggiisstteerreedd ttrraaddeemmaarrkkss aarree pprrooppeerrttyy ooff tthheeiirr rreessppeeccttiivvee ccoommppaanniieess..

What is SAFe®? What is Jira?SAFe is an Agile framework designed to address Jira is a powerful software development tool usedone of the perceived weaknesses of Agile – to plan, track, release, and report on software. Itperformance and delivery at scale. While Agile has began as a bug-tracking tool for softwarebeen widely recognized as a superior methodology developers, but has expanded into anfor small teams to quickly deliver value, it is often indispensable tool for all members of businessderided as a solution for large-scale usage. SAFe teams. Its built-in functionality, configurability andprovides a solution by giving organizations a extensions are what have made it the go-to choiceframework capable of continual content delivery at for Agile project management for anscale while following lean Agile best practices. For ever-increasing number of organizations. For moremore information on SAFe, visit their website: information, visit the Jira website:https://www.scaledagileframework.com https://www.atlassian.com/software/jiraA Pragmatic Approach to SAFeThe client's management team, fresh off of SAFe training, was interested in putting into practice what theyhad learned. They wanted to address extensive inter-product and inter-team dependencies that wereaffecting efficiency and quality within their organization.They also relied on a push model with their releases. Changes would be pushed out and releasesconsidered done, though this approach did not afford the ability to get client feedback. Instead, clientfeedback would either bubble up through Tier 2 support requests or be rolled into features for futurereleases.The organization felt SAFe would help them overcome their obstacles. Armed with clear objectives and theidentification of Jira and SAFe, the client started down the path to implementation. They were particularlyinterested in a few core SAFe concepts: 1. Program Increments (PIs) and PI Planning 2. Agile Release Trains (ART) 3. Weighted Shortest Job First (WSJF) Copyright © 2018. Isos Technology. All Rights Reserved. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. All other trademarks and registered trademarks are property of their respective companies.

Program Increments (PIs)Program Increments (PIs) in SAFe are analogous to Agile iterations. They provide a timebox for aligningdelivery across teams at a larger scale over a larger timeframe than standard Agile iterations. These PIs arethen further divided into iterations, common to the teams in the Agile Release Train. Using PIs aids inlarge-scale planning while controlling the amount of work in progress, providing measurable contentdelivery improvements. More information can be found on the SAFe website:https://www.scaledagileframework.com/program-increment/Solution DO DO PDCA ADJUST ADJUST Program Increment PLAN Program Increment PLAN Program Increment CHECK CHECKAgile Release Trains (ARTs)Where PIs are analogous to iterations, Agile Release Trains (ARTs) are akin to Agile teams. The scale of anART is significantly larger than an Agile team, typically 50-125 people in size. An ART is composed of multiplecross-functional Agile teams. The ART delivers solutions incrementally with the PIs. For more on ARTs, read:https://www.scaledagileframework.com/agile-release-train/ART PLAN DO PLAN CHECKDO PDCA ADJUST CHECK ADJUSTTeam PDCADiagram derived from Scaled Agile Inc. https://www.scaledagileframework.com/program-increment/ Copyright © 2018. Isos Technology. All Rights Reserved. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. All other trademarks and registered trademarks are property of their respective companies.

Weighted Shortest Job First (WSJF)Weighted Shortest Job First (WSJF) provides a mechanism for prioritizing jobs in SAFe. It is a way todetermine how to get the best “bang for the buck.\" WSJF divides the Cost of Delay (CoD) by the job size todetermine job impact. Through this metric, jobs can be properly selected from the Program backlog. Moreinformation: https://www.scaledagileframework.com/wsjf/ Time Criticality User-Business Value BANG Risk Reduction | Opportunity EnablementWSJF == BUCK Job Size/Duration How soon do What’s the revenue we need this? impact or consequences if we delay? If we do this, does it reduce risk or open us up to new opportunities?Starting a SAFe JourneyOur client chose Jira Cloud and Confluence Cloud as the foundation for their SAFe implementation. With Jiragrowing up alongside Agile in the development community, it theoretically had the tools needed to manageSAFe already in place. These could be brought to the surface through proper configuration.As a quick footnote, they also made effective use of Confluence spaces and Zoom rooms to facilitate BigRoom Planning within their distributed teams.With framework and tools in hand, the organization was ready to begin their SAFe transformation in earnest. Copyright © 2018. Isos Technology. All Rights Reserved. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. All other trademarks and registered trademarks are property of their respective companies.

How Did It Go Wrong?So...what went wrong when the client initially implemented Jira, prior to Isos coming onboard?With a tool as powerful and configurable as Jira, if you don’t start on the right path from the beginning, it isvery easy to find yourself lost. This has nothing to do with the general project management or technical skillof the implementers. Even the most adept can quickly find themselves overwhelmed with the nuances ofJira if they are doing complex configuration for the first time.Additionally, SAFe can be daunting for first timers. It requires extensive cultural and process changes, even ifbeing implemented incrementally, as in this case.Combining SAFe and Jira resulted in a perfect storm for this team, preventing either from being utilized totheir full effectiveness. Add into the mix a corporate reorganization and the departure of many productowners, and the organization experienced a compounding of their pains.This is not to say that everything went wrong, but there were several notable problem areas that needed tobe addressed.A common challenge for those using Jira for SAFe is the difference in meaning of the term \"Epic.\" Thisdifference may involve the creation of a custom \"Feature\" type in Jira, or an understanding among Jirausers to treat a Jira epic in the same fashion as a Feature in SAFe.An area of concern was the reluctance of PMs to use Jira. SAFe requires cultural changes, and if you can’tget your culture to buy into the tools you are using, you will eventually fail. There are far too many examplesof this for anyone to be surprised by it. A key factor in their reluctance was due to how they chose toimplement Jira boards.If you have spent any time using Jira, especially at the project management or configuration level, you Copyright © 2018. Isos Technology. All Rights Reserved. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. All other trademarks and registered trademarks are property of their respective companies.

know how powerful Jira boards are. They are the perfect way to know what your team is working on, whereyour issues are, and what needs to be done next. In the organization’s case, they were using the boards in a1-to-1 project mapping. This is great when a PM has a team that is working on only one project, but if thereare multiple projects the boards can quickly lose effectiveness.The board issue also exposed a defect in how Jira projects were being mapped. The organization wasmapping projects to teams. With over 30 products and only six teams, this was not a good approach. Anespecially poignant example of this surfaced with products that were being sunsetted, but were still beingsupported. Members from different teams were pulled into dealing with these issues. Since these peoplecould be pulled from any team, it became increasingly difficult to determine what team members wereworking on from project boards alone.A side effect of this was the lack of a true product backlog. Instead, a to-do list for new issues and featurerequests grew without much management or refinement. This approach is problematic in small projects.For a full SAFe implementation, this is disastrous.Beyond these issues, a few other structural issues were seen. Jira releases were not being used. Neither werelinked issues, which can provide high visibility into dependencies. Additionally, standardization did not existacross projects. Some were using Scrum, some were using Kanban, and all ran however the individualproject managers saw fit.A final issue was discovered during permissions auditing. There were far too many Jira administrators. Thisis a common problem seen in teams new to Jira. They do not have the governance in place to limit thenumber of administrators, often causing problems with Jira.What Was Done to Fix the Issues?The issues our client experienced were a result of implementing large organizational changes withouthaving the necessary experience in Jira. Fortunately, Jira is easily configurable. But without extensiveknowledge of the tool, one can quickly get mired in its complexities. Fortunately, Isos has deep expertise indistilling customer intent into configuration.The first thing we addressed was the project structure and the boards. The organization was using boards ina 1-to-1 mapping with Jira projects, making it more difficult to manage multiple Jira projects at once. This isactually a common issue among users new to Jira. Boards have to have an anchoring project, which leadsto the misconception that a board can only represent one project. However, by properly configuring boardfilters, viewing and managing multiple projects from a single board is simplified. Copyright © 2018. Isos Technology. All Rights Reserved. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. All other trademarks and registered trademarks are property of their respective companies.

Second, the mapping of projects to teams instead of products was a key issue with the implementation. Thereason for this structure directly correlated with the board misconception. This was something that IsosTechnology rectified.Isos guided the organization through a project makeover. Before implementing any of the product-basedJira projects, it was important to take a step back and define project composition. This would be useful laterwhen splitting up the projects.With that theory work done, Isos defined a reference project. This is a very important step in any Jiraimplementation that is overlooked far too often. Reference projects are important from an organizationalperspective to answer the question, “how do we work?” This is important for both veteran employees, as wellas new hires, demonstrating organizational identity. In this case, there was no standardization of howprojects functioned at the start of the engagement with Isos, which added a higher degree of complexity toa SAFe transformation.As part of the reference project creation, additional workflow statuses were added to aid the ProductOwners (PO’s). These statuses aided in identifying issues that needed grooming, additional requirementsand prioritization. Custom fields were also added during this phase to help track WSJF. The vision behindthese fields was twofold. First, they provided visibility for the POs and business on priority decisions based onthe value the teams were to be working on. Second, they would be used for reporting on the value delivered.With the reference project defined, it was now time to work on product-to-project mapping. A project wascreated for every product during this phase, with a final count of over 30 projects. Jira project categorieswere used to associate related products as part of this process. Later in the process, using categories madecreating and managing filters for boards and dashboard gadgets easier, bringing visibility to groups ofproducts.With the new projects defined, board makeovers could begin. The new boards were created to becross-project, showing the work teams were committed to completing. These boards made use of the Jiraproject categories applied to projects during that mapping phase as a base for filters. Additionally, thenumber of columns on the boards was greatly reduced, moving away from the model of every workflowstatus having a unique column.Too Many Columns! Multiple Projects PROJECT PROJECT 1/30 PROJECT 1/30 PROJECT 1/30 PROJECT 1/30 Copyright © 2018. Isos Technology. All Rights Reserved. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. All other trademarks and registered trademarks are property of their respective companies.

Now that appropriate boards were defined, Isos discussed the to-do list approach the organization was currently using. This was changed to actual backlogs that could be properly groomed and maintained. An added benefit of the new project structure was the ability to use Jira’s Cumulative Flow Diagrams. This diagram type was one of the features the organization was excited about when initially considering Jira, but was unable to use due to their original project and board structure. Cleaning the boards gave them clean reports. Cumulative Flow Diagram80 Pending In Progress70 Code Review In Review Done6050403020100 Jun 12 Jun 13 Jun 14 Jun 15 Jun 16 Jun 17 Jun 18 Jun 19 Jun 20 Jun 21 Jun 22 Jun23 Jun 24Jun 11 Now that the product projects were defined, dependencies could be addressed. Prior to this analysis, it was felt that inter-project and inter-team dependencies were huge issues affecting delivery. Though dependencies did exist, they weren’t as extensive as feared. Scope creep and team leeching to Tier 2 support were larger culprits. However, without visibility into dependencies, it was difficult for management to accurately assess this. Additionally, there was a perceived magnification of dependencies due to being unable to see the boards on which issues truly belonged. With organizational changes and the loss of product owners, scope creep ramped up significantly. The original configuration of Jira made it difficult to easily recognize scope creep, which is far easier to identify at a product level, as opposed to a team level. With the new structure and boards, scope creep was more readily identifiable. The support of sunsetting products was also a huge factor in decreased delivery performance. It was hard to visualize and control this in the initial Jira implementation. The solution to this was to create two teams dedicated to projects that were being sunsetted. These teams would be run using Kanban for their projects, as opposed to the SCRUM approach employed for the other teams. By having dedicated teams for these projects, the throughput of the regular project teams was increased without a loss of support for the projects being sunsetted. Finally, an audit of the Jira administrators was performed. While it can be argued whether to perform this early in the process or later, it must be done at some point. It is very common for Jira administrator permissions to be doled out with little governance during the early days of Jira at an organization. For proper long-term stability, this should be pruned as early as possible. Copyright © 2018. Isos Technology. All Rights Reserved. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. All other trademarks and registered trademarks are property of their respective companies.

Where Are They Now?The updated Jira SAFe implementation has been in use in the organization for a few quarters now, andteam members have definitely seen benefits. They have been able to control and report on scope creepand maintain the quality of projects being sunsetted. They are also able to properly accomplish PI Planningwith the greater control and visibility into projects, as well as getting increased PO buy-in necessary for SAFeto work. They have been able to do all of this on Jira Cloud with the Scriptrunner app being the onlyextension.The team is continuing to iterate over processes, incorporating additional recommendations from Isos. Theyare starting to make use of linked issue types. This is very important since it gives increased visibility intodependencies, an important factor in keeping the ART on track. They have also begun using Jira releases,which helps with organization, querying and reporting in Jira.While significant progress has been made, there are still some areas for improvement. The organization isstill not using the WSJF fields. Also, during the implementation, Isos recommended using Fibonacci forestimation. Currently, this has not been incorporated. Finally, projects show good burn-up in the reporting,but do not show good burndown. The organization is watching this closely and refining their processesincrementally to improve the burndown. BURNDOWN TO DO:In ConclusionWhat can we take away from this discussion? First and foremost, Jira is an excellent tool for SAFe. It doesrequire careful planning and a strong working knowledge of the features and concepts in Jira to implementproperly. Even without additional plugins, Jira is fully capable of handling the complex release cadencefound in SAFe. Once properly implemented, it becomes much simpler to visualize and manage teams andproducts to guarantee that what is promised in PI planning is implemented, keeping ARTs on track.When laying out Jira for SAFe, project standardization is key. While there may be some variance in projects,this should be minimized. Agile management at scale requires consensus. If every project is a snowflake, itwill increase noise. It is also very important to align projects to individual products, not teams. This will aid intracking, visualization and reporting.Finally, remember that the biggest aspect of SAFe transformation is the cultural change. If your tooling is notset up in a way that gets buy-in from all team members, the transformation will struggle, to say the least. Culture eats strategy for breakfast. Peter Drucker Copyright © 2018. Isos Technology. All Rights Reserved. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. All other trademarks and registered trademarks are property of their respective companies.

Isos TechnologyIsos Technology is a premier Atlassian Platinum and Enterprise Solution Partner and was recognized as theAtlassian Partner of the Year 2017 for Jira Service Desk. We help our clients, both private and public sector,adopt the Atlassian tools for DevOps, ITSM and Agile development and business processes. Our processexperts, coupled with a world class technical team, craft custom solutions, integrations and training for ourclients. Isos also has a strong software development team that delivers custom solutions across a widearray of industries to help solve some of the toughest business problems. Isos is based in Tempe, Arizonawith satellite offices across the US, from San Diego to Washington D.C.For more information, visit www.isostech.com.Contributors Tracy Walton is an Atlassian Consultant with Isos Technology. She started her journey with Jira as a Product Manager looking for a more efficient way to manage her backlog and provide Tracy transparency to her team and colleagues. Walton Six years later, and with many lessons learned, she remains an Atlassian enthusiast with the goal isostech.com/tracy-walton of assisting others get the most from their Atlassian products. Tracy's consulting is a unique blend of her passion for leading teams, her product expertise, and 10 years of hands-on experience in Agile software development in a variety of products and industries, including Digital Marketing, Customer Relationship Management, Subscription Billing and Compensation Analysis. She is an Atlassian Certified Professional: Agile for Jira and Jira Software Administrator and holds additional certifications as a Scrum Master and Life Coach. When she is not consulting she is likely out gardening or swimming with her family where they reside in the beautiful beach town of Encinitas, CA.Bob Wen Bob Wen is an Atlassian Support Engineer with Isos Technology. His extensive background as both a hardware and software engineer in telecom, defense and healthcare make him especially isostech.com/bob adept at helping Isos Technology’s clients overcome their technical hurdles. But Bob’s interests don’t just lie on the technical side. He’s also a self-proclaimed “process geek.” Possessing both Certified Scrum Master (CSM) and SAFe Program Consultant (SPC) certifications, Bob readily shares his knowledge both through structured training and informal discussions. His insight is invaluable in any agile or DevOps discussion. When not helping clients or spreading process knowledge, Bob can often be found at a poker table or working his way around a kitchen.Rodney Rodney West combines an anthropologist's instinctual understanding of cultural interactions and West extensive experience in mobile and enterprise development in his role as a Senior Consultant for Isos Technology.isostech.com/rodney As a software engineer and architect, Rodney has delivered mobile and enterprise applications and frameworks to a variety of Fortune 500 companies. Rodney has worked with clients in education, banking, entertainment, construction, retail, and mobile hardware. He now brings skills gained in these arenas to functional consulting. Rodney is a firm believer in the philosophy that one must first understand the culture of a company to properly meet its specific needs. It is this dedication to first understanding the ‘why' of customer requests that has made Rodney an effective team lead in his projects, proficient at interacting with all levels within client organizations. The combination of social engineering and technological prowess Rodney West brings to all customer engagements has made him a highly successful software architect, functional consultant and core member of Isos Technology's services delivery team. Copyright © 2018. Isos Technology. All Rights Reserved. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. All other trademarks and registered trademarks are property of their respective companies.