How we work at Easy Agile
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.
- Easy Agile Personas
- Our Dev Container vscode setup
- “Mr. Tulip” (our Slack bot which almost does everything)
- In-product NPS
- The Easy Agile Podcast
- Our deployment dashboard (showing the number of days since a Cloud or On-premise deployment)
- Powering our website with Sanity.io CMS
- ea-kit (our own component library)
- A new random forest churn model to better understand our customers frustrations
- 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.
Related Articles
ProductRethinking our UI: How Easy Agile innovates for a better user experience
At Easy Agile, we’re constantly looking for new ways to improve our products, and one of the ways we foster innovation is through Dash Days—a focused period where our team steps away from daily tasks to experiment, explore, and reimagine how our tools can better serve customers.
During our most recent Dash Days, we took a fresh look at the user interface of two of our flagship products, Easy Agile TeamRhythym and Easy Agile Programs. The goal was to enhance interaction and discoverability, so users can experience the full value of our tools without unnecessary complexity.
Here’s a glimpse into our thought process, challenges, and the exciting solutions we explored.
The challenge
As Easy Agile TeamRhythym and Easy Agile Programs have evolved, we’ve introduced powerful features designed to give users more control and flexibility. However, as new capabilities have been added, the interface has become more elaborate. For us, this presents an opportunity—an opportunity to take a step back, simplify the experience, and help users unlock more of what our products offer.
To address this, we brought people from across the business together to brainstorm how we could improve the experience in both products. Through these sessions, we identified a few core opportunities:
- Discoverability: How do we make it easier for users to find and use the powerful features built into our tools?
- Visibility: What’s the best way to surface the right information and features when users need them?
- Consistency: How do we create a more uniform experience within and across our products to make navigation intuitive?
Armed with these insights, we then set out to explore solutions tailored to each product’s unique challenges.
A more personalized experience with Easy Agile Programs
For Programs, we focused on three “how might we” questions to reframe our challenges into opportunities:
- How might we create more focus on the actions users are trying to complete?
- How might we make navigation more intuitive and easy?
- How might we help users with more context about where they are in the app at any given screen?
Out of the many solutions we explored, the one that got us the most excited was the idea of an Easy Agile Programs Home Screen—a personalized dashboard designed to guide users based on where they are in their planning cycle.
Conceptual sketch of the Easy Agile Programs home screen This home screen could adapt based on where users are in their journey, offering relevant guidance and actions.
- For new users, the home screen could provide clear onboarding steps and easy access to help, so they can get started quickly and confidently.
- For experienced users, it could offer insights and key actions related to their progress, so they can stay focused on what matters most. Users might even see data summarizing their accomplishments, which makes it easier to share successes with their teams.
Whether someone’s brand new to the product or deep into execution, the home screen could be a great way to guide and coach our users—helping them answer questions like, "What should I be doing next?" or "What extra value am I missing out on?".
A more focused interface for Easy Agile TeamRhythm
For TeamRhythym, our three key “how might we” questions were:
- How might we provide more focus within the User Story Map during sprint planning?
- How might we improve the discoverability of issues without epics?
- How might we enhance the layout to highlight key features and improve overall usability?
With these questions in mind, we explored a range of ideas to simplify sprint planning and make it easier for users to prep, plan, and review their work, whether they’re using Scrum or Kanban.
Three steps to simplify sprint planning on Easy Agile TeamRhythm Sprint planning can sometimes feel overwhelming when you have multiple sprints competing for attention. To help users focus, so we explored the idea of introducing a focused view during sprint planning.
- This would allow users to zoom in on a specific sprint and the backlog alone, while collapsing others.
- Each issue would have its own row in the detailed view, and users can drag and drop either an entire row or drag individual issues to quickly rank them based on priorities.
- The sprint view will also hide epics that don’t have linked issues in the current sprint, giving users a cleaner view of what’s relevant to their current work.
Conceptual UI of TeamRhythm User Story Map's focused view for sprint planning 
Conceptual UI of TeamRhythm User Story Map's detailed sprint view We also looked at ways to enhance the User Story Map interface to bring the most useful tools and features to the forefront. By improving how key functionality is presented, we’re helping teams quickly access what they need, when they need it, enabling them to stay productive without interruption.
.gif)
Conceptual UI of a more condensed top navigation for TeamRhythm User Story Map This way, we can create a smoother, more focused experience for teams using TeamRhythm, so they can focus on what’s in front of them without being distracted by everything else.
Your turn. What do you think?
At Easy Agile, we’re always thinking about what comes next.
These ideas aren’t on our official roadmap just yet, but they’re the kind of innovations we’re excited to explore.
If you think these changes would improve your experience with Easy Agile TeamRhythm and Easy Agile Programs, let us know! Your feedback helps us decide what to prioritize, so we can continue building tools that truly make a difference for your teams.
WorkflowHow to set your Agile teams up for success
Agile is about empowering teams to take ownership, feel truly engaged, and foster a culture of collaboration. More than ever, teams are required to deliver with greater adaptability, speed, and engagement. The future is more ambiguous and complex, and Agile teams must know how best to respond to these changing conditions.
Agile experts John Walpole, Dean MacNeil, and Nick Muldoon share their success formula behind the high-functioning Agile teams at Lyft, Valiantys, and Easy Agile. You will learn:
- How to create a compelling 'why' that the whole team can get behind
- How to empower your teams
- The qualities of high-performing Agile teams
-
Create a compelling 'why' that the whole team can get behind
I think Agile is not a silver bullet. We have people who look at Agile and say, "Oh, well, this is going to solve all of our woes." And it's not; it's certainly not a turnkey thing.
Nick Muldoon, Co-CEO at Easy Agile
Agile is not a silver bullet. It is not a methodology that will solve leaders, teams and individuals' problems. Agile is a continuous improvement journey of "adaptability in evolutionary theory; it's about responding to either a new environment or changes in your environment to again, not just survive but to thrive," said Dean.
Set your Agile teams up for success by teaching them to thrive by empowering them to lead change, make mistakes, build a solid foundation, and be open to learning, changing, and communicating the meaningful 'why' behind their work. You will see an explosion in Agile team success when you have a "cohesive team aligned to a common mission with a growth mindset."
Motivate your Agile teams by connecting their work with a meaningful 'why.' Schedule a meeting to ensure you constantly discuss their work's more profound purpose. Bring up a real-life customer example. John shared, "At Lyft, we share stories in a fortnightly meeting. We offer free accessible rides to those in wheelchairs or those who struggle to pay for a ride but need access to transportation to get to work or school.
"Bring your personas to life with these real-life examples, so it's front and center in your employee's minds," said John.
Empowering your teams
Culture eats strategy for breakfast
Peter Drucker
Your employees need to lead the change. "If you look at great leaders in recent Agile transformations, you might want to look at a company like Porsche," said Dean. Dean shares how Porsche has inspired Valiantys because "every employee at Porsche is leading the change. So they're all bought into it; they all have that sense of leadership to drive it.". Porsche's employees are leading the change because their leadership communicates the 'why' well. "Fun is number one when their CIO lists off the top three reasons 'why' everyone is so fired up about the Agile transformation. Because you can have fun on the job, your job is not supposed to be a grim duty. It's supposed to be something you look forward to."
"Empower your teams to make mistakes," said John.
Empower your Agile teams to fail and make mistakes through powerful questions. Leaders have to change their tone from "oh no, who do I fire?" to "what's the challenge? What can I do to help?". Express to your team that you're on a journey to learn as much as they are. In doing so, the leader humanizes themselves and becomes more vulnerable.
Leadership sets the tone. As a company scales, the responsibility to create the culture and the risk appetite falls more on leadership.
Qualities of high-performing, Agile teams
1. Create a solid foundation
Set your Agile team up for success with a stable team unit. Don't keep moving teams around; create long-term Agile teams to allow individuals to get to know each other and humanize one another. "I think stability is key to having the tacit knowledge keeping together and this open mindset where they're willing to learn; I love that," said Nick.
2. Open to learning and adapting
For Agile teams to continuously improve, they must constantly be learning and adapting. "You can't get that learning and adaptation if you keep just stirring the pot. Because you're going to keep scattering that knowledge, you want to take hold, and then, of course, you want to spread the knowledge to the organization then," said Dean.
3. Share feedback and do the retrospective
Ensure your Agile teams are demonstrating working product on a regular occurrence. If you're practicing Scrum, make sure you are doing the weekly sprint review. This allows the team to receive feedback from stakeholders and keep iterating and moving forward, ensuring they stay in movement. "Do your retrospective," said Dean." We're looking at what we delivered, and now we're going to look at how we delivered it." It is imperative that Scrum teams gather at the end of each sprint to discuss what went well, what didn’t go so well, and what can be improved on for next time. Otherwise, you invite complacency and stagnation into your Scrum process — the antithesis of Agile.
Using Easy Agile to set your Agile teams up for success
Easy Agile TeamRhythm supports your team's Agile practices in Jira. The user story map format in TeamRhythm transforms your flat product maps into a dynamic and flexible visual representation of work. Watch the highlights tour to see how Easy Agile TeamRhythm makes sprint planning, managing your backlog, and team retrospectives easier. Visit Atlassian Marketplace to start your free, 30-day trial today.
Agile Best PracticeSix Tips for Improving Team Collaboration
The 17th State of Agile Report shared that 93% of executives thought that their teams could do the same amount of work in half the time, if their teams collaborated better.
That's quite a statistic. We’ll leave it up to you to decide whether this reflects a lack of efficiency due to poor collaboration, or a disconnect between leadership expectations and the realities faced by development teams.
What we do know is that improving team collaboration has benefits and that improved collaboration is a key benefit of effective agile practices.
So if you think your team could work more effectively, here are six tips for improving team collaboration that we think will make your working life better, and help you deliver for your customers.
1. Agile Teams Are Cross-Functional
Cross-functional teams are the backbone of agile collaboration. It's Agile 101:
The best architectures, requirements, and designs emerge from self-organizing teams.
Manifesto for Agile Software Development
Ideally, your agile team should be able to deliver work independently. The skills and expertise of your team should allow you to handle diverse tasks without creating dependencies on other teams. You can take ownership of the software you're delivering.
The benefit of organizing into cross-functional teams is a greater shared understanding of your project, where you can each see how the pieces fit together. This type of collaboration supports the efficient flow of work and ensures that knowledge and skills are consistently shared.
2. Take an Iterative Approach
Or to put it another way, make it easier to fail fast, so your team can learn why, and correct your course. By breaking down large projects into manageable increments, your team can focus on delivering small, functional parts of working software at regular intervals. This approach goes hand-in-hand with continual feedback from users, ensuring that issues are uncovered quickly and dealt with just as fast. This shared team focus on user feedback, and the shared purpose and collaboration that comes with it, is a key benefit of agile development.
3. Maintain Regular and Transparent Communication
Daily stand-ups, sprint reviews, and planning meetings are all designed to foster regular and clear communication. You and your team should see these meetings as an opportunity to share ideas, discuss progress and blockers, and collaborate. If your daily stand-up is nothing more than a shopping list of tasks, then you're doing it wrong.
If your daily stand-up is nothing more than a shopping list of tasks, then you're doing it wrong.
Someone who has wasted too much time in shopping-list meetings.
Beyond team meetings, clear communication is important anywhere the details of your work are shared. Agile tools like Easy Agile TeamRhythm provide a central platform for prioritizing work and tracking progress. With a central source of truth that everyone can access to understand goals, priorities, and team commitment, collaboration can be more effective, keeping the team aligned and focused.
4. Conduct Team Retrospectives
Hot take: regular retrospectives are the most important agile practice your team can adopt.
Team retrospectives provide a structured opportunity to reflect on your work and discuss how it can be done better next time. This is team-led improvement because you and your team are in the driver's seat. Encouraging honest and open discussions during retrospectives helps build trust among team members and fosters a collaborative mindset. By continuing to work on processes and behaviors, you and your team can improve your performance over time and make your working life better.
5. Use Collaboration Tools
The right tools can make a big difference in team collaboration. The best tools provide a reliable source of truth that the whole team can access, in a place where the whole team will access it. It's a simple concept; a shared understanding of the work is supported by shared and willing access to the same information.
Choose a tool that makes it easy for you and your team to access information and keep it updated. If you're already working in Jira, an integration like Easy Agile TeamRhythm provides a better view of your work in a story map format, with goals, objectives, and team commitment all made clear. Team retrospective boards are attached to each sprint (or spun up as required for Kanban teams) so you have your team-led ideas for improvement tightly connected to the work in Jira.
No matter which tool you choose, make sure it will facilitate better alignment, streamline your workflows, and provide a clear picture of roadblocks and progress. By using collaboration tools effectively, your team stays organized, focused, and connected, no matter where each member is located.
6. Build a Positive Team Culture
It may sound obvious, but a positive team culture is essential for effective collaboration. Creating an environment where team members feel valued, respected, and motivated, encourages the psychological safety they need to share their great ideas, learn from missteps, and collaborate more effectively with their colleagues.
High-performing teams recognize the achievements of others, share constructive feedback, and support practices that lead to a healthy work-life balance. Make it regular, and keep it authentic. A positive culture not only improves team dynamics but also boosts overall productivity and job satisfaction.
Successful Team Collaboration
Effective collaboration can be the difference between your team achieving their goals, or falling short. By embracing agile practices like the regular communication that comes from agile planning meetings, to the learnings that come from taking an interactive approach to development, and creating time for team-led improvement with retrospectives, you can seriously boost your team dynamics.
Easy Agile TeamRhythm Supports Team Collaboration
Easy Agile TeamRhythm is designed to make your agile practices more accessible and effective, helping your team plan, prioritize, and deliver work with better alignment and clarity.
Built around a story map for visualizing work and retrospective boards that encourage team-led improvement, TeamRhythm facilitates sprint and release planning, dependency management, backlog management, user story mapping, and retrospectives.
Tight integration with Jira makes Easy Agile TeamRhythm a reliable source of truth, no matter where you and your team members are located.
Watch a demo, learn about pricing, and try for yourself in our sandbox. Visit the Easy Agile TeamRhythm Features and Pricing page for more.
Easy Agile TeamRhythm