Luis Goncalves
Last updated on | Agile General Knowledge

Top 3 Reasons Why Companies Struggle With Agile and Scrum

by Danish Wadhwa
why companies struggle with agile

Why Companies Struggle With Agile and Scrum

Agile methodologies involve new values, practices, principles, and benefits in comparison to traditional Waterfall method. As agile is a radical alternative to command-and-control-style management, its methodologies have spread across various industries and functions and also into the C-suite. National Public Radio(NPR) uses agile methods to create new programmes. One of the leaders in cloud backup services, Intronis, employs agile in marketing. C.H. Robinson is a known third-party logistics provider globally, deploys them in human resources.

The effective implementation allows businesses to take employees out of their functional silos and turning them to self-managed and customer-focused multidisciplinary teams, speeding up profitable growth and helping to create a new generation of skilled managers.

The general adoption of agile ideas, tools, and frameworks by businesses have happened, but only a few of them are making the most of its benefits by accepting agility as the end goal. Baked into frameworks of agile is risk mitigation. Risk can come in different forms like:

  • Not suitable for purpose
  • Not liked by customers
  • Changing of conditions
  • Cost overruns
  • Missing of deadlines
  • Quality is low
  • Compromise on security

If you are using Scrum, Kanban, XP, or SAFe; it doesn’t mean you are appropriately protecting yourself from these risks. This means you are not making the most of benefits. When it comes to traditional SDLCs, they were designed to mitigate risk. The roles of project managers make a difference, ensuring risk mitigation appropriately.

If we talk about flexibility and change; traditional SDLCs usually go too far with control and do not provide expected benefits. I am not saying waterfall is bad, but it requires you know with certainty the end state, the cost to get there, and its time of completion. Any change to the plan risks disrupting the certainty in these variables and the happiness of your customers.

Transition to agile requires the understanding of agile manifesto and its frameworks. This article guides about all the reasons behind the organization’s struggle with agile and scrum.

Work Culture

Organizations need to understand that the methods that comprise “Agile” will not solve any pertinent issue in their culture or “the behavior of their employees.” Problems of distrust, lack accountability, respect, or fear of failure are all readily exposed by Scrum( Framework of agile). For instance, the goal of scrum is to produce a potentially releasable product increment in every sprint that often exposes the business to the “technical debt” due to past product development efforts that has not been paid off and lack of quality practices within software engineering.

Most of the organizations are not able to deal with these surfacing issues. As they don’t have a neutral party to facilitate their exploration and resolution, most organizations tend to ignore them or consider Agile/Scrum liable to create them.

One of the co-founders of Scrum, Ken Schwaber, states that Scrum holds a mirror up to the organization.

In case that mirror reflects back, an organization does not like and blames the “mirror” rather than looking at the objectively provided feedback and evaluating to address it.

Independent work

The scrum involves two concepts empowerment and autonomy and if a team is not functioning independently; there is a problem.  According to Michele Sliger, coauthor of The Software Project Manager’s Bridge to Agility and president of Sliger Consulting, it may be that team members don’t understand how to adapt their new roles. Most of the times, it’s an indication that a project manager does not want to give up control.

According to Sliger, ” The control freak project managers do not let go of decision making and give no control to the members of team.”

What is the result?

When the team members do not feel that they are in charge, they do not accept changes and revert to take orders and prefer to work within their comfort zones, taking them back to waterfall. “Giving ownership to the team will bring accountability,” according to Sliger. Your employees are likely to step back from responsibilities if they feel that they are doing what they are told and the attitude is like, ‘Not my circus, not my monkeys.”

What is the way to foster independence?

If you want the effective implementation of agile methodologies, empower your teams to work freely while relaxing them from constant checking of higher-ups or set them free to make decisions and changes. If the project manager can’t cede control, then agile and Scrum training may help them to adapt to their new role in Scrum.

Not implementing as directed

As Agile methods are framework-based; they provide the minimal set of artifacts, roles, and ceremonies essential to create a product frequently. The adoption of these methods allows people to add things to the framework that are beneficial to them. For instance, various teams often leverage practices from Extreme Programming (XP) like Pair programming or Continuous Integration. The additions are accepted because they help teams to become self-organizing that is important in agile.

Sometimes, organizations take advantage of freedom and compromise on the simple set of practices that Scrum advocates. Scrum necessitates on the need for a Product Owner who is knowledgeable, decisive and available to the team, but organizations mostly skip this as they find difficult to search for a suitable person with required skills. Scrum is a framework, and the organizations move forward adopting “Scrum” without a Product Owner. When they struggle, they don’t get the reason for their failure that why they are not realizing the benefits from it as in real they are not practicing it perfectly.

The solution to this struggle is to invest in experienced and dedicated Scrum Masters. A Scrum Master is an unbiased, servant leader who makes sure that Scrum team lives by the values and practices of Scrum. He/She removes impediments to progress, facilitate meetings, and work with the product owner to keep the product backlog in good shape and ready for the next sprint.

Conclusion

Agile is worth investing the effort and time in for your company. You just need to practice it correctly, and it will become easy to incorporate it into an existing company framework. A business can expect to have a bumpy road with some developers, and it remains for some time, and your business will soon realize its benefits after its proper implementation.

Working with Me Or Evolution4all

I have developed the Organisational Mastery” product. The aim of this product is to create a coalition that drives change and internal innovation alongside shared knowledge throughout the organisation. It’s extremely suitable for companies that want drastically improve the alignment between executive leadership and delivery teams.

ORGANISATIONAL MASTERY SCORECARD

We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.

Take The Test
Rate this post:
Danish Wadhwa

About Danish Wadhwa

Danish Wadhwa is a strategic thinker and an IT Pro. With more than six years of expertise in the digital marketing industry, he is more than a results-driven individual. He is well-versed in providing high-end technical support, optimizing sales and automating tools to stimulate productivity for businesses.

Comments

Share your point of view

  1. Agile is a good servant, and a bad master.
    In my experience, doing contract work for many large companies, those that purport to use Agile are actually running Agile inside a PMBOK/Prince2 framework. The reason is that real-world commercial operations can’t work without a deadline or a budget. Infinitely recursive development is fine, as long as you don’t care when the product becomes available, or how much it costs to produce.
    Further, having a fluid development team, where everyone can do everyone else’s job, is totally unrealistic, since programmers tend to specialise in their areas of expertise.
    However, the morning standup, the nightly check-in and morning test are useful, which is why these practices have been widely adopted.
    As for things like Pair Programming, I’ve seen this fail in every company that tried to adopt it, since it doesn’t take into account the psychology of programmers, who are individualists, and expect credit for their work. In every pair, one guy always has more expertise than the other, and does most of the work. During the process, there are always differences of opinion as to which direction the design should take, sometimes resulting in parallel development of ideas, which need arbitration on the part of the project manager, and wasted effort.

  2. Agile (Scrum) is the most polarizing methodology I’ve experienced in my 30 year career. There are components of SCRUM that are good. Daily standups are a great accountability tool. Everyone can be called to reckoning for what they’ve done (or haven’t) with their day.
    As a DBA/Project lead for mainframe applications, it is an unbelievable productivity killer for me. I typically have a very busy day. I frequently work nights, weekends, and occasionally on holidays and a couple times on vacation to get projects complete. My company doesn’t ask me to do this, but I take a lot of pride in my work and accomplishing tasks helps me to relax. Now I am part of multiple scrum teams. One in particular involves 4-5 hours of meetings per week (Backlog grooming, Sprint Planning, Retrospectives, Sprint Reviews) with 2 week sprints. I literally do 15 minutes worth of DBA work per week for a project that is taking 4-5 hours per week of my time. Bear in mind that I was already overloaded prior to getting the Agile Enema.
    The worst dressing down I have received in my entire career (I’ve been lucky to not receive much criticism in 30 years) was after meeting with 4 other project leads, where we all agreed Agile wasn’t a good fit for our mainframe project teams. We had been sent to scrum master training, and had about 1 year to try to work the process with our teams. I presented all 5 teams consensus at a managerial oversite meeting. While I was getting dressed down, the rest of the project leads suddenly developed laryngitis. I don’t blame them, it was obviously not going to be an open dialogue.
    I can see from the business users, analysts and managers perspective, Agile is a great way to over see the interactions of the entire team process. 2 of the sharpest people I know are both project manager/analysts, and they are very strong agile proponents. This reinforces my belief that Agile is good for them. But for developers and technical staff that are in the trenches working their tails off to get work done, it is like having someone toss you and anchor while you are swimming. The thought that I can get more done by spending many hours idle in meetings (instead of doing the work that has to be done), strains the very fabric of credulity. The only benefit I have experienced is that it is slowing our companies productivity down so much, that I don’t get nearly the DBA requests that I used to. But the part of me that still wants to feel that I have accomplished something at the end of the year, feels like it is being water-boarded. And I feel a strong responsibility to point out “The emperor has no clothes”.
    One other facet of SCRUM that I haven’t seen mentioned, is that we are all drawn to different aspects of I.T. Some are very analytical and like the structure, managerial, organizational and design aspects of I.T. Some are very technical, and are drawn to coding, debugging and the very technical aspects of our jobs. It is this diversity that lets our individual strengths complement each other, and makes us all fit together well as a team. But SCRUM forces us all into that 1st category. If you are technical and would rather solve problems than to write about them, you may dislike Agile. And since most management falls into that first category, SCRUM will continue to be adopted and forced on those of us that it hinders and torments.
    In the interest of full disclosure, I was recently diagnosed with ADHD. (at nearly 50 years old). And one of the symptoms is “lack of patience” Sitting in meetings that don’t pertain to me while I have work to do is honestly torture. I had to purchase a blood pressure cuff to help me identify when I am reaching my limits. My BP is 120 over 76 normally. But wasting time in an Agile meeting puts me into the stratosphere. I get throbbing head-aches as well that I had never in my life had before Agile. Just from being forced to sit and not being able to do my work.

X