#kendis

When companies start to scale agile, fear looms over the company as to how they will make it happen. This fear is in the form of myths and speculations that often scares companies to becoming agile.

But with time and the evolution of newer technologies, agile and its processes have ceaselessly matured. Proving that the problems with scaling agile are nothing but figmental now. In this article, you will read about what the 7 myths about scaling agile are and how you should stop believing them.

1. There is no discipline in agile

Agile is highly disciplined when it comes to delivering. You have to make sure that you are consistently and continuously testing, getting feedback, shipping software on the deadlines and changing and updating the plan when needed. All of this needs hard work and coordination to achieve success. This cannot be achieved without the dedication, support and commitment from the teams and the management.

The driving force behind Trump’s election campaign was Agile, which evidently made him President. To learn more, click here.

Now that you know that agile has discipline, scaling can easily be practiced. It may seem complex but once you have a clear understanding of the core agile values and the fundamentals of this process, scaling is not a difficult task.

Tip: Agile coaches and transition experts assist companies in tailoring the process according to their specific needs.

2. Agile teams cannot Scale Up

That is not true. Countless enterprises have transformed by scaling agile to produce reliable and higher quality products. In a market where the competition is extremely fierce and where every company battling out to be the best, scaling has become quintessential.

Famous scaling frameworks like SAFe, LeSS, Spotify Agile Model and Nexus are proving to be very popular and in fact beneficial for a company’s success. The purpose of these frameworks is to guide in building a structure that lets the companies to delivering and reacting faster to any change with improved collaboration.

3. Scaling brings organizational friction and financial loss

Looking at the history of digital revolution, businesses have been often skeptical to adapting to scaling agile. And the reason for that they had to face issues in the form of organizational friction and resulted in a financial loss. But it was with perseverance and steadfastness that these businesses thrived and kept on scaling to produce phenomenal results.

The reason for their success was that these companies were good at defining company vision, analyzing their need to adopt of scaling by considering its challenges and advantages. They were ready to adjust and respond to the change that came their way.

A comprehensive study at Harvard on ING bank describes the key success factors of Agile at Scaling. It mentions that sequence of rolling out the plan is the key.

4. You need to stop working with your current ALM tool

Once agile teams start using an ALM tool that suits their preference, they become content with it. But when the business starts to expand, companies look for a tool that assists them to plan multiple releases and track work item dependencies. This is when they need an agile scaling tool that fetches data from their ALM tool, so they can utilize it efficiently to scale.

Earlier scaling tools were tightly integrated with only ALM tool that was developed by the same software provider. But now, scaling tools are very capable of integrating with the existing renowned ALM tools. So there is no need for the agile teams to switch to another tool. Hence seamlessly managing their program efficiently using a scaling tool of their choice.

5. Dependencies cannot be visualized with the tools

The higher the amount of dependencies, the higher the chances of the program becoming complex.The dependencies at the architectural design level can be described with the help of different tools. But when it comes to describing work items dependencies, then the usual solution is worksheets.

For visualising dependencies at a higher level, physical whiteboards did the job. The board would be covered with a red web spanning across the entire board mapping out the dependencies. But it was difficult to know the latest change that was made.

But now new scaling tools have made it simple for visualizing the dependencies, enabling individuals to make accurate and quicker decisions by using the latest data.

6. Program Releases have no deadlines

Quite the contrary. Agile teams work best in defined release cycles.

The release schedule of all the projects in a program are known to all the team members and the management. Each team can push their work in a planned release. With the enhanced use of continuous integration and DevOps, each team can deliver the feature as soon it gets ready.

If there is a dependency between two team work items, then the teams still can define a way to deliver. Learn, how Spotify resolved their dependent feature releasing.

7. You do not need a program level architect

Many consider a program level architect an obsolete position. Not exactly.

In a company, the program level architect is responsible for the infrastructure, technical strategy, and the evaluation of the business needs in terms of technical stability. They create a design that keeps the long term vision in mind. The architect doesn’t necessarily enforce the design but to guides the teams in such a way that it does not disturb or alter the vision kept for the organization, even if the requirements change. A program level architect plans and synchronizes the program architecture runway with the agile team requirements and manages technical dependencies.

If the project level system experts, or architects meet to discuss the vision, system design, security, tools or platforms then the program architect may act as the scrum master.

How Kendis poses a solution to all the myths about scaling agile?

Agile Scrum works best with small teams that work to deliver software which is prioritized by the team backlog. It is then built in iterative models with sprints by having the highest priority items implemented first. Agile execution works best in small teams. But when it comes to managing large organizations, it becomes difficult. Thus enterprises are adopting agile execution techniques to maximize success. The waterfall model can be easily scaled to become Agile.