Rethinking our UI: How Easy Agile innovates for a better user experience

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.

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.

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.