Change Management Week

Everyday this week!

How to Be Agile

Andrew Long

Andrew Long

Share on email
Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

Table of Contents

We met Drew through our customer (and follow guest blogger, Marc Schadee) and wanted to share his ideas on How to Be Agile because they are awesome and we thought you might think so too! Enjoy.

In the modern software development world, it is not enough to simply write code. Many businesses are discovering that their quality products and services are being overshadowed by smaller, leaner startups with shinier software. I’ve watched companies flounder and go out of business because their competitors were able to adapt faster to their shared pool of customers. That is what is at stake for every business that is unable to effectively harness agility. 

For many businesses, phrases like “agile” or “scrum” are terms that their software developers use to describe two-week release cycles. Maybe they’ve promoted someone to Scrum Master or created some other meaningless title to show the world that they, too, can be hip to the latest trends. Maybe they even bought laptops for their developers and let them wear jeans on Fridays, because that’s what all the cool companies are doing. These are all nice things, but they have absolutely no value, and by themselves make absolutely no difference. Like a kindergartener recreating the Mona Lisa with finger paints, you might get the colors sort-of-close, but you’re missing all the substance.

More Than a Buzzword

There are a lot of things that Agile is not. Agile is not a software thing. Agile is not a cure-all for a failing business. Agile will not make people invest in your ideas. Agile will not convince the good devs to come work for you. Agile will not solve the strife internal to your organization. Agile is not magic. It is not a process, or a structure, or a methodology. But most of all, it is not just a pretty word that you stick on your marketing pages and pat yourself on the back.

Agile is a mindset. It is a culture shift. Not a culture – a culture shift. If your company is agile, then there will be a constant renovation and expressing of ideas. Agile companies don’t stagnate – they adapt. They regularly review their systems and processes and work to improve them. Agile companies have a deep-seeded desire to improve and a need to compete. Not to compete against each other, but to work together to compete against everyone else. This is why they are successful, and why they are so hard to keep up with. An agile company is a Team.

In 2001, a group of software developers from various backgrounds met to figure out how to write software that can keep up with the rapidly changing world. What they produced was a set of four values and twelve principles that together drew a line between successful software development teams and everyone else. This was not a set of rules or requirements, and there is no suggestion of how to implement these ideas. The document, known as the Manifesto for Agile Software Development, simply put on paper what a lot of people and businesses had already figured out – that times are changing and if you want your business to thrive, then you have to change with them.

This seems like a simple enough concept, but it has certainly ruffled its share of feathers. The problem, I think, stems from the difficulty in comprehending exactly how fast things change. For developers, it is certainly possible to be four days into a two week “sprint” and suddenly be told that business has decided that your project is entirely unneeded. An agile team will roll with that and make it work. From the business perspective, a large enterprise may find that a little side-project is more popular with customers than their flagship product. Again, an agile company will take that for what it is and change their marketing to match.

Consider Google (now known as Alphabet), a company whose entire world was wrapped in a search engine (and advertising) until 2004. Gmail was introduced to the public in April of 2004, but started out as an internal side project of a single developer. It became so popular internally, that the company decided to toss a few ads on and release it for free to see if anyone would use it. Today, Gmail is one of Alphabet’s flagship products, alongside the Google search engine and other things like Wear and Android that only exist because the company was able to adapt to changing market trends.

For Alphabet and thousands of others, agility is built into the structure of the entire company. Agile is not something they do, it is something they are. In agile organizations, managers exist to support their team, work is prioritized based solely on its value to the customer, and every part of the structure is designed to allow frequent releases and sudden changes. That is done by automating everything that can be automated, encouraging teams to organize themselves, and identifying (and removing) every single thing (or person) that impedes the flow of work.

Good Enough Isn’t Good Enough

Many companies claim that they are agile. They prove this by putting their work on a Kanban board and comparing their velocity every two weeks. They use terms like “sprint” to describe a unit of time. They talk about “features” and “stories”. All of these are great things, but they do not make a company agile. Some of the more observant teams will describe their process as “wagile” or “scrummerfall.” Often, for some reason completely alien to this writer, they will be quite proud of these terms, as if they’ve discovered some way to cheat in the competition of buzzwords. What these terms really mean is that the team has little or no understanding of agility as a concept, and are trying to wrap different methodologies together without fully understanding why.

For these teams, “waterfall” is the antonym of “agile.” In reality, these two terms have no relation whatsoever. It has been stated several times that agile is a mindset. Waterfall, in contrast, is a methodology. There exist an infinite number of methodologies that a team can use to accomplish a task, and all of them are equally valid. Adapting some version of a waterfall methodology to work alongside an agile mindset is totally feasible. In fact, there are many methodologies used in agile companies that resemble short waterfalls, or perhaps resemble many waterfalls happening concurrently. The opposite of agile is not waterfall, it is “static.”

Static Companies

The values of agile stress that things like working software are more important than documentation, and that people are more important than processes. These seem like easy ideas to get behind, until they are tried by a static company. A static company may value its employees, but more often than not it does not trust its employees to gather requirements or make decisions. A static company may have competition, but often, it does not compete with other companies offering similar products. A static company may claim that their software is great, and have white papers and product descriptions that sound awesome, while their product is buggy and customer requests are ignored. Static companies make a plan or a contract and they stick to it, to the letter, regardless of how the wind blows.

“A smooth sea never made a skilled sailor.” (Franklin D Roosevelt)

Quite often, this stasis is so ingrained into the company culture, that it can be difficult to recognize until it is pointed out, like white noise that you don’t hear until it has stopped. These companies have numbers and charts to show how many people buy their product, but no way of knowing if the users actually like their product, mistakenly believing that these are equivalent. Workers generally do what they are told and try not to ask too many questions. New employees may be difficult to find, and when they are found, many of them leave after a very short tenure. These things are not questioned – it is simply the way things are. 

In static companies, product requirements come from the company, not the user. By the time requirements have come to the crafters making the changes, they have passed through so many hands that tracking down the original requestor is impossible. Once the change is made, it has to go back to the company, through several more layers of bureaucracy, before some person or group who answers to neither the users nor the crafters decides that the change is prudent enough to be given to the users (who, again, did not request the change in the first place and may not have even known it was happening).

In static companies, the developers, the testers, the writers, the marketers, or anyone else who helps craft the product, which here we are calling the crafters, do exactly what they are told. If a crafter spots an error in a request it may take days to get it corrected, so the crafter is likely to decide that the correction isn’t worth the effort. Deadlines are often set by the same people making the requests, who often have no idea how much work is involved, resulting in crafters focusing on pushing changes quickly, instead of creating quality products. Single crafters are often “siloed” as the expert on a single product, and isolated from changes elsewhere in the company, believing that someone, somewhere, has a picture of the whole product and knows how all of the pieces fit together.

Agile Companies

Agile companies have self-organized teams. This is not a recommendation – it is one of the twelve principles of agile. If your company does not have self-organized teams, they are not agile. In a self-organized team, team members gather requirements, perform the work, test the product and deliver it to the customer. If the team needs a business analyst, then they get one. If they need to ask the users a question, they contact the user and ask. Self-organized teams are usually quite small, with a handful of specializations, and everything they need to succeed.

While crafters in static companies get their requirements from the company, those in Agile companies get feature requests from customers. Agile teams develop goals based on requests and feedback from customers, and work together to achieve those goals. As mentioned previously, managers on such teams play a support role, providing resources, education, tools, and (perhaps most importantly) funds to the agile team. Managers in agile companies do not dictate how the team performs tasks, or even what tasks they perform. They simply ensure that the team has everything they need to be successful. 

This is a scary concept for a lot of businesses – just taking crafters off the leash and letting them do what they want sounds crazy. While such teams generally have a business liaison, usually with a title like Business Analyst or Product Owner, that person is still part of the team, and cannot set deadlines or make demands, any more than any other part of the team. Questions often come up, such as “what if they slack off?” or “what if they do it wrong?” These are valid questions, and the answer is the real secret to agile – if you can’t trust your employees, you shouldn’t have them.

Does that mean that you should fire every employee that doesn’t perform at their highest level? Of course not. But you shouldn’t ignore them, either. Managers in an agile environment have the unenviable task of building up not just the team, but every individual on it. If a team member is underperforming, it’s up to the manager to determine why. Perhaps that person needs more training, or there is a social conflict, or maybe they are in the wrong “bus seat” (that is, maybe they would be better off fulfilling a different role). Firing the employee should be the last resort, but as with any business, may be unavoidable.

Agile companies, just like every other company, have competition in their fields. Crafters, regardless of their craft, prefer to work with agile companies. What confuses a lot of static companies is why crafters prefer agile companies. Agile companies show as much agility in their employment practices as they do in their products, constantly working with their employees, as they do with customers, to resolve issues and improve quality.

This is why agile companies often have “perks” that seem silly or even inane. Things like 15% time, unlimited time off, flex scheduling, and lax dress codes are all things that sound like something that a primadonna spoiled dev would put on their wish list. Static companies may look at perks like this and think that the perks are why employees prefer agile companies. The static companies may implement some of these policies, within reason, and hope that the old adage of “if you build it, they will come” holds true. In reality, though, employees do not work for agile companies because of the perks, agile companies have perks because of their employees – those perks are necessary to be productive and are specific to the needs of the employees.

Nothing Worth Doing is Easy

When a static company decides to become agile, the first step must be introspection. The entire company must commit to the agile transition. The company has to research what agile is, study different agile methodologies, and provide training and get buy-in from every single employee. It’s common to assume that agile is a software thing, but the software team does not exist in a bubble. If the company is not agile, then an agile software development team cannot exist.

The value of training and buy-in cannot be overstated. Even with them, there will be some members of the organization that will be resistant to change, but without them, change is nearly impossible. A handful of individuals trying to guide the culture of an entire company is like trying to steer a cruise ship with a rowboat. Most people, when given proper training and reassurance, are very willing to adopt an agile mentality. 

Why do some people need reassurance? There are many reasons. For example, some people will have become comfortable in the position they are in and do not want things to change. Other people will be afraid that they will have less authority with self-managed teams. But the biggest resistance comes from those individuals who most feel that their job is at risk by the transition. There will always be some individuals who feel that they cannot compete in an agile environment because they do not have the technical ability. Often, these people are able to coast with very little difficulty in static environments but agile environments, because of their self-managed nature, require a level of accountability that can be very daunting.

The best way to handle this is to give the employees plenty of opportunity for training. Giving the allowance (but not the requirement) for training will provide a litmus test that can help determine which employees will be best suited to their roles. An opportunity may also exist during the transition to allow concerned employees to train for different positions, if they feel they are not qualified for the position they are in. In situations where training is offered but the employee actively refuses to improve, the employee is generally let go. 

Following training and buy-in, a business must make a determination on what kind of methodologies they want to adopt. Of course, each team may adopt different methodologies that suit their needs, but generally a transitioning business will try to align their various teams to a single set of tools and processes, so that they can focus more on the culture shift and less on the new workflows. At this point, if they haven’t already, it is strongly recommended that the company hire an agile coach to help steer the transition. help guide them in this decision and others going forward. Most companies adopt a computerized Kanban board with Azure DevOps or Jira and select a Scrum methodology, but these decisions are going to have to be suited to the company and its people. If the first thing you try does not work out, the teams can always work together to change it, later.

“There is no try, there is only do or do not.” (Yoda)

Scrummerfall isn’t a thing. Wagile doesn’t exist. Once a company makes the decision to adopt agile, and the crafters make a commitment to do the same, then there can be no half-measures. A company cannot effectively be half-agile. The company and all involved have agreed to open collaboration, accepting change, and working together to achieve their goals. Implementing new tools and processes takes time, but becoming agile takes only a commitment.

In an agile organization, implementing tools and such is an iterative process. Crafters in various departments will form teams, and start sorting out work. There will be long conversations and arguments. Some people will take on more work than they can handle, and other people will not have enough to do. These things are inevitable, even with the best planning, so let them happen. The crafters will mostly sort things out and the managers will be available to pick up the pieces. It will take some time for everyone to get into the groove of working with freedom, trust, and accountability. Every iteration, encourage crafters to participate in retrospection, and find ways to improve the process. If those ways work, encourage them to communicate with other teams and share their new skills. In most cases, the chaotic crossover doesn’t take very long – it’s amazing what self organized teams can accomplish when they are given the freedom to do so.

But beware – the biggest stumbling block that I have seen organizations make is well-intentioned limitations. Once they have tasted freedom, your employees will ask for some unusual things. You may have requests for things like unlimited PTO, or dress code changes, or the ability to work outside of office hours (you’ll be surprised how many people prefer to work at night, if given the opportunity). The question you, as a representative of the business, have to ask yourself is, “Do I trust my employees?” If you do, then give them what they’re asking for and trust them to get their work done. If a business does not trust their employees, their best employees will find a business that does.

One of the best examples I have seen of well-intentioned limitations is on 15% time. During transitions, every company I have worked with has had someone at some time ask for the ability to take company time for side projects. Usually, the ask is based on the very successful programs by companies like 3M or Alphabet that allot a certain amount of time every iteration for experimenting. 3M provides fifteen percent of their working time (which is where the term originates) and Alphabet reportedly allows twenty percent. Regardless, both organizations, and countless others, give employees complete freedom to do whatever they want during this time (with the understanding that the company owns whatever is produced, if anything is). Employees often use this time for studying, improving their craft, or experimenting with new technologies and tools. Highly marketable things like Post-It notes and Gmail were products of 15% time.

Where many newly-agile companies go wrong is by negotiating requests. In the case of 15% time, most newly-agile companies will agree with allowing the policy, but will restrict it to allowing work only on things that will benefit the company, or only on training, or will say that employees are allowed to use the time, but it isn’t going to be allocated (that is, they can use their spare time between projects). All of these caveats sound fairly reasonable from the management perspective, but in reality, they negate any positive effects that the idea could have. If this time is limited to learning, employees that would do experimentation are not likely to use it. If experimentation is limited to things that the employee is already sure will benefit the business, then it’s not really experimentation, is it? And if we’re being honest – if the time is not allocated, crafters will not trust that the company actually allows it. It may seem to a manager that you are negotiating work-time, but in reality, what you are negotiating is trust, and that is not a thing that is negotiable.

This is one of the reasons why agile transitions are so difficult, and why they so often fail. It is easy for a company to say they trust their employees, but for agility to be possible, that trust has to be more than a word – it has to be a real value for the company and all of its managers and crafters. This trust is one of the twelve principles of the agile mindset, and without it, a company cannot be agile.

It has been noted that agile companies provide higher quality products at a faster pace. This is because when a company and its employees agree to become agile, they are agreeing that the trust that the company is providing will be met with the highest quality that the crafters can provide. Agile crafters work daily with their business counterparts and the customers to ensure that what they are crafting is exactly what the customer wants. Crafters automate every process they can so that they can deliver higher quality, faster, with lower risk. How they do this, of course, is up to them, but every person I have worked with who was given the freedom to use their talents to improve their processes and products has done amazing things. Agile teams, through the use of collaboration and the attention to technical excellence, come up with ideas and improvements that no individual could possibly have imagined.

That is what agility is all about – it is a continuous culture shift focused on improving the business, so that it can improve the processes for the crafters, so that they can improve the products for the customers. It must be continuous, because the customers’ needs will change, the crafters’ needs will change, and the business’s needs will change. Change is inevitable, and a static company cannot compete in a changing market. To be agile, a company must place its trust in its crafters, give them the freedom and tools to do what they do best, and let them create working products that customers actually want. Anything less than that is just buzzwords.

Thank you,

— Drew Long

Be Agile!

One reason we love this article so much is that it validates and gets to the heart of what we believe at Netmind… a lasting transformation must be a people‑based transformation.

Join our #AlwaysLearning Community

Follow Us

About the Author

Andrew Long

Andrew Long

As a certified Scrum Master and an experienced Software Craftsman, Drew Long has been helping technical teams innovate and reach their goals for more than a decade. He has championed technical modernization efforts and agile transformations at multiple organizations, introducing leaders and crafters alike to previously alien concepts such as SecDevOps and Scrum. He takes pride in his ability to coach teams and individuals toward a higher quality of work and a more profound measure of personal success. When he's not iterating product development processes, Drew spends much of his time joining his wife and three children on exciting adventures in faraway places. Follow Drew on LinkedIn.

Related Insights

Onsite Training Request

Please provide the information below to help us to customize your solution. 

Contact Us

Netmind US
3372 Peachtree Rd NE, Ste 115
Atlanta, GA 30326
T. +1 (678) 366.1363

Office Hours:
Monday – Friday, 8:30-5:00EST

General Inquiries:
[email protected]

Sales Inquiries:
[email protected]

Request Information