A day in the life of Jamie

We’re checking the surf and haven’t talked in a while. Two sets of eyes locked on the ocean, is it worth paddling out this windy winter morning? “Where are you working now?” you ask distractedly. “I’m actually a software developer.”' Your eyes break from the swell, instinctively looking for signs of trauma or burnout. “Wow, you couldn’t have picked something more different!” you say, a little taken aback.

I have had some version of this conversation over and over since I made the switch from psychology to coding. People are often confused by how certain I am that I made the right choice, despite the fact that in my mid-thirties and around the birth of my first baby I discarded a lucrative career I spent a lot of time and effort pursuing, and to which I seemed to be well suited.

The truth is that making that change when I did vastly improved my health and my family's happiness. It was a privilege to work with my clients and share their innermost secrets, hopes and dreams. It was also extremely traumatic and disheartening, and was wearing me down. Then one day my wife said, “you don’t have to be a psychologist you know?” It may seem obvious, but that short sentence opened my mind.

I started to think about what else I might like to do. I’d always envied friends of mine who were carpenters or bricklayers and seemed to get so much satisfaction in gradually mastering their craft. Problem is, I am terrible with tools and can’t hammer a nail to save my life. A chat with a friend who is a coder where he spoke about his craft in the same way got me thinking.

I took a free online course to test the waters and was instantly hooked. I had to fight myself to go to bed at a decent time every night as I learned more and more about topics like CSS, browsers, clean code and asynchronous javascript. A couple of weeks later I started my masters in Information Technology and threw myself into it.

Ok, I thought, there is no way better to learn than on the job so I reached out to every company I could find within driving distance, offering to do anything even tangentially related to coding to get my foot in the door.

Thankfully, the Wollongong tech community (Hey there Siligong!) is open minded and two awesome companies, first FinoComp and now Easy Agile were able to look past my non-traditional background to see my potential.

I’m now a bonafide front end developer and am absolutely stoked to work everyday, expanding my toolset and honing my craft to build awesome products for our customers which improve their lives.

To anyone out there who is considering a career change, it’s never too late. It changed my life for the better and it could change yours too.

“The journey of a thousand miles begins with one step” Lao Tzu.

(Oh, you should definitely paddle out in that surf too. No matter the conditions a surf is always a good idea.)

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.

What is Cloud Fortified?

The Atlassian ecosystem keeps growing, and today there are over 5,300 apps and more than 1,600 partners, with customers installing so many products that meet a multitude of needs.

Atlassian products set a strong foundation of security and reliability and it only makes sense that the apps that clip onto these products are just as safe and secure. This is particularly true for enterprise organizations pursuing cloud migration who want to ensure their apps meet cloud security standards.

Enter Cloud Fortified.

The Cloud Fortified program and badge makes it super simple for customers to identify enterprise-ready cloud apps with additional security, reliability, and support.

In November 2021, the Easy Agile team proudly said “Wooohooo!” as we became Cloud Fortified across our full product range 🙌 🙌

Easy Agile Trust Center: You have put your trust in us and our products. Maintaining this trust will continue to be our priority.

What Easy Agile apps are Cloud Fortified?

Easy Agile TeamRhythm

Support your team from planning through to release and retrospective, and deliver products that your customers value, with our intuitive, agile solution in Jira.

Try Easy Agile TeamRhythm for free here

Register for a demo

Free Trial

Easy Agile Programs

The complete PI Planning solution for Jira. Ideal for distributed, remote or face-to-face Program Increment Planning.

Try Easy Agile Programs for free here

Register for a demo

Free Trial

Easy Agile Roadmaps

The simplest and most flexible roadmapping tool for Jira.

Try Easy Agile Roadmaps for free here

Register for a demo

Free trial

Easy Agile Personas

A customer centric approach to backlog refinement.

Try Easy Agile Personas for free here

Register for a demo

Free trial

Why is Cloud Fortified so important?

At Easy Agile, our customers are our highest priority. Cloud Fortified demonstrates our commitment to cloud security based on Atlassian’s programs and standards. It also is an easy way for our stakeholders to know that we meet Atlassian-aligned performance and reliability requirements and abide by strict support SLAs for an excellent cloud experience at scale.

Maximum security and continuous monitoring

Our Cloud Fortified apps are subject to the following four initiatives, which identify vulnerabilities at scale and shows our commitment to fixing these vulnerabilities and meeting Atlassian’s security baseline:

• Ecoscanner: Atlassian’s Ecoscanner platform continuously monitors all Marketplace cloud apps for common security vulnerabilities.
• Vulnerability Disclosure Program: Through this program, customers and security researchers can report cloud app vulnerabilities to Atlassian and Marketplace Partners. Atlassian runs this program and defines the parameters for all cloud apps.
• Cloud App Security Requirements: Atlassian has defined a minimum set of mandatory requirements that all Marketplace cloud apps must meet to ensure security best practices across our ecosystem.
• Security Bug Fix Policy: All Marketplace Partners are expected to meet Security Bug Fix SLAs to ensure cloud app vulnerabilities are addressed promptly.

Easy Agile also actively invests in two additional programs:

• Marketplace Bug Bounty Program: Through this program, we proactively combat security risks before they arise by incentivizing security researchers to find vulnerabilities
• Security Self-Assessment Program: Through this program, Easy Agile complete an annual security assessment that Atlassian reviews and approves.

Reliability at Scale

As Cloud Fortified apps, Easy Agile products undergo additional checks for service reliability and performance at scale, measured and monitored against service level indicators and objectives. We also proactively check to ensure future compatibility with Atlassian’s Jira to avoid disruptions. This means our Easy Agile apps are less likely to break in response to a Jira update.

As part of the Cloud Fortified certification, Easy Agile were also required to confirm our incident and change management process, that is integrated with Atlassian’s to allow for faster recovery time and continuous improvement. That means in the case of an incident there is a verified process to get back online fast.

Responsive Support

When you need help with one of our products, know that we will be there. Our Cloud Fortified apps abide by strict support SLAs. If one of our Easy Agile apps has a problem, we will get back to you within 24 hours, 5 days a week during local business hours.

Read more about our Service Level Agreement and commitment to you.

Our Support

Learn more about our Security practices

The Easy Agile Trust Center has been created to help you and your team feel confident in our products security, reliability and privacy. If you want to learn more about how we are looking after your security needs, visit our Easy Agile Trust Center.

Learn More