Washington, DC, January 7, 2025 – Valiantys, a global leader in IT consulting with Atlassian, announces the launch of Valiantys Federal, a dedicated Atlassian consulting team for the Public Sector and other highly regulated industries. Valiantys Federal emerges from Contegix’s Federal division, an expert Atlassian consulting team with deep experience in secure, compliant, and innovative solutions tailored to federal needs. This expertise will allow Valiantys Federal to offer unmatched consulting and engineering capabilities for federal teams.
“Valiantys Federal combines the global reach and Atlassian expertise of Valiantys with Contegix’s unparalleled depth in federal consulting,” said Shaun Jones, General Manager of Valiantys Federal. “As a U.S.-based team, we’re uniquely positioned to deliver secure, compliant solutions that not only meet the complex needs of federal agencies but also drive operational efficiency, foster collaboration, and ensure mission success.”
Federal-focused solutions built using modern work essentials
After more than a decade of working with public sector teams, Contegix has developed a suite of tailored solutions to take on the unique challenges faced in the Public Sector. Valiantys Federal is thrilled to collaborate with both government and non-government entities, dedicated to supporting operations that adhere to government regulations and security standards and foster public-sector collaboration. This partnership streamlines compliance challenges and boosts the success of initiatives.
Valiantys Federal merges a solid history of performance with extensive knowledge in regulated industries, such as defense, intelligence, and public sector agencies. Our unique approach highlights customized solutions and a successful track record, establishing us as reliable partners adept at managing intricate compliance needs and critical mission settings.
These services will continue to help clients from across the federal sector simplify modernization efforts, enhance collaboration, and ensure compliance with stringent federal security standards. Compared to costly and time-intensive tools built in-house or from scratch, partnering with a public sector expert enables agencies to save resources and remain focused on their missions.
Valiantys Federal caters to a wide range of customers within the DoD, defense industrial base, and regulated sectors.
Defense and Intelligence Agencies: Addressing the critical mission requirements of the Department of Defense, intelligence agencies, and relevant partners.
Federal Agencies: Offering customized solutions for U.S. federal government departments and agencies.
Defense Contractors: Supporting contractors collaborating with the U.S. government on defense projects.
SLED (State, Local Governments, and Education): Delivering services to state and local governments, along with non-profit educational organizations.
Organizations with FedRAMP Requirements: Ensuring compliance with FedRAMP standards due to their contractual duties or work demands.
Organizations in Regulated Industries: Assisting entities engaged in government-regulated activities, including those under HIPAA or FINRA regulations.
Harnessing tested experience to drive innovation
Just like Ascend Integrated, Valiantys Federal will operate as a U.S.-based entity: all operations, staffing, and infrastructure are and will continue to be entirely domestic. Valiantys Federal will build on these industry-leading platforms to provide the following core lines of business:
Atlassian Federal Solutions: Recognized as the leading Federal Atlassian solution partner, providing secure and best-in-class, FedRAMP-compliant Atlassian tools developed with extensive knowledge of federal requirements. Valiantys Federal services encompass implementation, training, onboarding, licensing, and management.
Federal DevSecOps: Valiantys Federal’s internal software factory guarantees security and operational excellence during the software development lifecycle. It is notably recognized for developing the TrustStack platform, which offers a robust solution for deploying highly secure Atlassian tools within Department of Defense (DoD)-grade environments. These additional services encompass process planning, consulting, and custom engineering.
Managed Platform Services: The dedicated managed service sets the standard in Atlassian Solutions and management and is expertly designed to handle every aspect of hosting, management, updates, and consultation services, providing seamless scalability. Additionally offering comprehensive support and proactive management, backed by our award-winning commitment to excellence and a customer-centric philosophy.
For current federal clients of Contegix and Ascend Integrated, the transition to Valiantys Federal will mean the same familiar faces with increased resources available. Clients can continue to expect:
An entirely U.S.-based team for onboarding, migration, and ongoing concierge-level assistance.
Consistency in service operations.
Unmatched expertise in FedRAMP and other regulatory compliance.
With the launch of Valiantys Federal, the TrustStack platform will soon introduce new features designed to meet evolving federal needs, including enhanced capabilities for HIPAA compliance and expanded support for DISA environments.
Valiantys Federal poised to lead the way in federal solutions
Valiantys Federal sets a new standard in secure and innovative solutions for federal teams. The company will continue to partner closely with Atlassian to advance its toolset for federal agencies and expand its leadership in highly regulated solution services.
In the last article, “Sprint Management with Jira: Estimating Your Velocity” we discussed how to plan work for a Sprint. Teams may simply estimate their time in hours and while others might estimate in story points. We mainly looked at how this would take place during the Sprint Planning Meeting. These hours are estimated up front. ScrumMaster may want to know how many actual hours are used. Some Teams may bill for hours as used so they need to be precise with every activity they do. Others might only want to see how accurate the Sprint Planning meeting was in estimating Stories.
For this article, we will discuss how to use Jira to record the time you spend on an issue. In addition, we will discuss some of the AddOn options that can be used to give enhanced time keeping functionality and reporting.
Jira Software provides an “out of the box” solution to recording your time. Within an issue, select More > Log Work. You can enter the time that was spent in terms of weeks, days and hours. You can also set an Original Estimate that you can Log Time against.
Jira Software also has reporting to show estimated time vs actual time. While these reports do give information displayed by Version, there are limits to the information these reports will show.
Tempo TimeSheets provides an enhanced time keeping experience. The interface makes it easy to search for issues and enter time. Timesheets can be submitted for approval. Reports can be customized and created based on different criteria. Tempo also has Teams that members can be on. This creates an approver and team member structure allowing easy planning and approval.
Tempo Time sheets works great for Teams that need to report their time and can do so after an issue is completed.
Some Teams may not be able to record time after an issue is complete and may want a timer to run that can be started and stopped.
For those that use Jira Service Management – an SLA (Service Level Agreement) – provides time tracking that can start begin recording when an issue is picked up by an Agent and stop when an issue is closed. An issue might have multiple SLAs to track time such as Time to First Response and Time to Resolution. SLAs are customizable and you can choose criteria to start/stop and pause the clock on.
If you would like to use a Timer to record time used for Jira Software or even have other Apps such as Trello, Gitlab, and Monday.com to integrate time keeping functions – Clockify may be a solution. Clockify can be integrated with these apps.
For Jira Software, The Free version of Clockify uses an API key you can paste into each app. You can also set a webhook for notifications.
A View from Jira Software:
Monday.com uses an extension for a browser such as Chrome to link to Clockify.
A view from Monday.com:
While having an App like Clockify between different Cloud apps can be helpful – Managing many cloud apps with time keeping functionality can be tricky. It’s helpful to decide which apps will have time activities recorded and which will not.
Time Tracking can be helpful for many groups. Accounting and Billing may need to know the time spent developing software to bill a client. ScrumMasters may need to see how much to adjust the velocity for the time actually spent vs estimated for the next Sprint Planning meeting. Managers may need to know how much billable a development team worked on. Using time tracking at Jira or Monday.com can take the time out of time keeping for your team.
If you are interested taking your Team’s Agile Processes and Tools to the next level, contact Ascend Integrated.
Ascend Integrated is proudly partnered with Atlassian and monday.com mentioned in this article. Ascend Integrated can also develop Clockify integrations with your app suite. Ascend Integrated also has Gitlab configuration capabilities.
We discussed how to use Atlassian Jira Software to track releases. For Teams that contribute to a release across projects, there are tools such Advanced Roadmaps and Jexo Swannly Roadmaps that allow for cross-project releases. You can view your team’s releases on a timeline with dates in a roadmap.
Now that you have organized your work, you are ready to determine which Sprint these work items will go in. During the Sprint Planning meeting, we will need to determine how much work the Team can commit to this sprint and plan for the next sprint. The amount of Story Points that a Team can complete during a Sprint is called Velocity.
Part 3 – Sprint Management
For this article we will look at how to manage a Sprint if your Team uses Scrum.
Jira Software
Jira Software allows you to drag issues from your Backlog into the Sprint.
In order to determine how many Story Points the team should commit to in the Sprint, we can run the Velocity Report and see how many Points were committed vs completed in the last Sprints.
In the above chart, we might see that the Team committed to 15 Points in the last Sprint and Completed all of them, so maybe we can increase the velocity a bit, assuming nothing else with the Team has changed.
Advanced Roadmaps
If you are using Advanced Roadmaps (included with Jira Cloud Premium or Jira Data Center), you will have an updated Velocity Report that will display the Average Velocity that your Team has completed based on previous Sprints. In the example below: The Team has completed an average of 19.33 Points, but the Team has been committing more than 20 Points per Sprint.
In our Advanced Roadmap Plan, we can use the Sprint capacity management view on the Roadmap tab and view the upcoming Sprint:
We can set the average velocity for the Team to zero. In this case, as we plan we can see that we only have 13 Points worth of work committed to the Sprint, and we have room for 7 more points worth of work.
Monday.com
Jira Software does have both a field for Story Points and Story point estimate. This allows a team to input the amount of points they initially thought the Story was worth and update the Story once completed with the amount of Story Points the story was actually worth. This can help a team estimate better in the future. While the Jira Velocity Report can only show Story Points, if your Team integrates Monday.com and uses the Sprint Planning template, you can view a summation of both Story Points (SP) and Estimated Story Points (EP).
Easy Agile
While it’s possible to run parallel Sprints for the same project in Jira, many Teams wish to plan several sprints ahead. This can create a lot of scrolling in Jira if you have a sizeable backlog and many Teams using the same project, this can be cumbersome.
Easy Agile Programs for Jira allows the creation of Program Increments (PIs). Within a PI, a Team can drag the items into each Sprint as projected all on the same screen. Dependencies can be visualized on the board.
In this article we showed some ways to plan Sprints using Jira Software or an AddOn to make use of Velocity to plan your Sprints. We can also view the difference between Story Points that were chosen at Estimation vs the amount of Story Points completed. It’s also possible to plan several Sprints ahead.
Story Points are a great metric to track how much work is being completed. But often times, we still need to track the amount of time an issue takes to complete. In the next article in the series, we will explore Time Tracking.
If you are interested taking your Team’s Agile Processes and Tools to the next level, contact Ascend Integrated.
Earlier this year, I was tapped to create and manage our client service portal here at Ascend Integrated. Looking back at my prior experiences as both a guide for what not to do and an inspiration for how to elevate the customer experience, I began to recall my first foray into ITSM outsourcing.
A decade ago, in another life, the fin-tech startup I had been working at for the past few years hit their stride and began a period of rapid growth expansion. It was an exciting time and the future seemed bright. And bright it was, so bright in fact that we had to wear shades.
The influx of new clients revealed a host of underlying issues that had gone largely ignored in pursuit of growth and investment. In order to succeed we needed to adapt, create efficiencies, and automate fluidly. One of the areas that needed to scale quickly was the client experience, primarily the workflows surrounding internal service level agreements (SLAs) and external communication.
It quickly became clear that we needed a better method to track and respond to client requests, questions, and issues as well communicate internally. Thus, the search began for an ITSM solution that would meet the needs of the entire company.
After weeks of demos, sandbox testing, and internal discussions, a vendor was selected and we began down the road to implementation. As soon as we did, however, we hit a major roadblock. The software’s feature suite was known in addition to the general idea of the efficiencies to be developed, but we hadn’t pictured what our ideal system looked like.
Up until now, most departments operated in silos with most of the workflow determined by direct managers. Change had to occur, but what those changes would be and how they could be unified were still unknown.
At the time, we chose to develop our new ITSM solution in-house. We thought, “Hey, we’re a software development company with internal Engineering teams and lots of smart people, we can figure this out easily.”
There were constant speed bumps and growing pains along this journey. It took the better part of a year and an extremely patient client as a beta partner, but we did eventually get our system rolled out and scaled for hundreds of client organizations.
And still, after all that planning, testing, and effort, clients were hesitant with this new method of interaction when it was initially introduced. They were apprehensive that instead of picking up the phone, they would submit a ticket via a client portal. It seemed too impersonal. There was concern that the service level would decrease with this new approach. The list of hesitations was long and getting buy-in took time.
Ultimately, what sold these clients on this exciting new product were the efficiencies they were seeing in real-time. Communication improved, response times to requests became shorter, fewer items were lost in the shuffle of emails, and internal staff was able to focus more on the client leading to a net-positive experience for everyone involved.
Today, there are many more tools and cross-product integration providers. Navigating the jungle of vendors can be daunting to say the least. A constant in the ITSM space is change. The way both teams and systems are managed are unique to each organization, as are the expectations for success. Both will continue to change with time and growth.
Though over ten years have passed and the sophistication of ITSM software has grown exponentially, the reasons behind necessitating these tools remains the same. Regardless if your company has a staff of 10 or 100,000, in order to be setup for success, it is advantageous for staff needs to be able to focus on the client and the work product above all else.
I’ve occasionally reflected about what I would change if I could change one thing about that initial experience. The conclusion was that I wished our company had the guidance of subject matter experts who brought an outside perspective and a wealth of experience along with them to simplify the process and help conceptualize a needs-meeting product.
I’ve worked in a wide array of industries throughout my career, but before my time here at Ascend Integrated, I didn’t know I was missing a piece of that answer. The staff at Ascend are a real team and that carries over to all of our clients. We don’t support each other just because we’re a team; we’re a team because we support each other. Our customers are part of our team, and that’s what makes us exceptional.
We discussed how to use Atlassian Jira Software to plan work. We looked at some different AddOns to rate issues that are to become work items for a team by prioritizing which items are the most important to different interested parties. We then discussed how the developers on a team can assign a rating of complexity to a work item. This can help determine our Team’s capacity: What items to pull into a Sprint and how many items the Team can expect to complete.
We can now turn back to the Project Manager role who might be asking: When will a group of work items be finished? The best place to look for this information will be in Releases.
What is a Software Release?
Releases are groups of updates for software. They may contain Bug Fixes, New Features, Improved refactored code, or other changes. They are generally tracked as Versions (Ex. 1.0.0).
The type of software that a development team works on will vary greatly from organization to organization. Some types of software are loaded onto secure devices that are not always connected to internet and thus are updated infrequently. One example might be firmware for an industrial machine – it might require a programmer interfacing with a physical terminal to load the update.
On the other end of the spectrum, there is also software that can have constant releases at any time, because the software is Cloud-based and many users can have settings to continually look for and download updates. An example of this might be a Smartphone App. In some cases, there might be a new update every day. Some very large platforms might have thousands of updates a day performed in various systems without the end customer even noticing.
Another factor may be what types of completed work items will be in releases. Some types of software favor stability over all else. Pushing out bug fixes may be needed to be frequent and take precedent over features which might only be released once a quarter. Some types of software may use multiple environments.
A development team may consider a story “Done” when it is released into a QA environment but a testing team may only be starting its work. Some teams may only be able to test large batches of work at once. Others may be able to use automated QA testing which might allow a work item to be tested right away and promoted to the Production environment when it passes a test.
With this in mind this article will show how to use Jira Software and its AddOns for Release Management in different scenarios.
Examples with Available Tools
Each Team has their own Jira project which has its own Product Releases at the end of every 2 week Sprint:
Jira Software has a Releases module in which you can use to track the FixVersion (version that the Story or Bug will be in).
Jexo
The Jira Software AddOn – Jexo Swannly Roadmaps has the ability to add a Cross-Project Release. In this example: The Koala Team and Toucan Team are both putting items in their own Releases, but the Cross-Project Release is available for both Teams to add their Jira issues to. Swannly Roadmaps is available for Cloud versions of Jira. The colored bars represent Releases in this view and show both the releases the Teams have and a separate Cross-Project Release.
Another solution for Jira Software Cloud Premium or Jira Data Center is to use Advanced Roadmaps. Advanced Roadmaps creates Cross-Project Releases that both teams can use.
Example:
You have two Jira projects from two different Teams. They each need to work out of the same Release – a Cross-project Release called Q1 Banking Release. Each Team has a Q1 Features Release that needs to be tracked for their Team. These Team releases are part of the Cross-Project Release.
Like the name suggests, Jira Advanced Roadmaps provides a visual Roadmap as well. It is a hierarchy of issues that that shows visually when issues will be worked on. You can also add columns to show issue information and make changes that can synch with Jira Software.
monday.com
Product Roadmaps can be a way to visualize which issues will go in what Releases. This can be visualized in monday.com’sFeatures and Releases Roadmap:
While monday.com can be used as a simple standalone project management tool, it can also be integrated with Jira Software. Issues that are updated in Jira Software can be visualized on monday.com.
Coming Up Next
In this article we discussed how to visualize when work will be released. A release might be to a customer in the Production environment or to another environment like QA where the next step is Testing. Releases can be milestones in a Roadmap for a Team to achieve. Roadmaps are a visual way to see when items will be completed. Releases might be done “When Ready”, after a Sprint is complete, Quarterly, or at another set cadence. With Jira AddOns, we can also coordinate with several Teams by creating Cross-Project Releases.
While Releases can be tied to a Sprint, they do not need to be. Releases are meant to be for the end user or project stakeholder so that they know when their requested Features or Bug Fixes will be in the latest version. Developers need to know what Release they will complete a User Story in, but also they need to plan what Sprint a work item will go in. In the next article, we will discuss some different Sprint Planning methods.
If you are interested taking your Team’s Agile Processes and Tools to the next level, contact Ascend Integrated.
Ascend Integrated is proudly partnered with Atlassian, Jexo and monday.com mentioned in this article.
Part 1 – Prioritizing our work and determining its complexity in Jira
In our previous blog article, “HOW MUCH SHOULD I BUDGET FOR AGILE (AND OTHER FRAMEWORKS)?” we discussed the decision making process for making an investment into your organization’s Agile processes. Jira Software provides an excellent platform for developers to track their work items such as Epics and User Stories. Jira Service Management provides a Service Desk portal for external users to report a bug or suggest a feature.
This article will focus on which tools that can be used to support the initial planning process in Agile. Scum Masters, Product Owners, and others within an Agile Team see a list of work items in a backlog and ask the following questions:
What work item is the most important and needs to be done first (Prioritization)?
How difficult will each work item be to complete during the Sprint Duration (Complexity)?
Referring back to our Agile process, we can focus on the two main methodologies: Kanban and Scrum in looking at how the Team can plan its work.
Kanban
Agile Teams using Kanban Methodology are interested in constantly prioritizing work so that they can keep work moving and flowing. Important work items may need to be done as soon as possible or they can be de-prioritized and worked on later.
Selecting a Single Priority Level
Jira Software includes Priority Levels that can be used to signify importance. Additional priority levels can be added. But ultimately, simply selecting a dropdown like “Highest” limits how specific we can be. What does “Highest” mean? What work items should the team pull in next if several work items have the same Priority level?
Calculating a Priority Level
Jira Automation (available per Jira project in Jira Cloud Standard and Global/Multi-Project in Cloud Premium) can be used to create a Priority Matrix. You can choose other fields to set the Priority level by a combination of field values such as “Impact” and “Urgency”. For example, if a customer documenting a bug creates a ticket reporting the Impact as “Extensive / Widespread” and the Urgency as “Critical”, then the priority for the ticket is set to “Highest”.
Jexo Foxly Backlog Prioritization (available for Cloud as a Jira AddOn) has a comprehensive Priority Scoring system you can customize to assign a numerical value to make work items easier to sort.
You can display work in Priority Quadrants to determine which items are grouped into different priority levels.
Multiple inputs for Priority
One way to prioritize issues would be to know how a certain type of user might value a user story. Easy Agile Personas allows you to create multiple personas which can place a different priority on a user story. Rather than just the Requestor’s priority, any user can see how different Personas value a new feature. Viewing the Persona may also be helpful when developing the feature.
For KanBan methodology, once a developer is free to continue working, they will select a work item from the backlog. They can see the priority and will choose the next most important issue. While due dates are important, developers who work on Kanban style teams are trying to resolve issues as quickly as possible, For Bug-fixing focused teams, it can be important to resolve the most painful ones first.
Scrum
For Agile Teams using Scrum Methodology, teams need to have a backlog that is prioritized. This is done by a product owner working with a project manager and the customer. Using the same prioritization tools as previously mentioned, we now have a list of user stories that developers can select from a backlog to complete.
The developers will now know which work items are the most important to choose first. Rather than a developer continually pulling issues from the backlog onto their board, the Development Team will select several issues at once from the backlog to work on during their upcoming sprint period (usually 2 weeks).
Now, the developers have a job to do. They need to determine how many of these work items they can commit to developing on during the Sprint. It is important to commit only to what your Team believes it can finish during the sprint. This control gives stakeholders, customers, and the project manager confidence that work will be completed on time. To determine how many stories each individual on a team can commit to, we need to look at Team Sprint Capacity. Before we address Team Sprint Capacity, we are going to discuss Work Item Complexity.
There are many ways that an Agile Team can measure the complexity of a work item, but for the sake of this article, we are going to focus on Story Points.
Story Points are a numerical rating of how complex a work item is. An item is rated by a developer in the backlog from 1-8. For example a “1” rating might be a simple task with no research required, where an “8” might be a complex work item and with no current understanding for how to solve the issue. Research, trial, and error are likely necessary to complete the work item within the Sprint duration.
Setting Complexity with Story Points
Jira Software allows a user to put in the Story Points while in the backlog:
Calculating Complexity
One way to create multiple inputs for Story Points would be to use Jira Automation to calculate the number of Story Points based on other fields. For Example: If research is needed, testing is needed, and we are not sure of a solution, then the Story Point Estimate is automatically set to an “8”.
Planning Poker – Voting on Complexity or Priority
While some teams have individuals that tend to work on their own items based on their specific skill set, other teams may have multiple individuals with the same skills (poly-skilled) that could pick up the same issue to work on. Teams of this type might hold a Poker Planning Session. With Jexo Foxly Backlog Prioritization, we can invite several users to a Poker Planning session.
During Planning Poker, several Team members will give their own estimate for a Story. We might use the same variables such as “Research”, Testing”, and “Sure of Solution” as the previous example but instead of a Yes or No answer, each voter chooses a value between 1 and 8. The scale could consist of “1” being the least amount of effort up to “8” being the most difficultly. Similarly, a group of those responsible for setting work item Priority such one consisting of a stakeholder, customer, and product owner might each vote on their own priority level. A formula can also be used to determine how to score such as “Business Value” + “Customer Value” = “Priority Score”.
Setting the Story Points using the Priority score – Automation for Jira
It is also possible to use Jexo Foxly Backlog Prioritization in combination with Automation to set other fields. For example: If the Score for an issue is above 30, then Story Points will be set to 8.
Planning as a Team
In order to determine what your Team’s “Total Sprint Capacity” will be for the next Sprint during planning, we can look to the number of Story Points the Team has completed in the past. One place to look for this information will be the JiraVelocity Chart Report, displaying the total number of Story Points committed by the Team during the last Sprint and the total number of Story Points Completed by the Team in previous Sprints.
Coming up Next
So far, we have discussed how interested parties such as business stakeholders can prioritize issues in the backlog using Jira or with an AddOn that adds extra functionality. We have also illustrated how a developer can give a rating of complexity a work item (Ex. a User Story) that is to be developed. A Team can even vote on issues during a Poker Planning session to determine the Story Points or they can calculate them with Automation for Jira. In addition, a Team can can look to the Jira Velocity Chart to see how many Team Story Point they can expect to be able to complete in the future.
The next question in planning our work is: When will the items be completed?
Let’s break this down by what each interested party wants to know:
Customers – Most customers are concerned with when they are able to see the updates released to their Production Environment, regardless of when it will be worked on by the development team.
Project Managers – Most project managers have deadlines in the form of dates or milestones based on releases.
Stakeholders – Business Stakeholders want to know when the business will see value (confirmation that a new feature is released to the customer and the customer has accepted it).
We will discuss Release Management in our next blog article of our Agile series.
If you are interested taking your Team’s Agile Processes and Tools to the next level, contact Ascend Integrated.
Ascend Integrated is proudly partnered with Atlassian, Easy Agile, and Jexo mentioned in this article.
When an organization starts out its processes are loosely defined. Why complicate things? When there are few parties involved, communication can remain informal. It’s usually easy to get in touch with each other. Transparency is preferred because of the close relationships held with the people involved. In many cases this is often an advantage. There are few bottlenecks from endless rounds of approvals needed, and things can be done on the fly without the need to document everything. This allows workflows to be executed quickly. However, as a company expands to bring on more complex customers, hires more people, creates more teams, and hires individuals to manage those teams; things can quickly become much more complicated. Expectations can be increased unevenly across teams.
In many cases, individual teams are allowed to manage their own development process in their own silo. Sometimes different teams can adopt their own development tools as well. This can often happen in a situation where a new team is acquired through a merger and the newly acquired team already has its own processes and tools in place. The leader of the organization might see this growing chaos and feel the need to create order. Decision makers look up the Agile Manifesto and see: “Individuals and interactions over processes and tools.” Does this mean that we are “Agile” if everyone is allowed to do whatever works for them?
One of the common misunderstandings of the Agile Manifesto is that “Agile” means “Do whatever works for you.” But if we take a closer look at the phrase “While there is value to the items on the right, we value the items on the left more.” – we can come to a similar conclusion: While it is true that we value individuals and interactions more than we value processes and tools, that does not mean that processes and tools have NO value. In fact, poorly defined processes and the wrong tools can lead to individuals having more frustrating interactions with other individuals – their teammates, vendors, and in the worst event even customers.
The way to show that management values the time of their employees is to make the process for the worker more efficient. If Team A has Jira but Team B has Trello and their work has dependencies on each other, not using a common tool can adversely affect communication and thus interactions between the individuals on those teams.
Often when problems crop up and organizations look for efficiencies, what tools each team can use for development becomes a decision that is based on cost efficiency rather than team efficiency. Many times, when deliverables become delayed and communication breaks down, the first instinct is to bring in a new tool that all the teams can use. While this can help account for some disfunction an organization may face, in many cases the software development processes that are used by disparate teams become the cause of more problems.
Even if the CIO has taken the lead to bring multiple teams on the same development platform, they haven’t accounted for the process that must be followed now that everyone shares a common platform. While there is value in bringing in a new development platform like Jira Software – this is only one half of the necessary solution. It’s important to give users training on how to use any new platform. This is a necessary consideration so that teams can use the new platform effectively. It’s also necessary to train your teams on using a common development process framework (with some allowable customization between teams). While this all sounds great, as a CIO we think to ourselves: We are already spending some budget on the new tool – implementing the new software development platform – Jira Software. How much should be budgeted for processes?
Questions to Ask When Budgeting
Who in the organization owns the software development process?
How much customization of the software development process is actually needed by different teams?
Is it due to product differences or differences in delivery expectations?
Is there a way to measure our success and efficiency across different development teams?
Do we have any experience with the Agile framework development methodologies like Scrum and Kanban?
Have we put oversight roles in place to make use of these methodologies successfully?
Do we have an individual with the right expertise (and time they can devote to it) who is able to lead an effort to standardize our processes and measuring results across teams?
Does our current company culture accept change easily?
How entrenched are old habits?
Implementing Agile Methodologies
Empower Team Leads (or Scrum Masters) to form a Center of Excellence and own the organization’s Agile training: For this to be effective, you need very dedicated resources with the right expertise to lead the initiative. Often, it can be hard for these individuals to find enough time to work on the effort to go Agile. The Atlassian Agile Coach offers information and tips that your organization can implement.
Budget Agile Training into your training department’s program: If your organization has training classes, this can be a way to ensure that your associates at least have a day of classroom time devoted to learning Agile. While this can be a good start for those without Agile experience, it’s important to learn continuously. Ascend Integrated offers the Jira Essentials with an Agile Mindset class which both teaches how to use Jira and how to use the Agile Framework with Jira. For more information about Agile classroom learning contact Ascend Integrated.
Structured Agile Transformation: This would be a top down organization-wide initiative that places importance, time, and a monetary budget on developing the Agile Framework. This works best with hiring a third party agile expert with experience with multiple organizations and situations that can get measurable results without the need for an internal individual to have to devote time and effort. With a third party leading an Agile Transformation, they can also have the authority and ability to motivate others. Ascend Integrated can lead the way at your organization with Agile Coaching and Process Consulting.
Scaled Agile for Enterprise (SAFe) Implementation: This is the most comprehensive methodology. Plan for a minimum of at least a half year (two quarters). For companies with 125 individuals or more, this can be a way to manage both individual teams and teams of teams. An outside third party leads the implementation and helps develop the organization’s individuals who will be owning the agile process in the future. Ascend Integrated is a Scaled Agile for Enterprise Bronze Partner and can enable a SAFe transformation with using the Jira Software suite or other tools at your organization.
For more information to help determine what the best path to Agility would be for your organization, contact Ascend Integrated. Ascend Integrated is a Atlassian Partner.
Reviewing FBO.gov and the GSA Ebuy portal, there are currently close to 300 open opportunities across the Federal government for the implementation, development, or management of agile processes and procedures. Tools used to enable and reinforce these processes are also abundant on the marketplace, but how can you select them in order to correctly meet government security standards? The documentation requirements often found within these government needs, including FedRAMP compliance, can be prohibitive without context. This blog will discuss tools currently available on the marketplace that meet FedRAMP compliance, while enabling agile processes across your organization, and can be integrated simultaneously to create even more sustainable managerial solutions.
Enabling Agile with Multiple Tools
It’s no surprise there are a range of toolsets on the marketplace that enable agile processes. However, many of these exist in a non-compliant cloud state and are rendered inaccessible for government users. Problems arise either through authentication, authorization of use, permissions, or from a general security and vulnerability standard. Three tools we are going to discuss today which can be hosted in FedRAMP compliant environments include:
Atlassian Jira Software
Atlassian Confluence
GitLab
All three have some overlap in surface capabilities, but when combined they provide a deep functionality for enabling agile processes.
Jira Software + Confluence
The Atlassian Tool Suite (Jira Software and Confluence) has been successfully used for over a decade across multiple Federal organizations. The products have been deployed across FedRAMP Low – High environments and enable multiple work environments to run effectively with diverse solutions. Using Jira Software, project managers and SCRUM masters are enabled to properly manage tasks and user stories, estimate and create sprint burndown charts, and track and manage the development of solutions across simple and complex workflows.
Confluence provides the wiki collaboration and documentation feature, often replacing SharePoint in agencies as the de-facto documentation tool. In unison Jira Software and Confluence enable traceability across written documentation networks and requirements along with deployment capabilities.
GitLab
GitLab is the end all, be all for application development. From inception to operation, usability is intuitive, and maintenance is easy to keep up to date. It provides users the capability to host a code repository that allows team leaders to actively track and manage development stories, tasks, and implementation all while utilizing the underlying DVCS. GitLab also enables collaboration through the use of wikis, and can be hosted across different low, medium, and high security environments simultaneously.
Jira + Confluence + GitLab
While these services can provide incredible capabilities on their own, covering multiple functionalities under the DevSecOps tool chain, the true power of their scope is realized when they are combined. When this set of tools is applied together users are empowered to accomplish more through utilizing the main strengths of each tool, specifically:
Jira Software: Project Management and tracking
Confluence: Wiki documentation
GitLab: Code repository, CI/CD, and deployment capabilities
Jira, Confluence, and GitLab can be synchronized together easily using multiple add-ons and apps from the marketplace. Many are free, while others carry a licensing cost to attach them. Enabling GitLab and Jira provides you with a full view of Tasks, Bugs, and User Story development in the Jira work environment. While documentation is developed in Confluence, including Branches / Commits / Merge Request information, and notes in GitLab.
These tools when combined, create a functional strength in their unison. It is the combination that allows each tool to work more effectively for a wide range of common organizational needs. And most importantly, these tools can be deployed across multiple Federal and Commercial organizations in a variety of network conditions and implemented in preapproved FedRAMP environments. Implementing and enforcing Agile processes is essential in your Federal Agency. Jira, Confluence, and GitLab combined provide not only these capabilities in a secure environment, but also possess all the functionality required to keep your agency on the cutting edge of available technology.
Conclusion
How are you enabling Agile in your organization? Feel free to reach out, comment, or drop us a line and let us know! www.ascendintegrated.com
Before the technology giants of today, the automotive industry, a looming and monopolistic industry paved the way for manufacturing and innovation. Eventually, General Motors (GM), Ford, and Chrysler would come to define an entire century rich with innovation. At the center of it were the core lynchpins of engineering and process management: Lee Iacocca, Henry Ford, and a name not mentioned as often as deserved, but who was considered the Elon Musk of his time, John DeLorean.
A playboy, iconoclast, engineer, and overall ‘rebel’, DeLorean helped shape the future of the automotive industry using his charisma to inspire designs and engineering capabilities which would help to birth the muscle car era of the 1960s and 70s. What DeLorean represented, was entrepreneurship in its purest form – a man eventually willing to do whatever it would take to save his company and realize his stainless-steel vision. His charm and entrepreneurial spirit drove him from his leadership of GM to creating one of the most iconic vehicles, but his inability to harness and reflect on the repercussion associated with his actions led to his eventual fall from grace. This is the story of unchecked entrepreneurship, and why we should always reflect on the actions we take when building a business.
The Rebel At GM
DeLorean always saw himself as separate from traditional management, even from his time at General Motors he was known as a renegade executive. Casually wearing a Leather Jacket, open buttoned shirt, and jeans while attending meetings in stark contrast to the stifling 3-piece suit corporate culture of GM. This attitude is reflected in his work. As the head of Pontiac, he oversaw the reinvention of the brand from a blue-haired version of the Chevrolet into a muscle car by leading the design of the Pontiac GTO using clever marketing and design choices.
But his time at GM and his rise to the presidency was cut short when, in response to the public’s demand for a more compact car and the rise of the Ford Pinto, he led the Vega project. He would later lament his time at Chevrolet in “On a Clear Day You Can See General Motors” the car’s complete lack of quality engineering led to multiple issues on the test track. Further in the book, he described the GM bureaucracy, a near-monopoly over the automotive empire willing to engage in unethical practices to remain profitable.
GM was too big to fail, and its design by committee attitude and slipping standards frustrated DeLorean. But, as we will later see, he would also fall victim to similar issues at DMC. As he would go on to say:
Leadership and innovation are impossible. – John DeLorean
The DeLorean Motor Company (DMC)
Following his departure from GM in the early 70s (or ejection due to his outspoken nature about the company), DeLorean began working on his next project and founded DMC. Working with multiple government organizations, specifically in the UK, he secured a large loan valued close to £100 million to build a state-of-the-art factory in Dunmurry, Northern Ireland. His dream was to design an affordable, yet luxurious sports car that was fuel-efficient and aesthetically pleasing. The gull-wing doors were a staple of this vision. DeLorean had spent years promoting his car through ads to “Live The Dream – Today” and allowed dealerships who sold his car to have a percentage stake in the overall company.
This process overcame multiple production hurdles, specifically linked to delays and financing, DeLorean’s first DMC-12 rolled off the Dunmurry assembly line in 1981. While DeLorean continued to tout the car’s capabilities, its 0-60MPH time, and its aesthetic qualities, the largely untrained workforce along with the conflicts in Northern Ireland further delayed the ability for DeLorean to ramp up production. By 1982, these factors along with a changing political climate in the UK, recalls and repairs, alleged embezzlement, along with negative press over DMC’s single product began to take their toll on the company.
This led DeLorean to take extreme measures to save his company.
Collapse
DeLorean saw his company as his ability to express his design and engineering talents to create something great. This is reflected in the urgency he expressed attempting to save the company. He flew and met with multiple potential investors and leveraged the network he built as a celebrity to attempt to salvage his company’s finances with new investors. In the end, he fell prey to his ego and his inability to compromise – and was caught in a sting operation by the FBI attempting to sell millions of dollars of cocaine in a last ditch attempt to save his company. The embarrassment he would have felt, as GM watched his company collapse, waned so intensely on his psyche he resorted to unethical and illegal activities to try to save it.
Upon his arrest, DMC quickly collapsed like a house of cards, and the factory was held together by a skeleton crew. 1983 would be the last year the DeLorean was rolled off the factory floor. DeLorean would later joke when trying to restart his business, “Would you buy a used car from me?” Even still, he began making plans for his third comeback.
The Spirit of Entrepreneurship
This comeback was to be based solely on an upgraded version of the DMC-12, but it never materialized, and DeLorean lost everything. In his last public speeches and appearances, he continued in the months before his death promising a resurgence in his company, his designs, and his vision of the automotive future.
It’s inevitable that the company comes back. – John DeLorean
His book “On a Clear Day You Can See General Motors”, no longer in print, highlighted a considerable amount of the management issues present within the company. Even choosing to delve into the details of the rushed design and development of the Chevrolet Vega, GM’s answer to the looming fuel crisis and the need for compact cars of the 1970s. Similar to Greek tragedies, DeLorean would ultimately become a victim of the same issues he identified.
For a man who wanted more than anything to be the next Enzo Ferrari, running multiple divisions of GM and DMC, his life would end rather quietly. Shunned from his business circles, he moved into a small condo in Morristown, NJ where he would pass away in 2005. At his funeral, he was laid to rest in a motorcycle jacket and blue jeans. Defiant until the end. He never gave up hope on a company resurgence, and even sold watches and memoirs to finance his next venture.
Unchecked, an entrepreneur may fall into this trap and do ‘whatever it takes’ to accomplish their goals, regardless of legality or ethics. DeLorean represents those raw qualities of an entrepreneur we love and hate: untamed, charismatic, narcissistic, brilliant, and uncompromising. Even with these traits, he eventually came to embody everything he hated about General Motors and all those stuffy and self-congratulatory board room members.
But, as we as entrepreneurs continue to grow, the case of DMC and John DeLorean can be used as a cautionary metaphor for business ethics and unchecked egos: that if we do not take active measures now and evaluate our actions, we may eventually become what we despise.
The Atlassian Government Symposium is an event held annually that allows government teams to connect, share, and learn how to take Agile work concepts and integrate them into their practices. As a certified Atlassian training partner, Ascend Integrated presented two projects during the symposium that showcased the unique benefits of government teams adopting Atlassian-based Agile solutions.
Merging Security and Efficiency
James Hunt, the lead Atlassian Expert, and Jeff Weatherford, the lead DevSecOps engineer for Ascend Integrated, discussed deploying Atlassian as a shared service across Platform One for the Department of Defense.
The give and take between most secure programming and ease of use amongst government teams has been a difficult balance to strike for many.
The solution, in this case, was the creation of a common environment for the team to use, built on preapproved hardened containers. By working in an environment that is already approved as safe and configured for government team members to use, there is a reduction in required communication for work to be completed and an increase in the efficiency of workflow.
Finally, a marriage of security and functionally exists that allows for a reduction in the bureaucratic processes that dictates when work that needs to be done is able to be accomplished. The efficiency improvement of these processes can be tracked and scaled using Atlassian software.
Planning for Success with Advanced Roadmaps
Shaun Jones, Chief Operational Officer of Ascend Integrated gave a keynote speech on how using Jira Roadmaps can make government project managers more effective. “Urgency plays a role in achievement…it’s in the planning where we win or lose.” Jones said. The need for managers to create an environment that reduces blockages to their team’s productivity remains apparent.
Advanced Roadmaps is a Jira add-on which uses existing data to create long-term planning visualizations. Planning using Jira Roadmaps gives project managers the tools to see what is occurring at all levels of team activity. It adds functionality through the use of dependency chains which create an organizational hierarchy.
This is an ideal add-on for real-time planning to occur and it can be integrated for use with Confluence for contextual messaging. The beauty of roadmaps is the simplicity of use by allowing a full scope of an organizations work to be viewed in one single source location. This allows managers to view and share bottlenecks with team members or clients before they occur, ultimately minimizing or avoiding them.
By having a system that allows users at all levels to understand and interact with data that helps quantify the expectation of project completion, project managers and team members are able to communicate more effectively. The level of granularity related to objective completion, task completion, and project completion is a valuable guide in helping team members and project managers visualize where progress is being blocked. Transparency of work processes helps to reduce the dissonance in communication between team members.
Scaling processes are made most effective when communication is fluid and data is easily visualized. Utilizing Atlassian software can help bridge the gap between stunted project growth and streamlining the technical capacity of your team. Ascend Integrated can implement these processes through delivering sustainable IT solutions.
