Easy Agile Team

Any organizational change is complex, no matter how big or small. Tracking workflows can also be a huge headache without software. However, whether you want to start a new Jira workflow, create a simple workflow, or undertake something more complex, there are tools to help.

Here, we’ll cover a few Jira workflow examples so you can decide which option best matches your team’s needs. You can also use these examples as mini tutorials to guide you through simple task management, complex projects, or process management.

Once you know how Jira software can help you streamline your business processes, you’ll probably wonder how you ever lived without it.

What is a Jira workflow?

A Jira workflow is a software plugin that helps you manage change in the organization. Whether this change is on a small scale, medium scale, or a massive project, these Jira workflow examples can help you navigate the task.

Here’s why you need Jira workflow to manage business processes:

• Task management means dealing with tasks on a small scale. A Jira workflow can help you deal with these tasks rapidly and effectively.
• Managing larger projects requires a more complex workflow. Here, you’ll need to use an “In Progress” status to better help track tasks. You can also use statuses such as “Awaiting Approval”, “Review in Progress,” and “Review Complete” for complex workflows.
• The Jira workflow includes statuses and resolutions for multiple tasks. This workflow level demonstrates just how multifaceted task management can get on a massive scale. The process management workflow is suitable for managing business or development processes.

You can use standard workflow, new workflow, or custom workflow automation depending on the change process you want to undertake. We’ll cover these three categories in just a bit.

Vital Jira workflow elements

Before diving into the Jira workflow examples, we need to cover all the elements in the workflow.

Wait until the team is familiar with working on this system to attempt any customization. Otherwise, agile team members may accidentally bypass the transfer or completion steps, resulting in an incomplete record of the workflow.

You’ll deal with several basic elements in the Jira workflow. These elements include:

• Statuses
• Transitions
• Assignees
• Resolutions
• Conditions
• Validators
• Post functions
• Triggers
• Workflow properties
• Workflow schemes

These statuses reflect who is responsible for tasks, task location, what needs to happen, and complete work.

1. Workflow statuses

Placing the task issue “Under Review” may be the first status in a process of several. Each task then requires several actions instead of one.

Only one status applies to a Jira issue at a time. Either the task will be “In Progress” or “Complete.” Once the Jira administrator deems that all requirements for final approval have been met, the task will be marked as “Complete.”

Multiple tasks can appear under any one status throughout their lifecycle.

2. Workflow transitions

Jira workflow software uses transitions to connect two statuses. Transitions receive names, like “Submit for Review,” which connects the statuses “In Progress” and “Under Review.”

Note that only the Jira administrator may move tasks between statuses. You can customize the system to notify various team members when a change is made.

Transitions are part of the Jira workflow elements that move tasks towards a resolution to complete a product, process, or project lifecycle.

3. Assignees

Assignees are team members who are responsible for completing issues or work tasks. This responsibility frequently changes as team members transfer issues between statuses. Once an assignee completes an issue, the Jira administrator removes their name from the task.

4. Issue resolutions in the Jira workflow

The Jira administrator or responsible assignee with the required permission will then resolve the task. Resolved tasks are transferred to “Complete,” “Fixed,” or “Won’t Fix,” depending on the status required.

If you need to re-open any resolved status issues, you must first mark the resolution as “Cleared.” Failing to clear the issue will mean that it will appear in separate places such as “In Progress” and under “Complete,” which will be confusing.

Resolution is not a status in the workflow of a Jira project, but rather the removal of the task issue from the system. Don’t confuse the two.

5. Conditions

Jira administrators set certain conditions on the Jira board to control who can create a transition.

6. Validators

Validators can allow or disallow transitions, depending on certain restrictions. Restrictions include the assignee providing proof that the task issue can move through the system, for example.

7. Post functions

When you post functions, you’re making further changes to issues. In other words, you can remove a resolution after you reopen an issue. You can also post functions to make changes to transitions.

8. Triggers

Triggers let you automatically activate transitions once specific events occur. One example of a trigger is when you move an agile issue from the “In Progress” section to “Under Review” after completing the code for a software development project. The team will either store this code in the Jira cloud, BitBucket, or another cloud-based system where relevant stakeholders have access to the team's work.

9. Workflow properties

The Jira administrator can set specific properties to manage transitions. An example of this would be displaying resolutions for team members that link to a certain issue type.

10. Workflow schemes

Workflow schemes support the Jira workflow by showing the relevant links between the subtasks, issue types, and new statuses.

Let’s look more closely at the task management process in Jira workflow examples.

Jira workflow examples

Again, you can use Jira software to track and record minimal or multiple tasks. Using software to keep a record of change makes teamwork easier, as many team members can see the same history of changes. Jira workflow examples also give you a good indication of what this software is capable of and to use it to your advantage in managing diverse business processes.

(Tip: Easy Agile Roadmaps for Jira is an easy way to visualize your workflow.)

1. Standard workflow management

The standard workflow allows you to create a workflow scheme to trace, move, and complete simple tasks through the system. They also help to identify bottlenecks in the system which are holding back progress.

An example of using this workflow would be writing articles for an internal communication campaign. The articles are the issues or new tasks in the “To Do” list. As you begin writing each article, you move it to the “In Progress” section. Similarly, as you complete each article, you transfer it to the “Done” category.

2. Jira workflow opportunity backlog

The opportunity backlog consists of product problems you need to look at before you place them in the workflow.

Jira users can follow this step-by-step workflow process to manage an opportunity backlog:

• As stakeholders give feedback, the project lead becomes responsible for managing these issues.
• The project lead bumps the issues up to the portfolio management team. The team will review the items and decide whether to include these in the backlog.
• These opportunities are evaluated in relation to the development costs and the value the use cases will deliver.
• Alternatively, the team leader or portfolio manager can place these opportunities on Confluence for further discussion and evaluation.
• When the team has all the necessary details about the opportunity, the Scrum Master or validator can transfer it to the “To Be Decided” status.
• Once a decision is made, you can transfer the backlog opportunity to the development plan or place it “On Hold.”
• The Research and Development team uses the “To Be Delivered” queue to show which opportunities they want to include in future releases. The R&D team will concentrate on the highest-ranking opportunities for further development.
• Once the stakeholders decide to go ahead with specific backlog opportunities, these become epics or stories for the release projects.
• The backlog opportunity then transfers to “Under Development.” The team leader will then link the opportunity with the relevant user stories.
• When the team works are complete, the story or epic is then closed after delivering the product.

Easy Agile TeamRhythm for Jira makes it easy to add backlog items to your Story Map.

3. New workflow

When you create a new workflow, you can customize it to your team’s needs. You can either copy and paste an existing workflow or start from scratch.

If you copy and paste a workflow, note that you will also be copying permissions, which may need changes to avoid permission errors.

Unlike managing your own standard workflow, which is simple, you may need approval from a Scrum master or Kanban validator. You can then include these permissions in the new workflow, avoiding the problem of transferring old permissions by mistake.

You can then customize the Jira workflow to include a status that says, “Awaiting Approval”, “Final Product Review”, or “Product Approved”, for example.

Likewise, a status like “Review in Progress” may help check the quality of new tasks. Lastly, a “Review Complete” status will show that the work issues have completed their cycle through the workflow. You can also use transition screens as you move issues through their lifecycle.

4. Customized Jira workflow

If you have multiple, diverse teams working on a project, you’ll probably want to customize your workflow to align with their requirements. Diverse teams from software development to marketing and HR use Jira software to manage their custom workflows.

Similarly, you can use customizations like those in the opportunity backlog example above to include statuses that match your workflow requirements. For example, an HR recruitment officer can use different statuses to indicate the position of candidates for job positions in a recruitment drive for a specific position. An initial status may be “CVs Received”, followed by “Possible Candidates For Interview”, and so on until the last statuses, which could reflect “Candidates To Interview”, and “Candidate Appointed.”

When customizing your workflow, concentrate on the big picture when dealing with add-ons as they may complicate the process.

Get started with automated Jira workflows

Map your workflow for basic projects, or customize them with additional Jira plugins. If you have any difficulty with customizing a workflow, you can always contact the Jira service desk for help.

If you want to start with automation of your workflow, Easy Agile offers two free workflows in the Atlassian Marketplace for Scrum and Kanban.

Add to your new workflow automation with other valuable resources such as Easy Agile's TeamRhythm for Jira or Easy Agile Roadmaps for Jira.

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.

Or why you should give meaningful names to example variables

I bent over my desk in frustration, suppressing the urge to scream so as not to upset the rhythmic clack-clack of my coworkers. I’d been frustrated all morning by a particularly nasty React infinite re-rendering issue that I just couldn’t get working. The urge to scream came when, my own toolbox exhausted, I turned to Google.

You see, it looked like someone else had come across the same issue and had decided to record a solution for prosperity (and internet points). I eagerly scanned the page for the sample code that would save my morning. Finding it, my eyes were drawn to the dreaded fooBarBaz and I knew my morning was about to get a whole lot worse before it got better.

I actually love the history of programming and the little easter eggs fellow developers have passed down (my personal favourite - I am a teapot). These help to make this job interfacing with computers much more fun and human. I can appreciate that the practice of using fooBarBaz in naming example functions and variables has a long and storied tradition dating back at least to the Tech Model Railroad Club at MIT circa 1960. I acknowledge that the use of fooBarBaz is primarily not to introduce any distractions from the point which is being demonstrated. I also think that we should pretty much stop using them.

I am always awed by the amount of information my fellow developers have left out there for me on the internet. So many people in this field seem to have an innate need to help others, leading them to put in countless hours to fill Stack Overflow and blogs with useful information. I can only imagine that the people putting in their time and effort to this end are hoping that their efforts will help as many people as possible. fooBarBaz gets in the way of that.

Let me take off my developer hat for a second and put on my recently discarded, slightly misshapen and battered psychologist one. Interweaving complex facts into stories is a time tested technique which facilitates learning. Here in Australia, the technique has been used for tens of thousands of years by the Aboriginal and Torres Strait Islander peoples to help them to remember important and complex information such as the locations of waterholes across vast tracts of inhospitable desert. Our brains are networks of interconnected neurons so we are more likely to hold on to what we have learned when we are able to integrate new information into our current knowledge base. The modern term for this is associative learning.

Additionally, as I’m sure you’ll remember from school, keeping learning interesting has been demonstrated to be a powerful motivator which energises learning.

When we take all this time and effort to communicate with our fellow developers we can and should harness the advantage of associative learning and intrinsic motivation to make sure that the information we are putting out there is as useful as possible to as many people as possible. To this end I believe that we should give as much thought to meaningful naming when creating example code as we do in our own codebases.

Marijn Haverbeke’s Eloquent Javascript regularly comes at the top of lists of books you should read when learning Javascript (JS). It is no coincidence that he is also a master at using meaningful names to help people to better understand coding principles. When teaching new programmers about string comparison in JS he uses the following example:

Marijn piggybacks off our existing knowledge about Springfield’s favourite cartoon characters to give extra meaning and interest to this example. We know that Itchy and Scratchy are a mouse and cat respectively and so most definitely not the same.

Consider the same example but rendered with the dreaded Foo/Bar instead:

To seasoned developers, this might be easy enough to parse: you’ve read hundreds of examples like this and so have learned the association between Foo and Bar and internalised it. But this creates a barrier for learning for new developers who have not yet internalised this rule and instead increases the mental load for them to understand the concept. It also misses out on creating that little spark of interest or joy to help pique the reader's interest and so increase their motivation to understand the underlying concept.

I am not saying there is absolutely no place for fooBarBaz (although I think their utility is limited). The best way to use these terms is to emphasise that anything could be put in a certain place. An example of this is when we’re talking about arguments and parameters in JS functions. You see, there is no type checking in vanilla JS and so if we have a function like the following that takes a parameter and simply logs its value to the console, it doesn’t matter what type of argument we pass in:

I believe that these terms have the most utility in this case as their purpose is to emphasise that their type doesn’t matter. I would also add the caveat to this that using these terms in this way is only suitable when you are producing content for experienced developers who are going to have built a working understanding of these terms.

Even if this is aimed at experienced developers, I still believe that more meaningful names would be better in this example:

Another example where more meaningful variable names would be useful is in relation to metasyntactic variables. These variables are commonly found in source code and are intended to be modified or substituted before real-world usage. Whilst these variables are only placeholders, I believe that it is also better to use a variable name which offers more context to your developer comrade to assist them when they are reading and implementing the code in future.

We work in a wonderful profession with a rich history, where many people are willing to donate their time to helping to educate and mentor their fellow programmers. Using meaningful variable names in place of fooBarBaz is one way that we can ensure that this effort is worthwhile and helps as many people as possible. It lowers the barriers to entry for the profession, helping to create a more diverse and welcoming programming community.

So ditch the fooBarBaz (but not the Teapot) and go forth and spark joy!

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.)

When you take on the development manager role, it can feel like you're doing a little bit of everything. Your job is no longer to focus purely on code — and you're not leading your average team. In your day-to-day, you're representing, strategizing for, and even developing with your engineering team.

With all the tasks filling your to-do list, it can be easy to forget: Getting quality results depends on the quality of your leadership. Work isn't just about projects — and you're not a project manager. Great development managers are equally as good at working with people, building culture, and supporting their team members as they are at boosting efficiency and working on all things technical.

To get the most out of your team, here are five tips that every development manager needs to know to get the best from their team.

1. Offer guidance, not micromanagement

Have you ever gotten anything done with someone breathing down your neck? It's not comfortable, and it creates a culture of distrust. In an agile environment, this goes against the principle of having a self-organizing team — one in which each team member takes charge of their own responsibilities and timelines.

A great development manager knows that each team member contributes their own unique work experience and knowledge to a team. Your job description isn't to do other people's jobs for them or boss them around. Rather, it's to ensure the engineering team produces quality products in a timely manner.

You'll get more out of your team by inspiring them instead of telling them what to do. Instead of dictating deadlines, guide your team in the right direction by illustrating the importance of your priority projects.

How will each person's contribution impact the broader company? How will finishing one task early unlock new opportunities for the team? Nudge your employees toward better decisions that they make themselves to build a team that's enthusiastic about their work.

2. Plan with the big picture in mind

While members of your product development team may be diving into the details — writing code, checking off smaller tasks — your job as a development manager is to think big. Development managers play a key role in the agile planning process by figuring out which projects their team should prioritize and how to best complete them.

Instead of just thinking solely about what's best for your team, you need to consider which projects and tasks best align with your company's broader business goals. This will help you build a development team that creates stand-out results for the entire company.

At the same time, you should be fully aware of what's possible for your team to take on. Will committing to one new product up one person's workload far more than others? Does your team have the capacity for more work at all? No matter how many years of experience your team has, they — as individuals and as a whole — need room to breathe so they don't burn out.

3. Keep your technical skills up-to-date

"Manager" may be the brag-worthy highlight of your job title, but that doesn't mean you can let your technical skills go. Odds are, coding will still make up a chunk of your day-to-day — or at least your week-to-week. Even when you're not directly assigned to a software development task, you'll still need to guide your team members through their individual tasks.

To give your team the support they need, you need to be able to speak their coding language. This will help you lead code reviews, take part in technical conversations, anticipate (and prevent) roadblocks, and ensure you're implementing the most efficient technologies. Regularly taking courses and joining a coding community are two simple ways to be a problem-solving champion for your engineering team.

Your technical expertise will help your team stick to your product roadmaps and meet key milestones.

4. Bolster your communication skills

When you take on the development manager job, you become a liaison between your engineering team and other parts of your organization. For example, you might communicate the needs of your developers to senior management or pass on requests from sales managers to your team.

People without a technical background might think you're talking about music if you start talking about C#. Engineers without business management experience may roll their eyes if you start talking about five-year plans instead of an upcoming product launch. Even though coworkers share the same company culture, they don't necessarily "get" each other all the time.

Developer managers are translators who represent their team and deliver messages back to them as needed.

Since you're constantly working with people from different backgrounds, you need to strengthen your interpersonal skills. Get to know how you can best communicate with different people. Which teams prefer email over texting? Who's the go-to contact person for each team? Does anyone listen better when they're not hungry? 🙋

The stronger your communication skills are, the more likely your team will get the resources they need, and the better they'll connect their priorities to your company's.

5. Be available to support your team members

Development manager may be a part-time managerial and part-time technical role, but in this position, you need to be a full-time leader for your team. When you want to consistently improve your team's output, you need to put your top-notch leadership skills into practice day in and day out.

As a development manager, you need to act as a coach of sorts for your team members. Schedule out recurring one-on-ones with your team members, during which you can chat about career goals and pain points on top of current projects. When you have a new hire, chat with them about their desired career path during the onboarding stage.

Based on what you learn, you can brainstorm ways to support their professional development. You don't have to pay for their bachelor's degree to help them succeed. Connect them to mentors, send them to conferences, recommend them for speaking opportunities — your options are endless (and simpler than you may think).

Offering support on both current projects and in long-term career goals is your chance to invest in your employees. It'll help them become better workers — and they'll feel valued, too. Did you know nearly half of employees leave their jobs to gain new skills? Keeping your development team at its best in the long run requires you to help each employee grow.

Lead your team as an effective development manager

Leading your development team to success takes an unbeatable blend of people skills, technical skills, and leadership skills. In your multi-faceted role, your ability to communicate and align your team with the rest of your organization is invaluable.

With Easy Agile Roadmaps for Jira, you can make team alignment simpler by dragging and dropping any Jira issue on a visual timeline. Watch our demo today to see how this tool can help your engineering team shine!

Being agile vs doing agile – what’s the difference?

Organizations around the world have recognized the need to respond rapidly to meet the challenges of constant change. As a result, they’re racing to adopt agile ways of working, with the pandemic accelerating agile adoption.

Those who get it right can make a powerful impact on their bottom line and their competitive edge. But for others, the benefits may yet to be seen.

This is where ‘doing agile’ versus ‘being agile’ can make all the difference. Because to truly reap the benefits of agile methodology, organizations need to shift from doing to being.

This article will explain the difference between being agile vs doing agile. Plus, we’ll take you through some of the common challenges many organizations face in their agile journey.

Key points

• To realize the full potential of agile ways of working, teams must cultivate an agile mindset as well as adopt agile processes.
• Moving from ‘doing agile’ to ‘being agile’ takes time, coaching, and a new approach to management.
• Done right, being agile can amplify customer satisfaction, employee engagement, growth, and profitability.

Why agile, and why now?

Agile had already been rising in popularity for over 20 years, but once the pandemic hit, this growth accelerated.

Across every industry, being able to deliver digital experiences is now crucial. Organizations now need to act and think like software companies, with a laser focus on the customer’s online experience. Together with an active approach to finding customers, you need to deliver real value to stand out from competitors.

For organizations looking to survive - and thrive - in this environment, many are turning to agile frameworks to rapidly add customer value and drive business results. Being agile allows teams to:

• Make the complex simple – by working within a clear, structured framework, chaos turns to order.
• Maintain a clear overview – agile teams have a shared understanding of their progress towards their goals.
• Replicate success – if a team finds an effective way to deliver results, they can repurpose and share solutions across the organization.
• Create an aligned, purposeful culture – when hundreds of people across one organization form dozens of agile teams, they build a stable backbone, walking the same path towards the same goal.

"Agile organizations, viewed as living systems, have evolved to thrive in an unpredictable, rapidly changing environment. These organizations are both stable and dynamic. They focus on customers, fluidly adapt to environmental changes, and are open, inclusive, and nonhierarchical; they evolve continually and embrace uncertainty and ambiguity. Such organizations, we believe, are far better equiped than traditional ones for future."

- McKinsey & Company

What does it mean to be agile?

Many organizations incorporate a few agile processes to manage projects. But that doesn’t mean teams have fully understood and embraced the agile methodology. It could be that they’re ‘doing agile’ rather than actually ‘being agile’.

Here’s the difference between the two:

Doing agile

‘Doing agile’ is the misconception that if you do agile things your company will become agile and responsive to change. Organizations that have fallen into this trap may go through the motions of some agile processes, such as daily stand-ups, sprints, and retrospectives. Teams are structured to be small, cross-functional, and collaborative. But by stopping there, those teams don’t become truly agile and they may struggle to see results.

While agile ceremonies, tools, and structures are critical in implementation, they are only part of what makes an organization agile.

Being agile

‘Being agile’ means you incorporate the above activities but go beyond the processes. This means applying an agile mindset and agile values to all areas of the organization. Teams will need training to master the agile mindset and push through any challenges along the way. It takes more time and effort than simply doing agile, but it’s critical if you want to reap the benefits.

What’s an agile mindset?

Embracing an agile mindset means understanding and living its four core values. To be agile, you need to:

1. Respect people - Recognize that people are critical to the success of your organization. Ensure people share common goals, feel safe and empowered to share ideas, and adopt a ‘we’ versus ‘I’ mentality.
2. Optimize flow - Build in quality at each increment so you can identify issues and course-correct early. This helps maximize value and minimize waste while creating a consistent, sustainable flow of work.
3. Encourage innovation - Foster experimentation with collaboration, constructive feedback, and autonomy. Schedule time and space for creativity and ideas to flow.
4. Relentlessly improve - Keep in mind that there is no endpoint with the agile mindset. It’s about continuous improvement, so you need to continually reflect and improve future processes as part of an ongoing practice.

To take these values and make them the foundation of working across your organization, you need to combine agile processes with an agile mindset. Without the agile mindset, you’re not ‘being agile’, and your processes won’t deliver your organization’s full potential.

"The agile mindset is a thought process that involves undersatdning, collaborating, learning, and staying flexible to achieve high-performing results. By combining the agile mindset with processes and tools, team can adapt to change and deliver incremental value to their customers."

- Atlassian

Agile processes and tools aren’t enough

Agile processes, including the ceremonies, tools, and apps, are there to support the mindset of the team. But without getting the mindset right across your organization, you won’t be truly agile.

Fostering the agile mindset gives an organization the ability to rapidly move in any given direction at any given time to deliver the best value to customers. Teams who’ve mastered agile are usually:

• Autonomous and empowered to make decisions around the product and customer experience.
• Able to adapt to change quickly.
• Always willing to learn something new.

Engaged with a shared purpose and collaborative culture.

"It's about being able to pivot to change. Whether that's in terms of people, or resources or budget - whatever that looks like for an organization. If you're able to quickly shift from one area of focus to another before your competitor does, then you have a competitive advantage in the market."

- Sean Blake, Head of Marketing, Easy Agile

Common challenges to look out for as you move from doing agile to being agile

The sooner you can act and move from doing agile towards being agile, the sooner your customers, employees, and your bottom line will benefit.

Here are a few common challenges and tips to overcome them.

• People might hold onto old habits
  People find change hard, especially when habits are ingrained. You might find some people dig their heels in, clinging to the old way of doing things. It’s important to remember it can take time, and people will need support to learn new ways of working. Be sure to bring in plenty of opportunities for feedback and discussion so you can reiterate as a team to find a process that works for your organization.
• It’s not just the team who needs to be coached
  Being agile is a mindset for the entire organization, including managers and executives. If your leaders don’t understand and support agile, it will be hard to get traction and shift old processes and hierarchies. Scrum Masters and Agile Coaches need to spend time coaching leaders to develop new agile mindsets and capabilities.
• For many organizations, being agile requires a new style of management
  The traditional command-and-control management style may have worked in the industrial age. But now it’s a mismatch for the way organizations and people need to work today, and it doesn’t support the agile mindset. To be agile, teams need the trust, autonomy, and ability to take an idea through to execution without any roadblocks. Senior executives must get behind this multifaceted cultural-transformation effort for this to happen.

Are you ready to be agile?

Moving beyond agile processes to scale an agile mindset across an organization isn’t something you can tackle overnight. It takes time, effort, training, and leadership support to internalize agile values and move beyond the command mindset of the past.

You may face challenges along the way, you’ll discover there’s always more to learn, and you must be agile in your adoption of agile.

But the prize for true agility is significant, including increasing customer satisfaction, boosting employee engagement, and improving productivity - making it well worth the investment.

Agility helps modern organizations thrive through change in an uncertain and unpredictable world. For most of us, it’s no longer a desirable way of working - it’s essential.

At Easy Agile, we embrace agile principles (of course), and we strive to help software development teams put agile methodologies into practice. However, with so much to get done each day, it's easy to lose sight of the core principles of the agile manifesto.

You're probably thinking that you read the agile principles before and now put them into practice...all day, every day. Why do we need to revisit them?

You don't need to memorize the principles. They're much more of a guiding light than a rote process. But lining up the agile principles against your everyday agile practices provides reinforcement that you're putting them into action. This also helps you identify areas for improvement. 🙌

The continued relevance of the agile manifesto's principles

The agile manifesto focuses on:

• Continuous improvement by responding to feedback and change
• Allowing software developers and cross-functional teams to organize in a way that embraces collaboration and interaction
• Involving customers in the development process and responding to their feedback

The manifesto outlines 12 agile principles which are the bread and butter of agile software development. We'd like to provide practical context to these agile principles, so we're going to organize them into three categories — building working software by being organized, helping teams collaborate, and tactics for keeping customers happy.

Getting organized so you can build working software

The first few agile principles we'll review revolve around the concept of working software — a product your customers can use as early in the software development process as possible. You’ll adapt it as you get feedback about what’s working well and what could be improved. This is in contrast to a waterfall methodology to development, which is a more linear approach that typically does not allow for iterative updates.

Creating working software you can continuously update is one goal. But, that's easier said than done without the help of purpose-built tools like Jira, whose goal is to help agile teams manage their chosen agile framework, whether it be Kanban or Scrum. (You can read our guide on the differences between Kanban and Scrum...or how to use them together. 💪)

Now, let’s look at which of the 12 agile principles fall into this category — #3, #7, and #8 — and how Jira helps implement a framework that adheres to them.

Agile principle #3

"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."

Atlassian (the makers of Jira) sums up the embodiment of this principle perfectly in its definition of a sprint: "A sprint is a short, time-boxed period when a Scrum team works to complete a set amount of work."

While agile sprints run over a short period of time, running them smoothly takes a lot of work for product owners and software developers. Luckily, Jira provides ways to streamline that work — check out our guide on automating parts of your sprint.

Agile principle #7

"Working software is the primary measure of progress."

Sprints can help you ensure that your team delivers working software incrementally. If planned well enough, a sprint can serve as a stopping point for the release of your next batch of features and functionality to your end-users.

Agile principle #8

"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

Agile frameworks like Scrum can help measure if a team is maintaining a consistent pace. Within sprints, effort can be measured in different ways like agile story points. As sprints are completed, Jira automatically creates a visual report of how many story points a team is completing from sprint to sprint in its velocity chart.

Time for team collaboration

You're an agile team delivering working software and using a super-tool like Jira to plan your work and track your progress. But you need a human touch to truly follow agile values. Please welcome agile principles #4, #6, #11, #5, and #12 to the stage.

Agile principle #4

"Business people and developers must work together daily throughout the project."

Daily stand up meetings are a manifestation of this principle. In this meeting, each team member addressed three topics: (1) what they worked on yesterday; (2) what they're working on today; and (3) what is preventing them from making progress today.

Agile principle #6

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

Whether it's in an in-person or remote meeting, conveying information is tricky — but (phew) we've already addressed that with practices like daily sprints and velocity charts to exchange information across team members and to visually review team progress. And you'll soon see other ways that agile software development teams organize and communicate with each other.

Agile principle #11

"The best architectures, requirements, and designs emerge from self-organizing teams."

Well, first, what exactly is a self-organizing team? It does not need outside direction or micromanagement to figure out what to work on and how that work gets defined and prioritized. These teams figure out how to plan their work, iterate to deliver that work, and then collaborate on how to continually improve. The agile ceremonies of Scrum — stand up, sprint planning, sprint review, and retrospective — are a working example of this.

Agile principle #5

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Ok, so we went out of order on this principle — but for good reason. Following principle #11 makes sense because good self-organized teams are inherently motivated. They work together to figure out how to get the job done and to help each other when someone is stuck. That said, it's important to have defined roles in an agile team, like a Scrum master who can motivate and give feedback to team members.

Agile principle #12

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

This principle perfectly describes a retrospective — a team meeting to reflect on your most recent sprint or iteration of work and to discuss how to improve for the next one. By answering these questions: (1) What went well?; (2) What could have gone better?; and (3) What can we adjust to improve for next time? your team is collaborating and interacting in an effort to become more effective.

Achieving customer satisfaction

Last, but certainly not least, in the agile principles are customer needs. Who is your customer? What are their needs? How do you respond to their feedback to make sure you provide a working product that they love? Enter principles #1, #2, #9, and #10.

Agile principle #1

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

It turns out that to satisfy your customer, you need to understand who your customer is. 😉 This takes work. A proven methodology for figuring out who your customers are is to create customer personas. These are fictionalized profiles of your customers that document things like their behavioral patterns, their shared pain points, and what their general demographic information looks like.

Agile principle #2

"Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage."

Requirements can't be effectively changed unless they are defined and made visible to stakeholders for feedback. Even if that feedback causes change late in a development cycle, that's ok! (You'll probably also receive change-inducing feedback on the working software you've already delivered. 😎) Tools like a product roadmap or a user story map that provide visual views of your product backlog help give your customers and stakeholders a platform to have the ability to provide feedback.

Agile principle #9

"Continuous attention to technical excellence and good design enhances agility."

One word: retrospective.

​Ok, two more words: sprint review.

In the context of principle #9, the retrospective and sprint review are two agile ceremonies to use to continually adjust your software's quality and design to best meet your customers’ needs.

Agile principle #10

"Simplicity–the art of maximizing the amount of work not done–is essential."

Imagine you had views of your customer profiles (personas), a visual mapping of their journey through your product (user story map), and a prioritized view of your plan to deliver your product (roadmap). What a time to be alive! If you're doing all three, chances are your team has pretty great insights into whether or not you're getting the right work done. 💪

Putting the 12 agile principles into action

Now you understand how the agile principles have been formed into agile frameworks and how tools like Jira can help agile teams run with those frameworks. We've also mentioned three effective ways to put these principles into action, and our products make it easy to do.

• Easy Agile TeamRhythm supports agile teams from planning through to review with features that support user story mapping, backlog refinement, sprint and version planning, and team retrospectives.
• Easy Agile Personas for Jira provides teams with a customer-centric approach to backlog refinement.
• Easy Agile Roadmaps for Jira gives visual insights for teams and stakeholders around the vision and plan for a product.
• Easy Agile Programs is a complete PI Planning solution that makes scaled cross-team planning and execution easy.

Check out all of our agile solutions in Atlassian's marketplace!

Agile software development uses iteration to improve agile practices. More than that, development teams use agile principles to enhance self-organization. Improving the Scrum framework leads to improvements in rapid deliverables and product outcomes through iteration.

But taking on agile when you're not familiar with this approach can be challenging. Team members need a bridging tool. A bridging tool like virtual team building activities supports new learning activities. New learning promotes new ways of thinking that promote continuous improvement. Enter, Agile games!

Learn how these games can support team-building and promote problem-solving for better software development processes, and which agile games to look for.

What are agile games?

Agile games are online games that entire teams can play. These games were created for team-building activities. They help nurture effective teams by getting everyone to work towards a common goal. When agile teams put their heads together, communicate effectively, and take on new learning, everyone wins — including product owners.

Team building games drive innovation by encouraging a new perspective through team-building exercises. Agile games are fun, but they are also practical. This practical approach enables team members to adopt new behaviors.

When they play agile games, teams implement better working methodologies in software development. Agile games support team building through new learning activities and iteration.

Ultimately, agile games augment the good communication and self-organization of DevOps teams. The outcome of playing agile games is that your team members more rapidly assimilate agile software.

As agile teams improve their problem-solving skills, they reap multiple benefits that might have fallen along the wayside if they didn't use an agile methodology or these agile games.

Types of agile games

There are multiple agile games that you can use to familiarize new teams with agile software. Tastycupcakes developed many of these simple games as ice breakers, which encourage introverts to participate more fully in Scrum practices. These games also help build multitasking skills in high-pressure DevOps environments, which any agile coach will be happy to use.

Now that you have some groundwork to help you understand the thinking behind agile games, you’re probably keen to find out what types of games you can play to build teamwork.

Here are a few agile games to whet your appetite. This list of games goes from the shortest to the longest playing times, each with its own objective.

1. Chocolate Bar Game

Playing TimePlayers RequiredFormatObjectives5 mins4+Virtual & in-personTeam building activity for customer feedback and iteration

The Chocolate Bar Game is ideal for new teams who are unfamiliar with agile practices. Teamwork improves as the members play this game and learn more about iteration. Entire teams can also play this game to understand how to integrate customer feedback into their retrospectives.

You can either play the game in person or play an online game with remote teams.

The Chocolate Bar game works as a Scrum simulation. The goal is to create a chocolate bar as if you were taking instructions from the product owner. Development teams choose their product manager who can also be the product owner. The rest of the agile team are the customers.

The product owner acts as a facilitator, instructing team members to create a chocolate bar that appeals to the target market. This chocolate bar must be delicious and can be made from either dark chocolate, milk chocolate, or white chocolate.

Additionally, the team can select a range of fillings to improve their product. Toppings and other unique features also come into play as teams can include organic or gluten-free features that cater to a niche market.

After each iteration, the project manager provides the team with customer feedback. Customers can give the software development team (or chocolate bar creation team) a thumbs up for their creation if they approve of the chocolate made by the agile team. Customers can also give team members a thumbs down if they don’t like the initial stages of their chocolate bar creation.

Teamwork involves recording customers' responses for changes before the next iteration, which involves the chocolate bar fillings. The team members will continue building their chocolate bar, adding or subtracting fillings and toppings until most customers are happy with their creation.

As you can see, playing the Chocolate Bar Game involves repetitive iteration based on customer feedback, which is the objective of this agile game.

2. How to Hug

Playing TimePlayers RequiredFormatObjective5 mins (or less)3+Virtual onlyAgile team collaboration

How to Hug is a simple game for improving team collaboration, especially on a remote team. How to Hug is a great icebreaker when introducing new team members.

The Scrum team can access this agile team-building activity online. The entire team uploads their photos for display on the How to Hug virtual circle. The whole team can then vote to place their image at the circle's center.

Once the agile team has a central image, the rest of the members move their images to touch the Scrum Master's image at the circle's center.

Everyone has a chance to place their image at the center of the circle, and the team repeats the process. Although a simple game, this is one of those virtual team-building activities that involve lots of laughs.

Team members learn about each other during this virtual hugging session with collaboration and team bonding helping to create a great team.

3. Ball Point Game

Playing TimePlayers RequiredFormatObjective15 mins, split into 3-min sessions4+In-person & virtualAgile production process

The objective in playing Ball Point is for the Scrum team to navigate agile projects better. By understanding the agile production process, the team appreciates the importance of self-organization. Self-organization is the cornerstone for creating Scrum processes that work so that the entire team can engage in effective iteration.

Entire teams can play this game physically or online, using game icons on the virtual whiteboard.

The common goal is for the team to move a ball or several balls around the table. Team members must all touch the ball or balls once. After one team member touches the ball, the next person must do the same. The Scrum team earns a point if they successfully manage to move the ball around the table.

Each sprint lasts for three minutes, and the whole team must participate in five sprints to see who wins the Ball Point game. During the first sprint, the team discusses their strategy and takes notes to anticipate how many points they will score in the first minute.

The second minute involves moving the ball around the table. The Scrum team records their points and new learning in the third minute.

As the game progresses, teamwork intensifies as members add more balls in the following sprint rounds. As the team passes balls simultaneously, the game becomes more complex. More thinking is required in the iteration process as team members attempt to increase their scores. After each round, the teams engage in a brief retrospective to see what tactics they can use to score more points in the next sprint. Simple but effective!

4. Marshmallow Tower

Playing TimePlayer RequiredFormatObjectives20 mins4+In-person onlyIteration & collaboration

This is an in-person team building activity, and the team will need a few supplies:

• Dry spaghetti
• One yard of tape
• One yard of string
• Marshmallows

Team members must engage in this learning activity in groups of four people. The Scrum master hands out 20 pieces of spaghetti to each team, along with the other provisions.

The objective here is to build the highest marshmallow tower with these items. The marshmallow tower must be freestanding, and team members must place all the marshmallows at the top of the structure. Some agile games use one marshmallow, while others match the marshmallow numbers with the spaghetti sticks.

Inevitably, the tower collapses as the team places the marshmallow on top. But the goal is to simulate the Scrum retrospective through several iterations. The whole team must quickly regroup through good communication and collaboration to improve each successive round.

The concept sounds simple, but its execution is deceptively tricky. Teams need to collaborate quickly, and you’re sure to see plenty of towers collapse at the last second as teams scramble to place the marshmallow on top of their structures.

But, repeat the challenge several times, and you’ll see teams refine their approaches to collaboration and iterate on their earlier creations.

5. LEGO Flow Game

Playing TimePlayers RequiredFormatObjectives60-90 mins3-9In-person onlyScrum simulation, iteration, collaboration, workflow

The LEGO Flow game focuses on a Scrum simulation. Agile teams build a virtual LEGO Advent Calendar to detail work items in an efficient workflow. Each section of the workflow involves specific role players.

The common goal is to build the items, find the following advent calendar number (analysis) and then identify a set of LEGO pieces that must align with the supply source (suppliers).

The Scrum team builds (builders) the LEGO item as they progress through the game. Team members must engage in constant iteration to determine whether the build is correct and acceptable to the market representatives or product owner (acceptors).

Agile coaches will love using this game as it is an excellent tool to introduce new teams to Agile. LEGO Flow offers new teams the opportunity to engage in new learning activities through a simulated Scrum exercise.

LEGO Flow is an agile game that requires three rounds, each with its own objective. These objectives include batch and phase-driven processes together with time-boxed and flow-based processes.

After each of the three rounds, teamwork involves sprint retrospectives to understand what went well and what challenges the team encountered. The objective is to analyze the pros and cons of each sprint approach, demonstrating the benefits of teamwork. The game ends with the building of an overall Cumulative Flow Diagram.

This diagram allows the whole team to view its strategies and decisions, consider where they went wrong in each round of this agile game, and enhance their workflow.

If time allows, the Scrum master can question team members about what policy changes they would make for future sprints.

Agile games and team building activities

The whole team can transform their work-life with virtual team-building activities over Zoom. Having some fun while learning definitely beats using a physical whiteboard and sticky notes to introduce new teams to the Scrum framework.

Easy Agile apps are yet another innovative way to ease your new team into the Agile family. Dive into the world of Easy Agile Scrum Workflow for Jira that you can combine with LEGO Flow.

Brainstorming as a group can generate a ton of ideas, but what do you do with all of those ideas after you’ve come up with them? How do you organize an entire team’s ideas? How do you narrow down the best solution? And how do you document the ideation session so you don’t lose any data? Never fear — affinity mapping is here. 🗺

Affinity mapping is an agile technique that helps teams reach a consensus after a brainstorming session, usability testing, or user research survey. It’s most helpful when you have a large amount of data to sort and when you need to distill all of that data into specific solutions the whole team agrees on.

Continue reading to learn more about affinity mapping, including when to use the maps, the benefits of affinity maps, and how to run an affinity mapping session.

What is affinity mapping?

Affinity mapping is an agile technique used to solve problems by distilling many ideas into the best solution or path forward. The exercise is designed to quickly get teams on the same page about a problem that needs to be solved.

Typically, affinity mapping occurs after a large group brainstorming exercise during which many team members and sometimes clients or stakeholders have given their input.

All of the team's ideas are added to sticky notes, which are organized somewhere for everyone to see. The team groups similar solutions until natural relationships form. Everyone involved in the session is able to see various paths forward, which can be discussed and narrowed down to the best solution.

Try affinity mapping whenever:

• A problem needs to be solved as a group
• The team has struggled to reach a consensus
• There’s an issue or problem that’s too complex or tough to grasp
• You need to reach one solution that everyone on the team will buy into
• Large amounts of data need to be sorted
• Data or survey results need to be analyzed
• A project or product is in a state of chaos

The activity sparks initial discussion on problems that are best solved by many minds coming together and agreeing on a course of action. Affinity diagramming is typically used in user experience design, UX research, and design thinking industries, but the practice can be implemented by any team that wants to distill information.

The benefits of affinity mapping

Affinity mapping provides a number of benefits for teams that need to solve a problem, sort large amounts of data, or reach a mutual consensus.

Affinity mapping helps teams:

• Prioritize what’s most important
• Unlock ideas that hadn’t been considered before
• Discover the “real” problem
• Work together to solve a problem (team building)
• Empathize with users or customers on common pain points
• Utilize multiple minds
• Reach a consensus together
• Make decisions without using up too much of anyone’s time
• Establish a safe environment to flesh out touchy or conflict-fueled discussions
• Facilitate equal participation, even from those who speak up less
• Involve stakeholders and clients in the discussion and agile process

The step-by-step process for affinity mapping

You can use affinity diagrams for a variety of reasons. They are commonly used to sort a large number of ideas after a brainstorming session or to make sense of data after usability testing, user interviews, or other user research.

Brainstorm ideas or collect data

The first step (or preemptive step) to affinity mapping is collecting your data points. If you are trying to solve a problem or make sense of a project, this will involve running a brainstorming session as a group. Make sure everyone starts solo when brainstorming to ensure no one is influenced by other people’s ideas before they’ve come up with their own.

It can help to frame whatever problem you are trying to solve into a “how might we” statement. For example, “how might we get younger audiences to use our product” or “how might we double last year’s sales goals.”

If you’re working with research findings for your session, you instead need to transcribe all of the qualitative data so that it can be organized and sorted during the mapping session.

Post the ideas or data for everyone to see

Take all of the ideas everyone came up with and put them on individual index cards, or use a separate sticky to represent each point on a whiteboard or wall. It’s important the surface you choose is visible to everyone.

Begin grouping data

As you add each point to the main wall, sort them into related groups. Organize the clusters naturally, combining or separating clusters as branching ideas form.

Don’t discard any duplicate thoughts, as these will help you visualize how popular an idea is. Continue to add to the board until every sticky note or card has a reasonable place on the visible wall.

Use a “parking lot” for ideas you can't sort

Create an area along the side of your wall called a “parking lot” for any ideas that don’t fit into a cluster. As you continue to build and sort the board of ideas, you may find reasonable spots for them.

Assess and name each category

Assess your clusters. Are there any clusters too similar to one another that could be joined together to create a larger group? Are there any clusters with too many branching ideas that should be separated into smaller groups?

Once you’ve completed your sorting and thematic analysis, it’s time to name each category. Don’t take too much time on this part. The category name just needs to generally describe the ideas inside the cluster. If you need to, vote on the best name to ensure too much time isn’t spent debating.

Vote and make decisions

If you’re analyzing a collection of data, you can now document the findings. What categories have the most data points? What connections do you see between clusters? What observations can you make from common themes?

Before dismantling the map, ensure you document everything with photographs so you can go back to the affinity map at any time to gather more insights.

If you’ve arranged ideas from a brainstorming session, it’s time to discuss the possible solutions and vote on the best option. Placing each solution category on an impact effort matrix helps the team visualize where their effort would be best spent. You can also work through different forms of voting, such as dot voting or the hundred dollar test.

Affinity mapping for remote teams

Many of the teams and businesses we work with are remote, which means getting into one room to collaborate around a bunch of Post-its isn’t an option. Luckily, there are plenty of online tools that make affinity mapping possible for remote teams.

You can create an affinity diagram template and follow nearly all of the same steps for affinity mapping by using online collaborative design thinking tools like Mural.

Affinity mapping brings teams together for a collaborative experience. It’s a simple process that ends with a consensus around the best solution or path forward. It’s especially helpful for complex problems, bottlenecks, or times when the team needs to get on the same page.

More From Easy Agile

Easy Agile is passionate about helping teams work better. To us, that means working more efficiently, effectively, and collaboratively. If you want more agile articles and how-to guides like this one, follow the Easy Agile blog for our latest content.

We build products specifically designed for Jira users to help agile teams collaborate using buyer personas, roadmaps, user story maps, and more. Our tools are simple to use and integrate directly with Jira for seamless product development. Try any of our plugins free for 30 days.

It's a Monday morning and I’ve just pulled into the Kiama train station carpark.

It’s a short commute to the Wollongong CBD, where I am greeted by the team as I enter the office.

We start the day with a morning huddle in which each of us shares something good that’s happened during the last 24 hours, what we’re going to be working on that day and whether we’ve come up against any blockers.

The entire team then takes a walk down to local cafe, Beast, and get a coffee together. It’s a wonderful way to start the day, with a group of inspiring people.

For me, customer support is up next and I am super keen to get into helping our customers on their day’s journey with our product. My past experience in customer support has shown me just how much customers appreciate timely and helpful responses. It can really change a person’s day.

When customers have been responded to, I continue with my daily work using Easy Agile tools. I can say for sure this does make managing and working through sprints much easier.

I’ve got great team mates; if I want to discuss something, get some feedback or pair up, my colleague Matt is always there to help. Here he is:

He is genuinely an advocate for software craftsmanship and I'm totally onboard with this approach.

Around noon, we all stop for lunch. Some of us will get takeaway from the local mall, and others will bring something from home, but generally we all sit together and enjoy each other's company. On Fridays the street market draws the attention of most of us. There will usually be a session on the Switch - Mario Kart or Smash Bros the most popular choices.

It’s back into things after lunch and I have a check-in with Dave to see how things are going. We discuss my journey so far and what my ideas are for our upcoming inception week.

It's great to be able to sit down and talk about how we can make our systems better and improve the day-to-day work for our team.

There’s a few more things to get done and then it’s time to head to the station for the commute home. Matt and I chat about software architecture and almost miss the train.

When I look back over the last couple of weeks at Easy Agile, what stands out is the culture and the values of the team.

The commitment to integrity, honestly, inclusion and work philosophy is truly inspiring and uplifting. Never in my experience have I started a work day where everyone shares something positive. it really sets the tone for the following hours.

Easy Agile is an amazing company, especially when I compare it with my experiences over the last 20 years in manufacturing, customer support and software development. The team at Easy Agile practically demonstrate a holistic approach to both work and life which is equally refreshing and encouraging.

We all know writing unit tests is important but sometimes it feels like it can take up more time than the feature work itself. I’ve found a couple of handy hacks that I feel have increased my speed when writing tests whilst also improving their quality and, being the kind fellow I am, I’m going to share those with you:

Hack 1: Use Testing Playground

I guess the first tip in this article is - use Testing Library. I didn’t make this its own point because it is already so popular. But if you are not using it yet, make sure you do!

Unit testing with Testing Library is really easy and intuitive. Despite this, it can still be challenging to find the right queries or to understand why an element isn't being matched.

Enter Testing Playground.

Testing Playground allows you to render a component in a sandbox providing you with direct visual feedback of the component. It also allows you to interact with the rendered component to come up with the best queries to select elements. And, like Testing Library, everything it does is with accessibility (a11y) in front of mind so it teaches you about the importance of a11y and best practices while you use it.

There are many ways you can use Testing Playground including a chrome extension and a browser based app.

The best way I have found which has been an absolute time saver for me though is by invoking screen.logTestingPlaygroundURL() right from the test block itself. I usually find myself doing this as soon as I get the component rendering, just to get the lay of the land and work out what parts of it my test might like to interact with.

Hack 2: Use test.todo

Please don’t jump down my throat, but I have tried Test Driven Development and didn’t like it. Like anarchism, I think it sounds awesome in theory, but found that it actually slowed down my development cycle when I tried to implement it.

I still like the idea of getting some thinking about testing down before I finish building a feature though and have settled on a process that, for me, seems to work well and keep my development moving along.

I now use Jest’s test.todo to record what I am going to test as I am planning to and building out a feature (Big thanks to Karl for first introducing me to the idea!).

My usual process goes a bit like this. First I capture the requirements spelled out for me by my awesome Product Owner (Hi Biz!) in test.todo form, like a todo list. Then, as I am building and encounter other edge cases and important testing areas I add these as test.todo’s too. That way, when it comes to testing time, I have thought through a lot of what I am going to test and am less likely to miss testing edge cases or important functional requirements.

A simple example for a test.todo for the following <UserDetails /> component:

import React from "react";export interface User {  firstName: string;  lastName: string;  username: string;  emailAddress: string;  SEN: string;}export interface ShowHideUserDetailsProps {  showDetails: boolean;  user: User;}const UserDetails = ({ showDetails, user }: ShowHideUserDetailsProps) => (  <>    {showDetails ? (      <div>        <h1>User Details</h1>        <ul>          <li>{user.firstName}</li>          <li>{user.lastName}</li>          <li>{user.username}</li>          <li>{user.emailAddress}</li>          <li>{user.SEN}</li>        </ul>      </div>    ) : (      <div>        <h1>Privacy Protected</h1>      </div>    )}  </>);export default UserDetails;

Might be as follows:

describe('<UserDetails />', () => {  test.todo('Should show user details when show details is true');  test.todo('Should NOT show user details when show details is false');});

Hack 3: Use builder functions

I used to find myself creating objects for each test to mock out values for testing. Then I wrote another component which used the same object and mocked it out again there. There’s got to be a better way, I thought. And Matt Smith at FinoComp introduced me to one.

I now use builder functions which return commonly used object types in testing and which allow properties to be overridden everywhere. There is certainly a little bit of extra time needed to set them up but I find that, once they are done, the next time you have to interact with that object you are so glad they are there.

// Example typeinterface User {  firstName: string;  lastName: string;  username: string;  emailAddress: string;  SEN: string;}interface ShowHideUserDetailsProps {  showDetails: boolean;  user: User;}// Builder pattern to build a mock object for the// ShowHideUserDetailsProps typeexport const buildShowHideUserDetailsProps = (overrides?: Partial<ShowHideUserDetailsProps>): ShowHideUserDetailsProps => {  const defaultShowHideUserDetailsProps = {    showDetails: false,    user: {      firstName: "Jazmyne",      lastName: "Jacobs",      username: "Kylee_Skiles37",      emailAddress: "Rashawn13@gmail.com",      SEN: "SEN-123456"    }  };  return { ...defaultShowHideUserDetailsProps, ...overrides };};

There are some limitations to this pattern however as they become less useful with deeply nested object types. Additionally, they do require some upkeep when object types change in the codebase which brings me to my next point...

Hack 4: Use a tool to mock your Typescript types

Look, I’m going to be straight here. This is the part where I plug my own work but at least I left it for last, right?

Whenever I found myself creating another mock object for testing I kept looking at my Typescript types and thinking, can’t something look at that and do it for me? This sent me down a search for a solution and I was so stoked to find intermock which is a command line tool that does just that. While it is still a work in progress and has some limitations I have found it super helpful when writing tests.

I did find using the combination of the CLI and copy/pasting from the terminal a little cumbersome though. How could I make this even easier I thought.

Enter my VSCode extension, Emulative. Simply select your type name, run a command through the Command Palette in VSCode and you can use Emulative to produce Typescript objects, Json objects or the aforementioned builder functions from Typescript types. These are automatically copied to the clipboard but the plain objects can also be sent to a new scratch file.

But wait, there’s more! Where I work at Easy Agile we have a bunch of properties we work with from Jira which aren’t accurately represented by string or number. With Emulative you can set up key/value pairs which will overwrite any matching properties which are found in your types.

Shout out to Easy Agile for giving me the time, resources and encouragement during an Inception Week to work on Emulative!

Well, that’s it for me, I hope you find some of these tips and tricks useful for speeding up front end testing.

Either way please feel free to sound off in the comments about nifty tricks you have found to improve your unit testing speed (or just how wrong I am about TDD).