Company

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

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

What is SOC 2 Type II Compliance?

System and Organization Controls (SOC) 2 is a widely recognized security standard developed by the AICPA that specifies how organizations should manage customer data. A SOC 2 report is often the primary document that security departments rely on to assess a service provider's ability to maintain adequate security.

Service providers like Easy Agile voluntarily undergo a rigorous audit and assessment to ensure their security controls meet AICPA’s Trust Services Criteria, including:

• Security
• Availability
• Processing integrity
• Confidentiality

SOC 2 compliance comes in two forms: A SOC 2 Type I report describes the design of a service provider’s system controls to meet relevant trust criteria as of a specific point in time, while a SOC 2 Type II report details the operational effectiveness of those systems controls to perform as designed over a specified period. An independent auditor, Johanson Group, has reviewed and certified that our processes, procedures, and controls are properly designed to meet the SOC 2 standards.

What does this mean for you?

Our achievement of SOC 2 Type II compliance means that when you use Easy Agile's services, you can continue to 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 ISO 27001 coming?

Now that we've completed our SOC 2 Type II compliance we'll be setting our sights on ISO 27001 compliance in the next 12 to 18 months.

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 II compliance and what it means for you, please feel free to reach out to our team at security@easyagile.com.

💬 “We know we’ve created something special, an ESOP like no other…”

Nick and I started Easy Agile after returning home to Australia from living and working in San Francisco where we witnessed the good and not-so-good sides of startups.

We were lucky to experience first-hand the amazing career opportunities and growth that working for successful companies such as Atlassian and Twitter can provide. On the other hand, we also saw companies start-up, consume vast amounts of funding and flame out. There was a terrible toll taken on our founder friends and their families who put life balance aside in pursuit of success at any cost.

We took all of this into consideration when we started Easy Agile. We didn't want to default to the standard VC-backed journey so we set our own pace. We wanted to learn what it was to build a customer-funded, sustainable growth product business, even if that meant a more difficult learning curve as we carved our own path.

Well, that was 6 years ago and here we are happily customer-funded for over 5 of those years, growing at an exciting rate, we believe is healthy and sustainable. We're proud that we're bootstrapped and we're not really looking to change that.

💬 “We can do things differently”

One part of the common startup playbook which we did want to retain is employee ownership. We have been dying to introduce an ESOP for a long time, however, being bootstrapped and customer-funded makes creating an Employee Share Option Plan a bit more complicated. Off-the-shelf plans are usually based around the concept of a planned (or hoped for) exit event, as it’s the only time cash-burning companies can realise value for shareholders. This would not work for us and we were looking to provide a more accessible way for our team to realise the value gains as we grow.

We also knew in our hearts that our ESOP had to be a reflection of Easy Agile's values. We understand the wonderful people that make up Easy Agile are all at different stages of their careers and have different needs financially so we designed our ESOP to take this into consideration.

Our ESOP also had to be generous. Nick and I really want to continue to pay forward the generosity we’ve been privileged to experience and enable our entire Easy Agile team to have the opportunity to achieve financial freedom. We hope one day many of our Easy Agile team will find themselves as founders of successful companies and continue this tradition with their own ESOPs. 🤞

Now our ESOP is live, we know we’ve created something special, an ESOP like no other. There’s no standard template for what we’ve built as very few startups or scale-ups in Australia are in our position. We’re growing fast, we’re profitable and we aren’t constrained by investor demands.

It means we can do things differently.

How the Easy Agile ESOP is different

1. Generous valuation from the start

For our initial grant of options, we valued Easy Agile using a super-low valuation. This gives our initial option grant the highest immediate appreciation of value on paper we can give.

This type of valuation based on our "Net Tangible Assets" (NTA) is made possible by the Australian Start-up Tax Concessions. Being a software company, our assets are limited to the cash in our bank and some laptops. We have no debt.

At the same time, we also have a “Fair Market Value “(FMV) calculated similarly to other SaaS companies. It worked out that our NTA valuation for our initial grant was 44 times lower than our FMV valuation meaning by accepting your options, on paper, your options are already worth 44 times more than you will ever pay to exercise them.

We feel this is pretty special.

2. Real $ value for our team more often through an Option Buy-Back

We understand that our team members all have different needs financially. Some have mortgages. Others want to buy a house. Others are happy to rent and invest in other things.

We’ve ensured our team has the opportunity to realise an exit at a time more suitable to their personal needs.

Our Option buy-back scheme allows Easy Agile, to offer to buy back vested options from our team at the Fair Market Value. Our team can choose to take advantage of the company’s growth and turn some of their Options into cash far more readily than waiting for an exit event (IPO, secondary, sale, etc). This is a profoundly different concept from most SaaS companies. They can also choose to hold onto their Options for the long-term gains we all work together to achieve.

3. Dividends

Most SaaS product companies don't really get to a dividend issuing phase. They simply don’t have the profits available. Once again, we're different here. We have a sustainable growth trajectory enabling Nick and I to issue dividends to shareholders over the course of the life of Easy Agile. We will continue to do this in the future and so Easy Agile shareholders will benefit long-term with dividends and voting rights that come with Ordinary shares.

4. You can nominate a trust

We allow you to nominate a trust to hold your share-holding. Nick and I are fans of getting serious about financial planning and literacy (just ask our team!). We wanted to give our team the most flexibility we could, so we allow for our team members to nominate a trust to receive their options instead of themselves personally.

What’s next?

We’re thrilled to be at this stage in our journey as it enables Nick and I to better reward the team who have built Easy Agile with us.

We’re even more excited about the journey ahead. We have big plans, the ability to invest in our team, our products, our growth and most importantly the impact we are having for our customers.

We’re always hiring so please reach out if you want to be part of the team that’s leading the way in helping companies around the world be agile.

💬 “We hope one day many of our Easy Agile team will find themselves as founders of successful companies and continue this tradition with their own ESOPs”

Earlier this year on a call with Michael Dockery, Chief Strategist of Design Industries (DI) in Melbourne, Australia, I asked: "What could we do better?"

Michael said, "...a way for vendors that worked with us to improve the way partnerships are promoted."

With that suggestion, the Easy Agile Meet the Partner interview series was born. Fittingly, our first interview is with the company that suggested the initiative.

Design Industries are obsessed with improving the productivity of their Enterprise & Government clients. They do this by optimising their clients' usage of Atlassian tools and implementing best practices while ensuring the platform and apps remain highly available through their partnerships with AWS and Ali Cloud.

Here is a conversation we had with Michael, Philip (Marketing & Comms Director) and Alice (Executive Business Partner). We discussed who they are and what they do, including some common IT acronyms you can learn about if you look them up :)

How did you encounter the Atlassian Platform?

Michael: Design Industries started as a web development company. We were doing custom code, then e-commerce content management systems, web builds, startup consulting, custom API mapping - all sorts of stuff! We took up Atlassian for our service delivery as we were using SVN, I think it was Base Camp, and other tools at the time. We knew we needed something else. I looked at lots of platforms for years and was looking at every project management tool out there.

I noticed Jira and thought that it looks complicated, a bit overwhelming, and then I saw the price - this was when Atlassian released their software as a service product - $10 for ten users! Everything else was $160 per user per month, so we took it up, and in hindsight that was a great decision.

And where is the Design Industries business today?

Michael: We're now half in Melbourne, half in Cebu in the Philippines. We support clients across Australia and help them to make the most of the Atlassian stack. Most of what we do is assisting around project management solutions, so organisations come to us and say, "We want to use Atlassian," or, "We are using Atlassian for project management, can you help us?" And the primary use case is around ITSM (IT Service Management), where they want to run some type of ITIL practice, so we help out with that.

There are also a lot of custom scenarios: a marketing, finance or HR team wanting to improve their workflows. What we've done is created predefined configuration sets for all those different types of operational core competencies to solve their recurring challenges.

Essentially we help organisations fast-start their practice or give a quick uplift to their capabilities by implementing these predefined configuration sets. This is how we support leading companies to make the most out of the Atlassian Enterprise stack. The next step is not only to support the platform and enhance its capability: it's being able to do that on a continual basis - which is where we are leading the market.

What we do with a lot of our clients is continually deliver improvements to the platforms: whether that's improvements in configurations or reporting; additional plugins; retiring other software platforms in the environment; onboarding teams and functions; integration with other platforms and applications in the background.

Are there any notable customer projects that you could mention?

Michael: There are quite a few listed on our website. We helped a significant retailer move onto the Atlassian platform as a core operations piece, assisting them in standing up their Atlassian Data Center environment. We put our standardised configurations for project management in and then we migrated their disparate platforms onto a primary enterprise instance. They were able to standardise and consolidate their Atlassian instances, so that was pretty cool!

Then there was another notable sizeable financial company. Again, Design Industries helped them stand up an Atlassian stack with our predefined configuration sets and, this time, in our managed AWS service. We then took the encrypted data from their parent company and imported it into this new environment. It has now grown to be the enterprise stack — their core delivery platform.

Philip: Each time another major company comes to us, it helps build our pool of knowledge. We often hear customers saying, "Wow! What, you mean you can press a button stand up an Atlassian instance? And then we have enterprise maturity as a scalable framework?"

We respond with, "Yeah, that's what we sell here. We give you a step-change in your organisational efficiency."

Where do you see common pitfalls occur when a customer begins deploying Atlassian tools?

Michael: That's simple — doing it yourself, giving too much Administration rights to people who aren't trained, aren't qualified and implementing it in an ungoverned way. That's a big mistake! However, I've seen it work as a change strategy. You know you can't make such a massive change without allowing people to do it themselves. So throw it over the fence go "OK, here is the tool, run with it" and then hope that the users get excited. When they get excited, then come back and retrofit the policy and do the cleanup, put the process on top and then retrain everyone.

If you've worked in IT or change management before, I'm sure you would agree taking that strategy is a costly mistake. It's better to do it the right way from day one and govern it with a vision in mind. It's an enterprise platform, not an insignificant piece. What part of "mission-critical" don't people understand?

Amongst the Atlassian ecosystem, is there anything that excites you as being "the future"?

Philip: Automated test cases!

Michael: What excites is it's pretty unlimited what we can do, and the capabilities are going to increase. I can see how this platform is beautifully set for some future trends, particularly around automation. I'm just excited that there's so much to do in this space. There are so many businesses that could use the capability that the platform can bring, and most - even if they've already got it - are barely scratching the sides of what's possible. We could close the doors for six months and work on ourselves and our processes!

Philip: Two years ago, we were having conversations about the massive efficiency that could be gained in government by taking on more Agile Project Management. There is so much waste that goes along with poorly managed projects and the associated rework. Then there are things like responding to natural disasters, where you can stand up a fit-for-purpose project management environment, notify the relevant people, get co-ordinating and deliver change on the ground.

Michael: Automated responses to predefined plan execution. I can think of so many things!

So when it comes to Agile, where are your customers these days?

Michael: What is interesting with Agile is the world has turned. I think everyone is now somewhere in the Agile journey, and that has changed from a few years ago. I guess the approach and the degrees of success vary significantly between our clients. Walking into offices, I still see many wallboards and sticky notes. There is always room for improvement.

The journey has begun. Some are doing it well; most can improve; everyone is in the middle. It's interesting times in the space.

There's the opportunity to optimise Agile processes everywhere!

Michael: I think it's just hard! I read about what they call "zero budgeting", which is a method to do budget allocation for Agile projects.

That is such a massive shift in how projects get funded and defunded. If you're going to sit there and say, "OK, we want to measure the value that's being returned on a live basis so that we can fund and defund on an agile basis," you've got to have the tooling in place. If you can't do proper portfolio reporting, you can't tell me what all of your initiatives are.

That means you have to have some type of standardisation in the delivery tool and in the portfolio. You can sit there and go, "OK, I can see my initiatives. I can see what's delivering value. I'm now going to make a monthly budget decision."

So it gets away from these big projects, where most of the C-Level still operates, to where they make funding decisions once a month. These decisions are much smaller, and they're based on who's doing well.

With Agile, there are different interpretations and you've seen different maturity levels in organisations. What resources do you provide to customers? How do you help them find clarity?

Michael: In terms of resources, I used to buy a book called The Lean Startup and give it away like crazy. So that teaches you Lean and Agile, and I think people need to go through the Agile "light bulb" moment. I very distinctly remember when I had my light bulb moment with Agile - there was a before and after. Before, it was confusion, and after, "Aha! I understand this now!" I still think that goes on for a lot of people.

The other one is Lean, and I think that's part of the Agile "light bulb" thing. As a senior stakeholder, you want to achieve things; you're going to invest in things. But having an understanding of what a lean approach looks like, and how a lean approach can be executed, helps a senior executive who typically won't have the time to go out to Agile training. It helps them get a sense of how to structure work, make it small, deliver some value.

The Lean Startup book was what you used to advise before. What do you do now?

Michael: * jokingly * I tell people to get the book!

In all seriousness, there are a couple of principles that you need to understand, and they are similar but different. Waterfall has milestones, Agile has a release. Waterfall has a week of work, Agile has a sprint which you set yourself. For example, a sprint may be one, two or three weeks - we use weekly. You get up on a Monday and say "What are we delivering this week?"

The benefit of Agile is delivering value fast and getting feedback fast, to inform your next delivery. In Waterfall, you're following a predetermined plan that is resistant to change. I like to think of it is as "What are we doing this week?" in Waterfall and "What are we delivering this week?" in Agile.

Lean-Agile is the next step, coupling lean principles to Agile methodology. It's well worth understanding if you're looking to the future. The Lean Startup, it's a classic. People ask, "How do you start a business? What's the most you need?" The most you need is literally a piece of paper and a pencil, and he gives examples of this. You can then say "I don't need $100k to start a business. I need a piece of paper and a pencil." It becomes a lot more achievable.

With these lean startup principles, what have you seen in large enterprise or government that has been successfully deployed?

Michael: They will talk about it in The Lean Startup and call it a "Tiger Team", and that's how most organisations have ended up doing it. Find a team that is a bit more innovative, a bit more flexible and seed the practice. Then with executive support, go, "OK, we're going to change the methodology. How do we do this? How do we find a team who's up to it?" You then get them trained, get them implemented, get the process sorted, get a best practice approach, you roadshow it and roll it out to the organisation. I think that's happened for the executives that have decided to go to Agile. The rest are just fumbling through at the moment.

Where do they need help if they're fumbling through?

Michael: More of a realisation that the toolchain is really important. Agile means you still need to have a written process. You need to have an elaborated work breakdown structure, and make it clear to the team how they're going to break up the work and put it through the system, even though they're "Agile". It still requires a project management configuration and then portfolio reporting.

If you've got the teams running their own processes, it's highly ineffective. We see divisions such as, "Team A are using Story Points, Team B use Estimation, Team C use nothing... and Team D, well, they kind of do it their own way - I think they're Waterfall". What a mess!

The whole process requires someone responsible. Most organisations have this initiative going on called "digital transformation". It requires an individual who is in charge of digital transformation to be able to make decisions on methodology when it comes to project management and how that interrelates with the tooling.

Philip: I think of it like showing senior executives fire for the first time. They haven't ever had reporting down to the level we are talking about once you've got the bottom up using this toolset. Previously, the reporting culture was, "Can you provide us with five slides for the senior exec or the board pitch?" where now it comes to, "Well, you can report on everything now at the click of a button and you can see it in real-time."

So it empowers at the top level, and it frees people up to work on high-value tasks.

You mentioned Eric Ries with The Lean Startup. Any other thought leaders that you follow?

Michael: *laughing* McLaren.

Philip: Michael's obsessed with Formula 1. It's a bit of a driving force behind how we do things here.

Michael: Formula 1 certainly is an interesting analogy. I don't know if it is in terms of thought leaders, but in terms of an area of inspiration, definitely Formula 1 and how it works because there's a lot to it. It's teamwork.

It's high-performance teams, high-performance machines. I look at the way we configured the tooling, and it's our high-performance machine.

It's probably not as exciting as a Formula 1 car, but it's what we've got, and we certainly get to drive it - but it's not as dangerous either!

We know you love Easy Agile apps. Any other Atlassian Marketplace apps you love recommending?

Michael:Riada Insight Asset Management is really powerful. For a lot of organisations when it comes to ITSM tooling, the monitoring tooling, the asset management tooling, and the ticketing tooling aren't integrated. It is quite tangled. So when an organisation is looking at Jira Service Desk, it's a no brainer.

Then there is Tempo Time Tracking. When one of our clients want to bill their clients, or they need to manage their budgets effectively, it works perfectly. It also lends towards capacity management. A lot of organisations struggle with their capacity management. Using that suite makes it super easy.

Lastly, if a customer would ever like to get in touch, what's the best way?

Philip: They call us at 1300 736 363. They can also fill out a contact form on our website. The form gets responded to quickly. We generally respond within an hour. We usually then book in a call. If it is a relatively straightforward request, we can get a proposal back within 12-24 hours.

Atlassian alumni make up a part of the Easy Agile team, with several former Atlassian staff working within the Easy Agile business. We had a chance to speak to another member of this extended alumni ‘family’,  Boris Berenberg. Boris is an ex-Atlassian who eventually went on to found the New York HQ Atlassian Solution Partner Atlas Authority.

It was a particularly exciting day for us to catch up with Boris, as after a mere 3 1/2 years, Atlas Authority achieved Gold Partner status with Atlassian.

Personally, I had the pleasure of working just metres away from Boris in the San Francisco office. It was great to hear his journey, and learn how the Atlas Authority team have grown to double-digit staff members based in multiple countries in such a short amount of time. Meet Atlas Authority, an Easy Agile Partner.

How did you end up working for Atlassian?

I found Atlassian because a friend that I went to college with told me about this company that he was working for that paid to send him to Amsterdam for three months. And I thought that sounded cool. So this ‘perk’ was the driver for me getting into it.

An obscure way to ‘find Jira’!

Well, I started my in-depth learning of Jira at Atlassian because I helped write a lot of the performance tuning documentation when I was there. A lot of this work was done by the Sydney support team and I ended up dealing with most of the performance-related tickets that were coming into the San Francisco office at the time.

So when I left Atlassian, my particular skill set that very few other people had was, how do you make your Jira faster?

How do you get a performance improvement on Jira?  That was my expertise.

So after Atlassian, you started Atlas Authority?

I needed something after Atlassian and I went to work for another company.  During the interview process I recommended they look for a  contractor for a few months but they still felt the role required a full-time staff member. So I joined them. It was a great job and a great team. Three months in, I was sitting there with nothing to do, kind of like I had predicted. So I went to the CTO, who was my boss at the time, and I said, look, my number one mandate has been to reduce Atlassian spending at this point. I'm going to go work somewhere else and wishing you guys the best of luck.

And at that point, I went to go work at Uber, and Uber was probably the best team I've ever worked on in my life. We're working with one of the largest Atlassian deployments in the world at the time; we were just all on the same page. Having that level of understanding and shared expectations on a team was just out of this world.

So because of my tenure at Uber, I had some ideas at the time around how an Atlassian practice should be run and I started Atlas Authority to see if my ideas were right or wrong. If my ideas turned out to be right to some subset of the market, then we could be a successful company.

I guess three and a half years later, we are. We are now almost 10 people in 3 countries.

So would you class your expertise as being Atlassian application performance focussed today?

Well we used to focus specifically on that, for instance, we helped the largest telco in America reduce their average Jira page load time from 12 seconds to 4.5 seconds. So a huge improvement.

At the same time, whilst our business grew, Atlassian was doing a really great job of improving the performance and stability of Data Center deployments, and they've done a really great job in Jira 8.0 around indexing performance. If you monitor Jira releases, you'll see that there's a pretty steady stream of performance-related and scale-related issues being resolved.

We knew that we couldn't continue to focus on that. We've kind of become a more general Atlassian partner at this point. We still tend to work with very large Data Center deployments with people doing highly technical implementations that involve very heavy, hands-on analysis, or writing custom code. We do data transformations from migrations from and to the cloud. We help with plugin migrations. Still very complex problems, but different from where we started.

Today, we also have a portfolio of 13 Atlassian Marketplace apps we call our own.

Were these marketplace applications from customer needs?

We created Atlas Authority’s marketplace business in a couple of different ways. Atlassian has a regular event called Ship It. Back in the day when I first joined, the support team was notorious for not participating in these events because while everyone else can stop doing their jobs for 24 hours, the support team found it hard to participate because they had to respond to customers. So I did my best to participate.

I created the Markdown Macro app and took second or third place for that Add-on during the ShipIt. And I won a ticket to the Dropbox developer conference at the time when the Developer Relations team picked me as their winner.

When we got started with Atlas Authority, Atlassian actually granted us the ability to continue to manage that plugin. And so at this point, it's grown to about 5000 installations and millions of end users. We push updates to it regularly & it started our journey into the Atlassian Marketplace.

Which add-on do you think solves the biggest problem?

Our customers are predominantly large organizations. Communicating within them is tough. For instance, people will say, “Hey, you know, my CTO doesn't understand the work that we do in Jira. If we purchase a reporting plugin, it may serve that information up better”. The thing is, a CTO doesn't want to go to Jira in the first place.

Most CTO’s sit in twelve meetings a day and make technical decisions. There’s not a lot of time to go digging through a tool. So providing a Monday morning email that summarizes exactly what's going on in the various initiatives automates updates and improves communication.

It means that you can bring the right message, in the right format, to the right person, at the right time.

The ‘push’ nature and the ubiquity of email makes our Notification Assistant for Jira a real elegant solution.

Does Atlas Authority use Agile methodologies to run the business?

I have had an interesting journey with Agile because when I was working at Atlassian, I built a tool using my 20 percent time. The tool did great, but the project completely failed because we hit the goals of the finance team and not the support team that was paying for the work that we were doing. So classic project failure scenario. A really hard lesson, and a reminder why a core tenant of Agile is to ensure your stakeholders are involved in what you’re building.

Now in the consulting world and owning our own products, we deal with Agile constantly, both in a delivery capacity as well as an internal capacity. Internally, we happen to use Scrum for a lot of the software development work we do. We heavily utilize Kanban on the support side.

So that was how you ran into Easy Agile products?

We were essentially using Easy Agile Roadmaps for two things. Our product development org is a bit scrum-fall. A portion of waterfall at a high level. Similar to program level planning, or doing theme or initiative level planning, but using a roadmap. And then we break it down as we get close to it and use a more traditional methodology to accomplish that.

On the other side, we were also using Easy Agile Roadmaps as a tool to visualize our consulting engagement work. As a way of seeing which customer engagements are running in parallel and what resources are associated with those customer engagements.

If we have a person working part time on a  customer migration, and that migration is going to take three months, we need to be able to visualize that. We needed a light-weight tool that could deliver this for us at that time.

So you use Easy Agile Roadmaps to run your business! We are honoured. Have you encountered us at any customer sites?

We do, but we don't notice them for all of the right reasons!

We resell a lot of plugins, and a strong statement of support of Easy Agile’s tools is they work so well that we don't have to do very much handholding of customers. We don't have to do a ton of training. The UX is done really well. The visual design is done in such a way that it fits into the narrative of Jira as visual design. So a user doesn't need to learn a new visual terminology.

From a performance perspective, from some other vendors, we may see obscure issues. For instance, when we may see a background synchronization job running and it’s causing everything to slow down. Another common issue that we see is that large organizations tend to have similar time-based patterns of plugin usage when it comes using these tools. Another example is when everybody across the organization does their P.I. planning on the same day at roughly the same time.

If that tool is not built in such a way that takes into account this parallelism you can encounter serious problems when people are depending on the product. A lot of the time an application may have low usage 90 percent of the time. And then 10 per cent you will encounter crazy spikes in terms of what that application is asking Jira's backend to do which can make it all fall over.

I don't think we've had to deal with a single complaint about Easy Agile apps in three and a half years of consulting. That's amazing.

Thanks for your time Boris, but I have to ask, did you ever get to Amsterdam?

So that's a great question. So during my interview with Atlassian, they asked me why I applied. I mentioned the secondment was a common thing I heard about the company. They said, absolutely, you can do that with us. I should have gotten it in writing as it took over 3 years to get there!

But it was worth it the wait, I had an amazing time. I loved Amsterdam and I've gotten back five or six times since then.

It's been one of my favourite cities in the world that I've ever gone to and I particularly enjoyed working with the team there.

Atlassian Authority has been acquired by Modus Create.

Need help? Get in touch with Modus Create or follow them on Twitter, LinkedIn or Facebook.

Easy Agile’s purpose is to find a better way to work. Back in 2018 we consciously acknowledged that what got us here👇🏼, won’t get us there 👉🏼. In other words, we have to change to achieve our goals. The real challenge is to proactively seek change rather than being forced into it.

"We believe there is a better way to work"

What got us here

When Easy Agile (then Arijea) first started out in 2016, Nick and I would spend a full third of our day discussing what we were going to do and how we were going to do it, (which is a pretty good idea when you don’t know what you’re doing!). It was these conversations, along with reading Thinking Fast and Slow, Deep Work and Small Giants which formed the basis of some of our company values and how we work at Easy Agile. We still talk a lot, not quite a third of the day, but it’s more around how we’ll work, rather than what we’ll work on.

A quick history: 2016 - 2018

A lot happened in the first few years of Easy Agile’s existence. We created some successful products, travelled around the world to Atlassian events and generally had a bunch of fun. We also built huge backlogs of work we’d never, ever start, let alone finish.

Back then our situation was a little different to most other software companies. We had more products than developers! At one point we had 5 products and 1 developer. This improved to 3 developers and 2 products, but even still, our internal systems and other non-customer-facing work never seemed to get started.

These early years were chaotic, which was entirely my fault. It was my reluctance to give up coding that meant I was lost in the weeds rather than zooming out and attempting to build a fantastic team. We were just plodding on, looking at our shoes and getting distracted by little things instead of stopping, reflecting and committing to our core purpose. I needed to change my ways to help the team improve. Thankfully I remembered a really cool video which eventually would become the impetus for me changing my focus from code to the team...

I’ve watched this video countless times over past few years. Every time I do, it makes me feel so lucky that I worked at Atlassian and was able to partake in ShipIt and Innovation Weeks. I highly recommend you take the time to watch it if you haven’t already.

The importance of Autonomy, Master and Purpose

The ideas this video presents around autonomy, mastery and purpose propelled me to think beyond simply how we work to think about the reasons why we work. Naturally, the first thing that comes to mind is money. Having enough money is vital to live a fulfilling life (which I’m proud to say we strive to provide at Easy Agile), however, as covered in the video above, more money is not necessarily a great motivator. It’s autonomy, mastery and purpose which provide that.

So whilst I was taking a step back to create a better way of working, I figured we may as well try to bake in autonomy, mastery and purpose along with a provision to prevent some undesirables from creeping in. The main culprits I had in my sights are bureaucracy, red tape, sacred cows, legacy systems and politics.

If you’re going to the effort to building an amazing team of talented people, taking time out of their lives to work for you, the last thing you want to do is get in their way with pointless rituals which just stifle their creativity and waste their time!

Gaining perspective by zooming out

Being a software company, Easy Agile’s heart beat is our software development process. However nowadays we do so much more than develop software. All of our team communicate directly with our customers daily via customer support, we have fantastic marketers, product managers and a data analyst. We needed a way of working which went beyond backlogs and estimation and brought everyone together to push in unison towards our goals.

We do our best work together in cross-functional teams so I wanted to bake that in from the start, rather than build silos as we grew. We started out by having everyone work off one backlog and scheduled all of our work in Jira (including Sean, our first marketing hire). However, as you can guess, this doesn’t scale. The details discussed at our planning sessions became irrelevant to most of the team. We ended up only skimming over most of the details which made planning and estimation mostly irrelevant.

In early 2019 I made it my mission to get serious about finding a better way to work. So I stopped coding (it was frightful founder-code anyway). Since then we’ve been through four revisions of our development process. We’ve even made “finding a better way to work” our motto.

The details of this transformation is beyond the scope of this blog post, however, let’s just say that we’ve gone from a chaotic, unmanaged backlog to a far more organised and considered approach to work. The current revision of our development process allows us to work on (and dogfood) our products and our internal systems simultaneously. It scales with us as we grow, encourages cross-functional teams and bakes in our company values as well as autonomy, mastery and purpose for all team members.

Shape Up by Basecamp forms the foundation of how we work

I was first made aware of Basecamp’s Shape Up in a comment Nick made on a blog post I wrote announcing one of the aforementioned revisions of our development process. It was 4 months later when I’d started my hunt in earnest for a better way to work that I remembered it and, upon re-reading it, felt it might just work.

In Shape Up you work in 6 week cycles which is just long enough to do something tangible, but short enough not to feel that the deadline is too far away. This is followed by a 2 week “cool down” where everyone is free to fix bugs, try out something new and gather themselves for the next six week cycle. At Easy Agile, we already worked in a “product” cycle, where we would focus on one product after another, so this idea fit in well.

Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The majority of our new features are built and released in one six-week cycle.

Shape Up goes on to propose the concept of “pitches” and “bets”. A pitch is a refined description of a feature or change large enough to have a meaningful impact on the company if it is successfully delivered.

Shape Up takes its name from the “shaping” process applied to forming a pitch. Shaping a pitch is simply taking the time to focus on the problem and define a good solution. You are encouraged to pull in people you trust to “hammer the scope” of your pitch so it is very clear what it does and does not do. This appeals to our “Engage System 2” and “Commit, as a team” values.

I’m not a betting type of person, and seeing as that viewpoint seemed fairly prevalent in the team, we came up with an alternative vernacular: Opportunity.

What is an opportunity?

Opportunities ratify the work of our Product Managers. They may take up to four weeks or longer to shape which is in stark contrast to other workplaces where product managers are responsible for “feeding the beast” (finding, or making up, work to keep the development team at full capacity).

Opportunities represent either 2 or 4 weeks of work. Anything less and it’s probably not really worth doing, or it is a small improvement, which is done by our Small Improvements team (more on that later).

Our cycle

Where Shape Up’s cycle is a total of eight weeks, we’re currently experimenting with a six week cycle. We have four weeks of work on Opportunities followed by a week of paying down Technical Debt, go to market and final Opportunity shaping. We round out with a couple of Dash Days (more on that later too).

1. How we shape and select Opportunities

Shaping opportunities primarily falls on the shoulders of our Product Managers, Teagan and Elizabeth. Anyone can raise an Opportunity ticket in Jira, but by doing so it also means taking complete ownership of guiding it through development, testing, production and monitoring its health and metrics after launch. For this reason we usually recommend working with a product manager to flesh it out.

The process of shaping and scope hammering is generally done with a few collaborators who can provide perspective on all of the moving parts involved in what you’re attempting to do.

Currently we attempt to select the Opportunities which will put Easy Agile in the best possible position to achieve our goals (aka our quarterly and annual OKRs). Opportunities which are not properly scoped or shaped will be sent back to the drawing board to come back around in another 6 weeks.

We are currently exploring how we can improve the Opportunity selection process. The betting table meeting described in Shape Up is one way to select what to work on, however we feel there is a better way which we haven’t quite put our finger on yet. Ideally each Opportunity will help us move towards of one or more of our top-line goals. Baking our OKRs into our work planning keeps them at top of mind throughout the year.

2. Opportunity team formation

The autonomy part of our development process really sings when it comes to team formation. With only one exception**, all teams are self-selected and formed of exactly three development team members (a senior, mid and junior team member - something we are still actively hiring for). Team members from product management, data analysis and marketing join to create truly cross-functional teams. This means when the Opportunity goes live, all of the required marketing material, documentation and other non-development work is ready to be rolled out allowing us to move on to Tech Debt / Go to Market / Shaping Week.

We chose three team members per Opportunity as this allows each team to self-serve their own pull requests. Our pull requests require at least two approvals to be merged. Having three team members reduces the disturbances and context switching being forced onto other teams.

**A small team works on bugs and small improvements on a 2 week Opportunity which is always selected. The team members for this team work on a rotation so everyone gets their go.

3. Tech Debt / Go to Market / Shaping and Selection week (yes - we need a better name)

In the week following the completion of our 4 weeks of Opportunity work, the development team takes a week to focus on technical debt or improving their development environment. We also use this week as a rollover buffer to close out any work which was not completed in the Opportunity weeks. We try to keep rollover to a bare minimum.

The marketing team will roll out any of the initiatives they built in the prior four weeks to support any new features which were shipped.

The Product Management team will crack on with finishing up the shaping of their Opportunities and have them ready to work through with the team for the next Opportunity cycle.

4. Dash Days

Dash days (formerly Inception Week) is a period of freedom and autonomy to work on a pursuit of your choosing which, when successful, will ideally lead us to think “How did we live without this before!?”. They are essentially a mix of ShipIt / Innovation Weeks / 20% Time which I experienced at Atlassian. They’re a great avenue to release the creativity of our team.

Some recent successful Dash Days projects.

1. Easy Agile Personas
2. Our Dev Container vscode setup
3. “Mr. Tulip” (our Slack bot which almost does everything)
4. In-product NPS
5. The Easy Agile Podcast
6. Our deployment dashboard (showing the number of days since a Cloud or On-premise deployment)
7. Powering our website with Sanity.io CMS
8. ea-kit (our own component library)
9. A new random forest churn model to better understand our customers frustrations
10. Our own logo/brand design framework

As you can see, there’s a great deal of diversity in the Dash Days projects we have shipped. Shipping is not a requirement of Dash Days, though. Quite often it’s best to take some time to try out some new ideas or build a prototype to put in front of customers.

A great example of that is a feature refinement developed by Sam and Angad, two of our newest front-end developers. They worked with our Product team to build a new way to create issue dependencies in Easy Agile Programs. Their definition of done was not releasing to production, but to get it on a test server which we used for customer interviews run by our Product Managers, Teagan and Elizabeth. The following Dash Days Sam and Angad took this feedback, refined the feature with the product teams' help and shipped a version to the Cloud version of Easy Agile Programs. So far the new dependency creation approach appears to be 10 times more popular! Success!

Dash Days is also a great time for team members to take advantage of their $5000 Learning and Development budget which each team member receives every year.

Shaping a new way to work

Introducing a Shape Up flavoured process here at Easy Agile has allowed us to gain focus and certainty in the work we choose to take on. It allows us to have long term goals without the need to build inflexible roadmaps. Our Product Managers are encouraged to take the time they need to focus and design amazing new solutions for our customers. The 6 week cycle grants us the flexibility to react to external changes or take advantage of new opportunities which arise without derailing the plans for the remainder of the year. We can take the learnings from our past Opportunities and feed them into the plan for the next, increasing our chances of success.

Easy Agile’s development teams are flexible and choose who they work with and what they work on. We constantly pay down tech debt and shun red tape, legacy systems and sacred cows. We work in cross-functional and fluid teams.

We’ve been able to adopt Shape Up and bake in things like Dash Days and our company values. We love that the way we work allows us (and encourages us) to stop, take a breath and express our creativity every 6 weeks. Tech Debt Week and Dash Days are also a great way to increase the focus of our development team on their main projects by deferring any small tasks which interrupt and distract them.

We believe a steady, life-inclusive and balanced approach where we bring our whole selves to work each day is better than burning ourselves out in the pursuit of unrealistic deadlines.

And finally, as we grow, we know that the system which runs Easy Agile will continue to change to help us find a better way to work.