Agile and Scrum have become some of the most widely searched terms when it comes to organizational management, project management, and organizational change. 

The danger, like many things in today’s fast-paced world that’s at your fingertips, is what you or your organization do with the information. Execution is everything, and successful execution is measured in products being delivered in iterations. The day-to-day operations are really about who you are as an organization and not simply what you do.

For these reasons, it’s best to start an agile discussion about what it isn’t to avoid any unnecessary strife within teams or organizations.

Buzz words within organizations are nothing new, and scrum has been the scapegoat for organizations failing to truly understand how to implement a true agile transformation. It is too easy for executives to “blame the process” instead of looking into the mirror and trying to decipher what went wrong. This brings us to our first and most important principle idea that must be screamed from the mountain tops...

Agile is not a magic wand. 

You cannot wake up one day, read a few articles about companies completing transformations in how they work and who they are, and decide, “if we only had a few great scrum masters, we could do this as well!”

Agile has been used as a magic wand by many companies to replace waterfall-type project management models. A few strategic hires of scrum masters, product owners, or product managers and VOILA! The company and its engineers can do twice the work in half the time.

Not so fast. 

Agile is no different than the keto diet. You want to try it for a bit just to see if it works, but realistically you can't just dip your toes in. It is all or nothing. Cut the carbs and increase the fat to lose weight, or continue the same vicious cycles. You need to be ready to stick with it and come to some hard realizations about who you are and your habits, or you will not achieve success.

When choosing to adopt agile principles, executives and decision-makers have to be ready to step up and understand what it is that needs to be changed and that change starts with them. Scrum masters are there to help lead the charge, but without the buy-in of top-level people in the organization, failure is inevitable; agile and scrum then becomes the scapegoat by simply saying, “We tried it but it didn’t work for us.”

It is no different than when I have tried to maintain the keto lifestyle and say, “I tried it, but I just never gave up milkshakes and beers,” and then went on to blame the keto diet instead of my decisions. If your organization is thinking of adopting agile and changing who you are as a company, then you have conquered the first steps to success. If you hope to fill position vacancies with scrum masters and product owners while refusing to break down siloed teams and change day-to-day operations drastically, agile is probably not for you or your organization.

Agile is not too restrictive. 

Many top-level leaders and middle managers will look at agile and think it’s extremely restrictive and filled with meetings that waste time and money. In reality, the opposite is true. If you look at the calendars of said people, are you asking why they are in all of those meetings in the first place?

Image: The Scrum Framework Scrum.org

Agile is team-centric, stripping out layers of management and empowering teams to make critical decisions on how to do work based on what is to be done and prioritized by the product owner. Is there a place for all of the managers in this model? There are, but not as many as you would think, and their roles have to drastically change. Like the scrum master, leaders must be able to constantly reflect on the company's transformation―who it is to become, and what it wants to become. The scrum master must have the authority and autonomy to coach up as well as within his or her team. The manager has to be able to support the teams in those decisions as well and carry the torch of change management that the scrum master is fostering through the agile transformation. The inability to do so only means that there may be too much red tape as well as the “that’s not how we do things here” sort of discussion.

Management should listen to their scrum masters and be willing to always reflect on how those changes should be implemented and how they can accommodate them as fast as possible. To delay it only delays the iterations of customer-ready products. If you are saying agile is too restrictive, perhaps we need to take a step back and ask what is restrictive about it and how do I or we become more amenable to new approaches of who we are as we work?

Agile can be adapted to fit how my organization does things. 

Unfortunately, agile is not Chex Mix. You can't just “pick and choose” what works and what doesn’t work. It is a work style change that you have to choose to adapt to and must be all-in. Many organizations will take the key principles of agile, put their spin on it and maybe even put a catchy acronym or new name on it, and then repackage it as their own “agile method.” I did that too with the keto diet. That’s also why I refused to change my habits and still have to explain to my doctor why I still have holiday weight from 2019 to shed.

Flexibility in agile comes in the day-to-day discussions and transparency with the team. Tackling organizational change in how teams communicate and work requires flexibility from all parties including developers, product owners and managers, and the stakeholders. Work that was originally planned a few sprints away as a top priority might have changed, or the scope may have been changed. These changes are alright, so long as the team is mature enough to discuss it as a team and come to the necessary conclusions to complete work in an iterative, deliverable fashion. This is very different than hiring scrum masters or product owners and telling them to forego the very training they finished to keep the peace and maintain the same poor processes that have been in place.

Organizations must embrace the opportunity to understand that there needs to be some major changes coming down the pipeline. Embracing the opportunity to better the organization through change early will create a better environment for developers and product owners, which will yield a higher quality product delivered to customers and stakeholders. If executives are not able to hear the word “no” and be comfortable with it, agile is most definitely not the right change.

Agile is much like your in-laws; it’s going to point out and bring to light the glaring issues you have as an organization. Be comfortable and accept it. No individual or organization is perfect. A proven method such as agile and “making it your own” is being a bit egotistical. Your way might not be the best and that thinking may just be the driving reason you are looking at agile as a transformation solution.