The Common Stumbles of Leaping into Agility

The Common Stumbles of Leaping into Agility

Chances are that you’ve seen a company get on the bandwagon of agile adoption, transformation, and digitization. Regardless of what marketing phrase is used, “going agile” is becoming more of a commodity and expected tactic rather than a differentiator. If you are not agile, then you must be everything negative that is its antonym: waterfall, traditional, and old-school. Companies of various sizes spend a lot of time trying to apply agility into their operating model; some overhauling a lot, while others try to pick and choose only what they believe will benefit them. The latter is usually where the problems start. 

Taking from the framework only what is easily seen.

Agile frameworks are processes, structures, and approaches centered on co-creating the solution with the customer, releasing it, seeing it in action, and modifying the next portion of work based on what’s observed. There’s emphasis on checking-in with the end-consumer, frequently, along the way, and embracing the opportunity, rather than burden, of adapting to constant changes. These behaviors are driven by the primary goal of making the end-user happy. In other words, it’s a way of doing things in a manner that allows you to adjust to the ever-changing environment. 

Regardless of which specific agile framework is used, everyone wants to understand the framework, at a high level, in terms of three simple aspects: new meetings, new roles, and new tools. Unfortunately, when a framework is illustrated with just these visible aspects in mind, that which does not fit easily onto the illustration either has a tendency to get left behind during learning or is down-prioritized as an essential part of the framework, at most residing in footnotes or off-page references. What’s most-often forgotten are things which are much less visible, more difficult to understand, and quite fundamental to the framework’s success: the values and principles. 

Turning values and principles into ambiguous notions.

When it comes to the fundamentals of agile frameworks, powerful “values” are taught, such as commitment, courage, focus, openness, and respect. However, the interpretation of those can vary largely among companies and can be different from what the framework advises because, unlike explicit guidance synonymous with roles and responsibilities, values are more ambiguous and often a company already has specifically-defined corporate values. Just because a framework explains that people should not be maxed out in their work capacity and should have a free-time buffer for emergencies, agility, and basic sanity does not mean that a company is willing to adopt that notion and change its ways. It may not even see such behaviors as negative. “That’s just how it is here” or “we’re in that kind of line of work” are frequent defenses about why certain behaviors, which are warned against in many agile frameworks, may be tolerated in a company.

Principles are less ambiguous but still very difficult to implement. It's difficult to concentrate on working software when complicated change request documents are needed for scope alterations. It's almost impossible to co-create with customers when sales people and management are afraid to put development teams in front of the client. Companies that implement agile frameworks often try to apply agility to only certain places in the organization where they believe agility is necessary… or where it won’t rock the boat. This results in only taking pieces of the framework; the classic case study on why agile implementations fall apart. The whole idea of “disruption,” while boasted as the new thing to aim for, is seldom sought after my more-conservative organizations given the risks change carries.

Implementing the wrong parts.

It’s hard for some organizations to adopt an entire agile framework because the framework requires changing the organization. That’s the whole point of agile transformation. While a framework can be modified to fit the more rigid parts of the organization that themselves cannot be altered, it’s very easy to modify, versus leave intact, the wrong parts. 

Each framework advises that in order to properly adopt it, you have to adopt it correctly. Frameworks, especially the more established ones which have been updated over time, have gone through peer-reviewed testing, practical real-world experiments, and case studies. Anything that has received criticism or failed to provide evidence of reaching the frameworks’ boasted goals, got modified over time. Frameworks evolve. They are “agile” and practice what they preach.

When implementation of a framework turns into applying just the “easier” pieces of, we begin to lose the ability to say “look at all the research that shows the framework works” if that research is based around implementation of the framework that is different from the way a company wishes to implement it. We cannot say that we decided to use a hammer to help hang some pictures on the wall, explaining how great hammers are, if we only chose to use the hammer’s handle.

Implementing “our own flavor."

When in doubt, an organization may try to use the notion of “we’re just agile… we don’t use a specific framework” to get past the fact that they are not modifying any of the organization that actually needs to change. As long as development is iterative, there are terms like “agile teams” mentioned in the org chart, and common rituals of “stand-ups” are executed, middle management may be able to get away with convincing senior management that they have sufficiently executed agility in the organization. This leads to the notion of doing agile rather than being agile. 

Many of us are quite intelligent, have extensive experience, and understand how to develop and deliver initiatives ranging from small projects to entire company startups. Yes, it’s true every framework was created by people. However, just like small businesses, many more are created than actually survive the test of time. There is a higher chance of success when adopting what has proven to work, the way it was designed and verified to work, rather than making your own version. While being a trailblazer and trend-setter may seem attractive, that tremendous potential for return on investment comes with a tremendous risk and high probability of failure. It’s at times better to work off of the research another R&D department has already spent tremendous time, effort, and money on.

Assuming successful delivery means successful agility.

Getting things done is what we are often graded on. Things need to be delivered. There are almost-endless ways to ensure things that need to get done, actually get completed, and when push comes to shove, usually processes and rules go out the window in exchange for meeting deadlines. Just because a company says that they use sprints, Scrum masters, and some type of product owners… and its leaders have a track record of delivering, does not mean that they are being agile with their delivery. The one who gets things done can be incorrectly looked at as the one who gets things done in an agile manner. Effective and efficient are still confused by some. A common situation here is one where senior leadership says “you get things done, and you say you are doing Scrum, you must be doing Scrum well.” Be carefully who you ask about how to be agile. Correct process leads to easier delivery but effective delivery does not always mean efficient process.

Abusing the agile guide.

Every framework has some kind of agile guide. Scrum, for example, has the Scrum master; the person responsible for ensuring the team is protected for distraction, the impediments are handled, the process is adhered to, and the organization is going in the proper agile direction. This is a person that should not be afraid to say it as they see it, should not be on the payroll of the team, should not have the same KPIs as the product owners; all to avoid a conflict of interest about what their goals really are.

Agile guides are just that. They guide others. They are supposed to be telling the players how to play better as a team and should not be ones also on the field playing with them. Some companies expect the guide role to also do things other than guiding, mentoring, and coaching. It’s not uncommon for a Scrum master to be hired only to later become disappointed as their role morphs into a Scrum product team delivery owner and manager, concentrating on pushing team members to get things done rather than protecting teams from disruptions and those who would otherwise incorrectly push them with unrealistic expectations.

Shoving various types of expertise into one.

Doing things right and doing the right things often gets squeezed into a single role because of the common excuse that both are sides of the same coin… which is a common excuse for “we don’t have money for all these agile roles.” A Scrum master, for example, will need to be an expert in Scrum but not necessarily in the functionality of the features being built by the team. That’s instead the job of the development team. While a Scrum master will need to know the concepts of backlog prioritization and tradeoffs, they don’t need to know what feature is more valuable than which other feature in the backlog and why. That’s the job of the product owner. Requiring the Scrum master to have domain knowledge at the level of a product owner as well as functional knowledge at the level of the developers, is requiring the Scrum master to be able to fill in for others and not have time or a mindset for their own role. We all know that when one can fill in, one eventually will fill in regularly, leaving very little time for their true job and we end up with a coach trying to play with the players during a match. It won’t be pretty.

Making people wear more hats than can fit on their heads.

Doing more with less people is never going away. It surfaces with a vengeance during agile transformation, especially if the organization has a focus and preference on technical competencies for all of its roles. Initially, you may see testers, architects, and developers shoved together into one type of multiple-hat-wearing guru. Then, a further step may be taken to also infuse such a hand-on technical role with a combination of people management and agile coaching. After all, what better than someone who does it all for one paycheck. If the paycheck is bigger than average, that’s even more leverage to hold that person liable for not delivering on objectives, regardless of how conflicting those objectives may be when lumped into one profession. Agile is not doing more, with less people, faster.

Relying on the few-days expert.

Some companies make the mistake of quickly creating transformation experts by sending some people on two-day certification courses and hoping they come back with answers on how to be agile. The certification approach has become a quick and practical niche of education which helps people gain up-to-date fundamental theory with the ability to try some things out immediately in practice. While certification is important, since one needs to be able to stick to certified fundamentals when in doubt, replacing experience is difficult. Although it’s cheaper to certify someone on the basics rather than bring in an expert, big topics like agile transformation can be more expensive in the long run, if they even succeed, when the wrong person is put in charge of them.

Scaling with buzz words.

While adopting ability in a team is difficult, adopting it across the organization, in a scaled manner, with multiple teams is a whole new ballgame. Scaling, to many, simply becomes a notion of having more roles and more meetings. Someone may start to throw around buzzwords, like “product increment planning,” not really seeing it as more than just a larger number of people, meeting quarterly, to align. It’s usual for some scaled elements to be taken from more-common scaled frameworks, like SAFe, and then shoved into a company’s current process in order to scale that process for more groups. In reality, there are many scaled frameworks, such as S@S, LeSS, NEXUS, DaD, and others, and their goals are to simplify with scaling instead of adding a layer of complexity, bureaucracy, and hierarchy.

Bigger does not need to mean more complex and in order to be truly agile, a scaled framework must be well-understood so that it can properly address the complexity that is a side effect of growth. Simply making a “lots of people in a room” meeting, appointing a scaled “Scrum of others'' role, or creating several levels of owners of nested teams might not have the best results. We may like a snack such as ice cream. We may enjoy an entree like fish. However, putting them together, on a larger plate, calling it a “meal”, and eating them simultaneously, might result in some unwanted side effects.

Not seeking an experienced helper.

I often say that correct agile adoption is hard but incorrect adoption is a skill that we all start out with. While it’s impossible to identify, resolve, and prevent all of these risks, and while there are many more pitfalls and dangers, it’s essential that a company looks at these aspects and makes an informed decision... not about what to do and what not to do from a detailed implementation tactic, but to bring in an expert who is aware of these factors and has successfully demonstrated education, experience, and results in the matter. Adopting agility that actually works is an art that needs an artist. Winging it and hoping it turns into a masterpiece is risky. Agility is about trying fast and failing fast in order to learn fast. Make sure you don’t turn it into trying fast and failing big. There are plenty of incorrect ways to transform an organization.

These opinions are my own unless I explicitly cite otherwise.

To view or add a comment, sign in

Insights from the community

Explore topics