{"id":61510,"date":"2021-06-03T18:24:12","date_gmt":"2021-06-03T18:24:12","guid":{"rendered":"https:\/\/explore.local\/2021\/06\/03\/five-step-agile-work-environment\/"},"modified":"2025-04-04T19:47:55","modified_gmt":"2025-04-04T19:47:55","slug":"five-step-agile-work-environment","status":"publish","type":"post","link":"https:\/\/degreed.com\/experience\/pt-br\/blog\/five-step-agile-work-environment\/","title":{"rendered":"How I Learned to Stop Worrying and Love an Agile Work Environment"},"content":{"rendered":"\n

Career mobility has become an increasingly critical component of a healthy enterprise talent strategy; it\u2019s cheaper than sourcing external talent, and it drives employee engagement and unforeseen innovation. But because it is tied to so many areas of the business \u2014 talent acquisition, learning and development, compensation, workforce planning \u2014 it\u2019s hard to know where, how, when, or with whom to start. <\/p>\n\n\n\n

A global, top-down mobility approach is appealing but increasingly, the complex strategies that solve today\u2019s needs are outdated by the time they\u2019re implemented globally. Organizations notoriously spend years on competency frameworks, for example, only to realize they are outdated by the time they\u2019re complete<\/a>. These tumultuous conditions, we hope, are temporary. But if COVID-19 has taught us anything, it\u2019s that the pace of change will only accelerate. Rather than ignoring this reality, organizations should build a culture of experimentation by favoring a more agile work environment over long-range planning when innovation is required.<\/p>\n\n\n\n

In the early days of software development, the business would put together long, complex lists of technical requirements, and engineering would commit to building a product, exactly as outlined, with every associated bell and whistle. Turnaround times were measured in months or years, with few mechanisms to capture feedback on usability, value, or changes in the market. The products built this way were sometimes successful, of course, but the risks were huge: what if users don\u2019t like this solution? Or can\u2019t use it? What if the problem has changed so dramatically that our solution no longer addresses a need? <\/p>\n\n\n\n

These risks pushed IT to move toward agile methodology \u2014 building lean first iterations, collecting feedback quickly, and releasing and testing improvements more frequently. This takes the burden off of the initial requirement-gathering phase, acknowledges the dynamic nature of today\u2019s world, and prioritizes the most important type of feedback: the kind we get from users when they\u2019re actually using the product.<\/p>\n\n\n\n

People in the L&D space know that stealing from marketing and IT can sometimes garner amazing results \u2014 and this is no different. You can steal the idea of an agile methodology as well to create an agile work environment at your organization. Let\u2019s take a look at how this can be done.<\/p>\n\n\n\n

1. Champion an agile work environment within your organization.<\/h2>\n\n\n\n

Usually this requires experimentation. Perhaps you\u2019re ready to roll up your sleeves and get going. You might even feel a little excited. But then you remember: you work in a corporation. Things are complex, sometimes bureaucratic, and principles that work for startups have failed in the past (remember the bean bag chairs?) That\u2019s not how budgets get allocated, and you don\u2019t want to risk being seen as naive.<\/p>\n\n\n\n

Luckily, there\u2019s a ton of research<\/a> to tap into as you become your team\u2019s lean champion. One study found that projects applying lean methodology were more likely to come in under time (5% sooner), where others usually finished right at time. Budget-wise, lean projects came in, on average, 9% under budget, while others were only 2% under.<\/p>\n\n\n\n

\"The<\/figure>\n\n\n\n

A company Degreed recently worked with had a large call center population, and trouble with turnover. Attrition rates had been raising red flags in this part of the business for years, and engagement rates for this population were low. One of our Degreed champions committed to approaching the problem differently, and began by compiling data on previous efforts. There had been some work done in the area, but many of the solutions felt like shots in the dark. She knew she needed to better understand the problem before she\u2019d find the right solution.<\/p>\n\n\n\n

She didn\u2019t begin by championing agile practices across the entire organization all at once. She chose to implement an agile work environment for one particular initiative to demonstrate the power of the approach.<\/p>\n\n\n\n

2. Get to know your employees.<\/h2>\n\n\n\n

Remember when implementing an agile work environment, we\u2019re looking to maximize value for our employees, which means we have to first dig into their challenges. Most enterprises begin with engagement surveys, and these are great places to start. Many of our clients, for example, come to us with a goal of improving the learning experience after a less-than-stellar result for a question like \u201cHow does the firm support your development?\u201d While investments in Learning Experience Platforms<\/a> are great ways to enable your team to drive more meaningful experiences, creating real value for employees requires going deeper into their challenges with the current environment.<\/p>\n\n\n\n

Whether it\u2019s in response to an engagement survey, or retention\/promotion rates within an area of the business or demographic, grab a few of these folks (and a few of their managers) and speak to them candidly about what\u2019s going on. Interviews work best here, but a follow-up survey with free response can work well too, depending on resourcing. In some cases, especially if there\u2019s a lack of trust, it\u2019s helpful to use a third-party firm, but even in high-trust environments, ensure your employees know the responses are confidential. Everyone has to be aware that this isn\u2019t a shame or blame game.<\/p>\n\n\n\n

Conducting interviews to deeply understand the challenges your people are facing takes discipline. This framework<\/a> from the Silicon Valley Product Group has been helpful as we\u2019ve prepared for and conducted interviews like these.<\/p>\n\n\n\n

Our call center champion found that many people were leaving within the first 90 days, and those that made it past 90 days were likely to leave at around two years. So her problem was actually two<\/em> problems, and she used her interviews to dig into each. Because of the high volume of hiring and the high turnover, she was able to sit in on exit interviews for both populations. <\/p>\n\n\n\n

3. Define employee challenges. These are the problems you\u2019re trying to solve.<\/h2>\n\n\n\n

Once you\u2019ve conducted the interviews, it\u2019s time to make sense of what you learned. Are you hearing similar themes from your employees? If so, what are they? (If not, you likely haven\u2019t spoken to enough people yet, so get back out there!) Group what you\u2019ve heard into the key challenges and prioritize. <\/p>\n\n\n\n

When prioritizing, you\u2019re living in the tension between two poles: maximizing user value and minimizing waste. At this stage, imagine Steve Jobs on your right shoulder and Marie Kondo on your left. Steve says think bigger, and focus more on delight. Marie helps to keep unnecessary complexity in check. If talking to imaginary characters doesn\u2019t work for you, try using the Value vs. Complexity model<\/a> to rank these problems, with the goal of finding those with the highest potential value and the lowest effort required to solve.<\/p>\n\n\n\n

\"Find<\/figure>\n\n\n\n

In the call center, it was discovered that employees leaving within 90 days of being hired struggled with many things, chief of which was friction in processes and social isolation, whereas longer tenure employees were leaving largely due to lack of career progression. Managers were stretched so thin that they could often not give either population what they needed: adequate onboarding or adequate career conversations.<\/p>\n\n\n\n

4. Design a Minimum Viable Product (MVP).<\/h2>\n\n\n\n

Once we have a clear understanding of our priority problems, we can start to form hypotheses about the best ways to solve them. The critical element in an agile work environment is that our solutions, no matter how sexy they seem, are hypotheses. For each problem, frame your solution as an MVP, identifying:<\/p>\n\n\n\n