For enquiries call:

Phone

+1-469-442-0620

HomeBlogAgileFailures in Agile Transformation

Failures in Agile Transformation

Published
19th Feb, 2024
Views
view count loader
Read it in
4 Mins
In this article
    Failures in Agile Transformation

    With the increase in Agile adoption across the organization, the stories are piling up too. Now the question is, are these success stories or the failure stances. Usually, in the conferences or meetups, you get to meet people from various establishments, this is just another way of getting to hear what worked or what not. Even in your own organization, you can feel the pulse of the transformation. There are many reasons why we end up with messy transformation, I have tried elaborating few in the discussion today but there’s more to it. As you read, you might connect with some of the points, let’s start the digging:

    1. AIMING ON PROCESSES AND NOT PEOPLE

    The inclination of Agile is more towards people or individuals, we talk about empowering team, making them self-organized. We even talk about creating high performing teams which can deliver maximum value by the end of every increment. With the adoption of Scrum, where the core values involve Focus, Openness, Respect, Commitment and Courage at the root level, the ‘people’ factor becomes important. Ultimately, it the ‘people’ who work at the ground level for client satisfaction, to achieve this, they adopt processes for smoother workflow. That’s it! Organizations, during their transformation, tend to overlook this critical piece. Their approach becomes more inclined towards processes and they start considering Agile as a process but in fact, Agile is more of a mindset change. Process starts getting priority over people or individuals, always remember, process is just for supporting or helping the individuals with their work. People are not for the processes, even one of the four principles in the agile manifesto says: “Individuals and Interactions over Processes and tools”. I was surprised to hear in one of the trainings’ that people in the same team are using mail to communicate around the stories/deliverables. Can we not give preference to face to face interactions?

    2. MICROMANAGING THROUGH CEREMONIES

    Self-organization is one of entities in Agile, the core says, trust your teams. Micromanagement not only hinders creativity, but it also impacts the morale of agile teams. Management or the scrum master should refrain from getting into the minute details during the scrum ceremonies. Most of the times, it is observed that the daily scrum gets converted into a status meeting either for the scrum master or for the technical lead. As a Scrum Master, you should help the team getting self-organized rather than being directive. One of the principles from Agile talks about giving the space and trust: “The best architectures, requirements, and designs emerge from self-organizing teams.” This enables the team to find their own solutions, helps them with innovation and most of all, teaches them the value of being a team. Every ceremony has its own schema and none of the ceremony is to track individual chores. You must trust your teams, remember, trust can do wonders, believe me, if you trust your people, they will never let you down. Here comes another principles’ focusing on the same. “Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.”

    3. Hastening the Transformation

    Any change, whether it is for the system or for an individual, takes time. When was the last time you promised yourself to change one of your habits, was that easy? Almost every individual at the start of the year takes so many resolutions, how many do you think gets accomplished! Same goes with the transformation, it takes time and you will have to give because it is not just about the individual, it is about the organization. When the transformation journey starts, the delivery teams take the maximum heat. They are the ones who are expected to be Agile BUT the management usually lags, they are still in need of mindset to support the change. Just by doing the agile ceremonies is not being Agile, it comes with a wide variety of shift, be it - culture, technical, management or team. You have to accept that it is going to be a challenging journey which will have its own milestones and you cannot skip those. Also, it is long journey with hiccups, be ready to accept the challenges, learn from the mistakes and come up with the action items to improve.

    4. Scrum Roles Getting a Back Seat

    When teams in agile are formed, some of the roles are asked to play dual. In such scenarios, scrum master roles can be played either by the team lead or by someone who is ready for that extra piece. Though the role gets played, but the essence of this position goes for a toss. The focus just stays on delivery without instilling the purpose.  The organisation needs to acknowledge that scrum master'sis a fulltime job that helps teams in staying on track, motivated and helps them see their own progress through information radiators. Anyone else playing a dual role might not do justice and end up walking on two different tracks - not able to reach the goal in both the positions. The team needs someone who can teach, mentor, train and be with them. Just forming the team is not enough if the organization doesn't follow the best practices, such cases tend to get trapped.

    5. Lack of support from Middle management

    In my past experiences with the organizations in transformation mode, usually the middle layer is where the problem brews. Transformations get a go ahead from the top layer, but it gets difficult for the middle management to adopt. It is important to ensure alignment among the leaders of the organization on the aspiration and value of the transformation is done before moving ahead with the approach. In another example we can see a project manager being insecure as most of the juggling is being handled by the scrum master. In such cases, to prove their existence, the middle layer starts getting into the little details, this impacts the team as half the time they are functioning as per the project manager. Due to this, we hear a lot about the role of scrum master being questioned on their responsibilities. They are assumed to be just sitting and watching, in other words, doing nothing! According to the research led by AgileTurkey.org in Turkey in 2018, the two major hindrances to agile transformation were found out to be the resistance to transformation and culture transformation. Existing managers have a lot to do in order to manage with these two major challenges, they should be part of the transformation beginning from themselves, their day-to-day actions, and should guide the whole company by being supportive of the process.

    6. Tools over mindset

    With the transformation comes the need to use fancy tools and abide by ‘laws of the tools. Some feel proud in using the costliest tool, some make it a point to introduce the tool being used by the competitor. But is it worth it? Transformation can be done using ‘MS Excel’, there is no set protocol for focusing on the tool. Though the tools play an important part, but teams should focus on Agility and Scrum framework first and then on tools. You certainly need to track metrics like velocity, burn-down, estimates. But with the right mindset, the goal can be achieved with no trouble. This doesn't mean tools are bad, but it means mindset should be given priority over the extensive use of tools.

    7. Transformation as a Destination (Thinking Your Transformation Is Done)

    Many a time, we hear ‘We are now agile, we transformed in so and so year’ and what not. But is agile a destination, NO, it a journey, a never-ending journey. Some teams think just by implementing a bunch of backlogs, doing the ceremonies and tracking metrics, they are Agile. No, they are not!

    Whatever way out we have today are based on our experience, knowledge and the situation we are in. If any of the factors change, our solutioning will be different. Both the values and principles of the Agile Manifesto point to the continuity of the process. Responding to change over following a plan relates appropriately as much to the processes as to our sprint outputs. We have to understand that process is never whole. You just have to continue reflecting what worked and how to fine tune the process whenever required.

    8. Misunderstood cross-functional team

    Every time I speak about the delivery teams, at least one of the participants from the audience ask this question “We say it's a cross functional team, but my tester is not ready to code!” Have we understood it correct? None of the processes are bad, it is about how we adopt them that makes a difference. “Cross Functional Doesn’t Mean Everyone Can Do Everything, a cross-functional team has members with a variety of skills, but that does not mean each member has all of the skills.”  – Mike Cohn. This interpretation of cross-functional imposes a pressure on the delivery team which breaks the team apart and is sometimes the cause of conflicts among the members. As per scrum guide – “Cross functional teams are groups consisting of people from different functional areas of the company. – it should be formed not only with technical specialists (Back-end, Front-end developers, QA engineers, etc.), but also consists of member like Business Analysts, Marketing and UX specialists or anyone else taking an active part in the project.”

    9. Scrum for All

    Just because everyone is going that way doesn’t mean that way is for you too! It is necessary to understand the current and what exactly you want it to be once the journey starts.  Scrum is one of the frameworks to help with complex adaptive projects, but it is not for all the products or projects. If you are transforming your IT helpdesk department, scrum might come out as a failure, the support team cannot say that they will be delivering 10 high priority tickets after the end of sprint, where sprint duration ranges from two week to a month. Second scenario can be the team handling production defects. But this does not mean that Scrum is bad, no it is not. It is just that these scenarios are not meant for Scrum.

    Every story is different and so are the reasons, as said earlier as well, this is not just a complete list, there can numerous other details depending on the situation. I will be happy to hear your viewpoints on the misalignment and disorientation. Lastly, it is significant to focus more on the people, the mindset and the collaboration to get better results.

    Profile

    Deepti Sinha

    Blog Author

    Deepti is an Agile Coach by profession and Freelance Trainer with over 11 years of industry experience working primarily with healthcare & finance clients in delivering business. She has played a wide variety of roles in the graph of her career, whether it be, management, operations or quality. She likes reading fiction, management and loves to write her experiences. Her colleagues mostly describe her as very detail oriented person with a knack of creativity and imagination. And yes, she loves feedback more than her coffee!!

    Share This Article
    Ready to Master the Skills that Drive Your Career?

    Avail your free 1:1 mentorship session.

    Select
    Your Message (Optional)

    Upcoming Agile Management Batches & Dates

    NameDateFeeKnow more
    Course advisor icon
    Offer
    Whatsapp/Chat icon