Easy Agile is now SOC 2 Type 1 and 2 certified

We are thrilled to announce that Easy Agile has successfully achieved SOC 2 Type 1 compliance, a significant milestone on our unwavering commitment to maintaining high standards of security and privacy.

What is SOC 2 Type 1 Compliance?

According to our compliance partner, Vanta:

”SOC 2 is the most sought-after security framework for growing SaaS companies. SOC 2 attestation demonstrates your organization’s ability to keep customer and client data secure.”

Service Organization Control (SOC) 2 is a widely recognised auditing standard designed to ensure that service providers manage your data appropriately. SOC 2 compliance is particularly relevant for technology and cloud-based companies that store customer data as it requires them to establish and maintain strict information security policies and procedures.

The "Type 1" designation indicates that our systems and controls have been evaluated and tested at a specific point in time. Achieving SOC 2 Type 1 compliance means that an independent auditor, Johanson Group, has reviewed and certified that our processes, procedures, and controls are properly designed to meet the SOC 2 standards for security, availability, processing integrity, confidentiality, and privacy.

What this means for you

Atlassian recommended we partner with Vanta for our SOC 2 compliance as Vanta are a leading trust management platform serving software companies like Easy Agile.

Our achievement of SOC 2 Type 1 compliance means that when you use Easy Agile's services, you can do so with the confidence that we have robust controls in place to secure your data. We believe that security is a shared responsibility, and this milestone is part of our ongoing effort to provide transparent and secure practices that support your business.

We want to thank you for your trust and support in Easy Agile. Your data security and privacy are our top priorities, and we are committed to delivering services that not only meet but exceed industry standards.

When is SOC 2 Type 2 coming?

We are currently in the audit period for Type 2 compliance. We will update this page when we have achieved Type 2.

We intend to seek ISO 27001 compliance once we have achieved SOC 2 Type 2 compliance.

Where can I learn more?

Visit our Trust Report to access security reports and monitoring.

For any questions or more information about our SOC 2 Type 1 compliance and what it means for you, please feel free to reach out to our team at security@easyagile.com.

Trust Report

View our trust report hosted by our compliance partner, Vanta.

Go to trust report

Software development teams are known for using a wide variety of agile methodologies, approaches, and tools to bring value to customers. Depending on the needs of the team and the product's stakeholders, it’s common for teams to deploy and utilize a combination of software development methodologies.

Most dev teams combine methodologies and frameworks to build their own unique approach to product development. You’ll find there are plenty of overlapping principles from one methodology to the next. The key is choosing a system and working as a team to fine-tune and improve that approach so you can continue to reduce waste, maximize efficiency, and master collaboration.

In this post, we’ll outline and compare the following eight software development processes:

1. Agile software development methodology

2. Waterfall methodology

3. Feature driven development (FDD)

4. Lean software development methodology

5. Scrum software development methodology

6. Extreme programming (XP)

7. Rapid application development (RAD)

8. DevOps deployment methodology

1. Agile software development methodology

Agile is the most common term used to describe development methods. It’s often used as an umbrella term to label any methodology that’s agile in nature, meaning an iterative process that reduces waste and maximizes efficiency.

Most software development methodologies are agile with a strong emphasis on iteration, collaboration, and efficiency, as opposed to traditional project management. It’s like comparing jazz to classical music. 🎷

Traditional, linear management methods, such as the waterfall method we’ll cover below, are like classical music, led by one conductor who has a set plan for how the music should be played. The agile process, on the other hand, is more like jazz, which comes together through collaboration, experimentation, and iteration between band members. It’s adaptive and evolves with new ideas, situations, and directions.

2. The waterfall methodology

The waterfall approach is a traditional methodology that’s not very common in software development anymore. For many years, the waterfall model was the leading methodology, but its rigid approach couldn’t meet the dynamic needs of software development.

It’s more common to see the waterfall method used for project management rather than product development. At the beginning of a project, project managers gather all of the necessary information and use it to make an informed plan of action up front. Usually, this plan is a linear, step-by-step process with one task feeding into the next, giving it the “waterfall” name.

The approach is plan-driven and rigid, leaving little room for adjustments. It’s more or less the opposite of agile, prioritizing sticking to the plan rather than adapting to new circumstances.

3. Feature driven development (FDD)

Feature driven development is also considered an older methodology. Although it uses some agile principles, it’s viewed as the predecessor of today’s agile and lean methodologies.

As the name says, this process focuses on frequently implementing client-valued features. It’s an iterative process with all eyes on delivering tangible results to end users. The process is adaptive, improving based on new data and results that are collected regularly to help software developers identify and react to errors.

This kind of focused agile methodology can work for some teams that want a highly structured approach and clear deliverables while still leaving some freedom for iteration.

4. Lean software development methodology

Lean software development comes from the principles of lean manufacturing. At its core, lean development strives to improve efficiency by eliminating waste. By reducing tasks and activities that don’t add real value, team members can work at optimal efficiency.

The five lean principles provide a workflow that teams use to identify waste and refine processes. Lean is also a guiding mindset that can help people work more efficiently, productively, and effectively.

The philosophies and principles of lean can be applied to agile and other software development methodologies. Lean development provides a clear application for scaling agile practices across large or growing organizations.

5. Scrum software development methodology

Scrum is a system regularly used by software development teams. Like many software development methodologies, Scrum is agile, focusing on a value-driven approach. The Scrum process is based on empiricism, which is the theory that knowledge comes from hands-on experience and observable facts.

One Scrum takes place over a preset amount of time called a sprint. Usually, the time frame is between two to four weeks and the Scrum is at the beginning of the sprint. The goal of each sprint is to yield an imperfect but progressing version of a product to bring to stakeholders so that feedback can be integrated right away into the next sprint.

The specific goals of each sprint are determined by a product owner who orders and prioritizes backlog items (the artifacts that need completion). The sprint process repeats over and over again with the development team adjusting and iterating based on successes, failures, and stakeholder feedback.

Learn more about Scrum — the complete program planning solution for Jira.

6. Extreme programming (XP)

Extreme programming, also called XP, is a methodology based on improving software quality and responsiveness. It’s an agile approach that evolves based on customer requirements; the ultimate goal is producing high-quality results. Quality isn’t just limited to the final product — it applies to every aspect of the work, ensuring a great work experience for developers, programmers, and managers.

Decision-making in extreme programming is based on five values: communication, simplicity, feedback, courage, and respect. The specifics of XP can’t apply to all situations, but the general framework can provide value no matter the context.

7. Rapid application development (RAD)

Rapid application development (RAD), sometimes called rapid application building (RAB), is an agile methodology that aims to produce quality results at a low-cost investment. The process prioritizes rapid prototyping and frequent iteration.

Rapid application development begins with defining the project requirements. From there, teams design and build imperfect prototypes to bring to stakeholders as soon as possible. Prototyping and building repeat over and over through iterations until a product is complete and meets customer requirements.

This is ideal for smaller projects with a well-defined objective. The process helps developers make quick adjustments based on frequent feedback from stakeholders. It’s all about creating quick prototypes that can get in front of users for constructive feedback as soon as possible. This feedback is pulled into the user design so that development decisions are based on the direct thoughts and concerns of those who will use the product.

8. DevOps deployment methodology

The DevOps deployment methodology is a combination of Dev (software development) and Ops (information technology operations). Together, they create a set of practices designed to improve communication and collaboration between the departments responsible for developing a product.

It's an ongoing loop of communication between product developers and Ops teams (IT operations.) Like so many agile processes, it relies on continuous feedback to help teams save time, increase customer satisfaction, improve launch speed, and reduce risks.

The steps of DevOps deployment repeat, aiming to increase customer satisfaction with new features, functionality, and improvements. However, this methodology has some drawbacks. Some customers don’t want continuous updates to their systems once they are satisfied with an end product.

Software development made easy

Most software development teams use a combination of methodologies and frameworks to fit their team size, team dynamics, and the type of work being completed. The key is to use an agile methodology and work together to continually improve your systems as you learn and grow.

Easy Agile is dedicated to helping teams work better together with agile. We design agile apps for Jira with simple, collaborative, and flexible functionality. From team agility with Easy Agile TeamRhythm, to scaled agility with Easy Agile Programs, our apps can help your agile teams deliver better for your customers.

Book a 1:1 demo to learn more about our suite of Jira tools, or contact our team if you have additional questions. We offer a free, 30-day trial, so you can try out our products before making a commitment.

Product development without an agile workflow would be like building a house without a blueprint or defined roles on the construction team. No one knows what to do or who does what. 🤔

The result: time and energy wasted building a single house that would most likely reveal its darkest flaws over the years.

So, here’s what you need to know: Process increases efficiency. It also increases efficacy, customer satisfaction, and a better experience for the team members who take a part in the process.

Follow this how-to guide to building and implementing an agile workflow in Jira. In this article, we’ll cover what an agile workflow is and define the steps for its creation and its principles in depth.

The notion of workflow

The execution of a team's work is dictated by one or more processes. In other words, a process is a way the team gets to the finish line with deliverables. And if you're developing products with an agile framework, an agile workflow is a way to structure that process.

Generally, a workflow is made out of:

• Activities, tasks, and steps
• Roles
• Work products
• A few other things to help improve team collaboration and work execution

With such a structure, it gets easier:

• To repeat the process
• For team members to work with each other
• To scale the process and the work itself

It seems like a workflow is so well-organized that teamwork would flow smoothly just because it exists. Well, that's not the case. In the next section, you'll learn that there's not a workflow for any team or project. Instead, there are one or more workflows that work for your team or your project.

Why there's no one-size-fits-all workflow

The size and maturity of teams have an impact on their workflows. Also, the type of project and both company culture and team culture influence the configuration of workflows. Bottom line: Your agile workflow will depend on many factors, and it’ll likely be unique.

You might, however, find online suggestions of workflows that prove to work with other companies. So, if you prefer, you might use those as a starting point for the definition of your own workflow. It might be the case that excluding some steps does the trick for you. On the other hand, you might define your own workflow from scratch.

Jira is a very versatile solution for workflow management that supports many different agile workflows.

With Jira, you may customize workflows to different company cultures or team cultures. In this context, culture means the way team members work with each other. In the same vein, a workflow expresses the dynamics of a team in one or more projects.

Now, if we're talking about Jira workflows, you should know what one of those contains.

What's a Jira workflow exactly?

A Jira workflow is an agile workflow built on top of and implemented with the help of Jira. It's a digital board that allows checking the statuses of work items. It may also send notifications when those items change status. You can also use your Jira board for Scrum meetings such as daily standups and sprint retrospectives.

You absolutely need to keep the statuses of ALL work items accurate. That means updating the status of each work item whenever and as soon as it changes.

Only an up-to-date agile workflow — and Jira board — fulfills its purpose and delivers benefit. It's an awesome tool for team members, Product Owners, and Scrum Masters to track work progress at all times.

Let's move on to our guide now. You'll find out, one tip at a time, how to become an agile workflow rockstar with the help of Jira.

Your guide for agile workflow in Jira

Start your engines! You're heading on a fabulous learning journey about the creation and management of agile workflows in Jira. Here are our best tips to make this process happen:

1. Start now

Don't postpone getting your hands dirty with workflow definition.

Even if you start simple, just get started. Don't delude yourself into thinking that you'll succeed at agile if you start big. In fact, that could work against you and your project.

2. Don't overwork

Don't spend weeks structuring, restructuring, and then restructuring your workflow some more.

Overworked workflows are hard to understand and much harder to implement and comply with. That would harm the basic principles of agile methodology.

With an overloaded workflow, you'd end with team members not knowing what to do and when to do it. Consequently, at the end of the sprint — or iteration — and project, no deliverables would be ready to roll out.

3. Don't forget about workflow stakeholders

You should account for roles that will somehow use the workflow you're defining. Whereas some will use it daily to get work done, others will use it only for some kind of management analysis.

You should understand with them what their workflow needs are. It'll take time, so you must be patient.

4. Understand the concept of ‘issue’ in Jira

In project management, an issue describes a problem for which there's no solution yet. Those issues come from risks to the project's development process and ultimate success. For instance, adding a functionality to the project scope — the issue — could come from the possibility of requirement changes — the risk.

However, in Jira, an issue doesn't necessarily represent a problem. Rather, it represents a piece of work that teams must complete. For instance, a Jira issue can be a task or a helpdesk ticket.

With software development, a Jira issue may symbolize more specific concepts such as:

• Product features and functionality that the development team must implement
• Bugs that must be solved

5. Know the pieces of the puzzle

In Jira, a workflow has four types of components:

1. Status. This indicates the position of an issue in the workflow. It can be an open — or unresolved — status or a closed — or resolved — status.
2. Transition. This defines how an issue changes status, and it can be either uni or bidirectional. You can create more or fewer constraints depending on how statuses change. You can even define that only certain people or certain roles can change an issue from one specific status to another.
3. Assignee. This is the person responsible for an issue.
4. Resolution. This describes why an issue went from open to closed statuses. Additionally, it should only stick to an issue while it’s resolved.

In software teams or projects, it's common to find statuses such as:

• "To Do" for issues yet to start
• "In Progress" for issues that the team already started to tackle
• "Code Review" for completed coding tasks that need a review
• "Quality Assurance" for completed issues that require testing by a team of testers
• "Done" for completed, reviewed, and tested work

When a code review is successful, the work is done. In this example, the code review's success is a transition from the status "Code Review" to the status "Done." And the resolution would be the reason why the code review failed.

Finally, you can set up transitions with:

• Conditions. They prevent an inadequate role from changing the status of an issue.
• Validators. These ensure a transition only occurs under certain circumstances. If not, the transition doesn't happen.
• Post functions. They describe actions on issues besides changing their status, and you can automate them. For instance, remove the resolution from a resolved issue before changing its status back to unresolved. Another example would be to remove the assignee from that issue.
• Properties. These are characteristics of transitions. For example, one characteristic could be to only show resolutions relevant to the type of issue.

6. Define ‘done’

Every team is unique. It’s made up of different people, different habits, and different experiences with technology and methods. Different ways of getting work done. This means you need to define what “work done” means to your team or your project.

For instance, you need to answer the following questions for your team or project:

• What status should a product or a feature have when it’s approved to launch or release?
• What should your team members do to get each work product to that status?
• Who should make decisions — such as approvals — along the way, which decisions, and at which points?
• Who declares work as done?

7. Customize Jira default workflow

Remember that you could use Jira to customize workflows to different ways of working as a team? Here’s how to do it:

Step #1: Define your workflow's statuses and transitions in Jira workflow designer.

You may go with Jira default Scrum or Kanban workflow — Jira classic templates — or make some changes to it. Alternatively, you may choose the Jira simplified Scrum workflow, which is adequate for reasonably basic requirements.

The simplified version of the Scrum workflow contains:

• Three statuses: "To Do", "In Progress", and "Done"
• Two transitions: from "To Do" to "In Progress" and from "In Progress" to "Done"
• Four columns to organize issues distributed across boards: "Backlog," "Selected for Development," "In Progress," and "Done"

Step #2: Build your workflow by adding components to the simplified Scrum workflow.

To track issue progress in agile development, you might add statuses such as "Code Review" and "Quality Assurance." And, you might add a validator to the transition from "Code Review" to "Done" to force that you need a successful code review to mark “Done.”

In addition, you might include approval stages in the workflow such as "Awaiting QA." These stages are prior to those in which an issue is closed or changes to a closed status.

Step #3: Nail the visual presentation of the diagram.

Once you finish tailoring the workflow to your team or project, make sure that the diagram is visually readable. That's essential when sharing the diagram with stakeholders for feedback. You should collect feedback from at least one representative of each kind of stakeholder.

An interesting feature of Jira is the workflow lets you give visual highlight of issues. This lets you see where the issue is in the workflow according to its status. Just open the issue and click on the "View Workflow" button next to the issue's status.

8. Rely on Jira reports for progress tracking

Jira provides two useful reports for tracking the team's work progress on a sprint:

• The Burndown Chart, which shows:
• The amount of work left to do in a sprint
• The work that team members are executing at the moment
• The distribution of work throughout the sprint
• Whether issues fit into the sprint and the effort estimation was adequate
  
• The Sprint Report, which includes:
• The Burndown Chart
• A list of open and closed issues for that sprint
• Extra work added to the sprint

As with any other report, Jira reports allow you to reason about success and failure. In this case, it's the success and failure of each sprint in terms of:

• Effort estimation
• Team performance
• Process irregularities
• Sprint planning

Most importantly, you can use Jira reports for the continuous improvement of those aspects and preventing problems such as:

• Too much work for a sprint
• Rushing work
• Sudden changes in priorities

A Jira workflow comes in handy when detecting outliers in the development process such as:

• A large number of open issues
• Frequent issue reopening
• A high number of unplanned issues added to the sprint

Being able to detect these problems is extremely valuable in that it helps avoid a massive sprint failure.

9. Share information

People at your company who aren't members of your team might need information from your workflow. So, take that into consideration when defining your team or project's workflow.

Those people might need to know about:

• The amount of completed work
• The product backlog dimension when compared to team performance
• The number of open and closed issues or the number of issues in a specific status
• The average issue completion time
• The average number of issues that take too long or experience bottlenecks, which means not moving forward at specific statuses such as "Quality Assurance"

10. Keep it simple

⚠️It can be tempting to create issue statuses while moving issues through the workflow, but don't do it! Each additional status adds more transitions and all their customized characteristics.

❌If your workflow already allows you to assess the sprint and feed your stakeholders with valuable information, that's just perfect. You don't need to add more issue statuses to it.

✔️Add extra issue statuses only when you have no other option. For instance, when different teams need to track work in different stages of development, you might need different statuses.

11. Limit work in progress

You may determine a specific limit to the number of issues in a specific status. When doing so, you should make sure all the team has enough work at each workflow status.

Plus, you should ensure that the limits you introduce into the workflow don't exceed the team's capacity. If you don't, the team will need to prioritize and you may not want that to happen.

Team performance should increase if you set the right work-in-progress limits. 🤗

12. Prepare to scale up

Agile teams should be small. Nevertheless, an agile workflow should cope with an increase in the number of people working with it. This means no one should notice if an increase takes place.

Here are some golden rules for scaling agile workflows:

• Agree on agile practices for workflow definition and minimize customization when multiple teams working on their own projects must collaborate.
• Different teams working on the same project should use the same workflow, or things could get messy.
• Teams should compromise when defining a common workflow. However, that's when teams build workflows based on multiple past successful experiences.

What else can you do?

Whenever you hear about workflows, it’s a sign that the work’s execution is being structured. It's also a sign of a long way ahead, but the outcome will be awesome if you:

• Follow the 12 rules above
• Choose a flexible issue tracker in terms of workflow customization, such as Jira
• Complement the issue tracker with the right apps

Don't force your team or project to comply with a tool. 😨 Rather, do the exact opposite! Choose the tool that allows you to build and implement the right workflow for your context.

That will increase throughput and workflow compliance levels, which is exactly what you want when creating a workflow.

Keep your agile approach strong — streamline, discuss, and iterate. These are the keywords for building and implementing an agile workflow, so don't forget them for a single second! As a result, you'll avoid:

• Complicating the workflow when it's not absolutely necessary
• Disregarding the pains of stakeholders and team members have when using or viewing the workflow
• Having an outdated workflow that's no longer adequate for both the company culture and the team culture

Kick your agile workflow up a notch

Easy Agile TeamRhythm helps you build and implement a Scrum workflow in Jira. Optimize your agile workflow by:

• Visualizing what the team will deliver and when by arranging user stories into sprint swimlanes
• Prioritizing user stories in each sprint by ordering them inside the respective sprint swimlane
• Reviewing sprint statistics at a glance to ensure that the team's capacity isn't exceeded
• Registering effort estimation in user stories.