Алиса Бобовникова - Agile Transformation in IT-organizations

Current market conditions stimulate organizations to introduce innovative product improvement solutions. Environment changes responsiveness became an important factor in market competition. This trend is especially typical for the IT industry as this field is characterized by a lot of innovation. Transforming companies find it difficult to adapt to continuous change. This is often caused by lack of organizational flexibility and changes responsiveness practice. In order to address this issue, companies need to continuously search, evaluate, analyze and develop new tools for organizational culture.

This narrative is for those who have chosen the path of transformation to gain speed, flexibility and effectiveness. We will talk about how to improve the team’s effectiveness with agile techniques and also give you an idea how to start changes and how to measure them.

Chapter 1 discusses the approach to understanding agile methodology and its main provisions. Special attention is paid to the relationship between the type of thinking and the team effectiveness. Continuous customer focus and the need for regular teams’ interaction is revealed from practical examples.

Chapter 2 reflects agile management features and waterfall approach, which is also considered classic. This chapter provides these methodologies comparative analysis, highlighting distinctive features and opportunities for their use.

Chapter 3 describes agile transformation stages, most common agile frameworks, their distinctive features as well as their pros & cons.

Chapter 4 provides an overview of the main existing agile methodologies with implementation examples, as well as a step-by-step agile implementing roadmap also considering agile driven project documentation required.

Chapter 5 and Chapter 6 describes agile implementation effectiveness assessment methods, analyzes direct and indirect implementation process metrics as well as the technique implementation success criteria in different companies’ practice, and provides key agile project’s KPIs.

Chapter 7 is dedicated to the agile transformation challenges and explanation what agile coaching is, describing Agile coaching levels and tools as well as how coaching can help you with transformation.

The narrative is filled with living examples of companies implementing transformation in the IT sphere. Thanks to organizations’ practice, we deliver experience that can be useful for you along this difficult path. New management practices introduction in an organization is a way that requires changes not only in actions but also in attitude. We hope you will follow this path with us.

In 2021, the Agile Manifesto celebrated its 20th anniversary. The approach originated as a revolt of developers against clumsy IT corporations.

Let's figure out what Agile is, learn something from its history, and what is its difference from other software development approaches. We will also dive into some of the Agile frameworks, find out which option is most suitable for you, and what Agile coaching is, so this knowledge will allow you to apply it in your team or company.

The material may be useful and informative for wide range of specialists dealing with software development: front-end and back-end developers, DevOps specialists and software architects as well as for team leaders, project managers, product owners, CTO’s, CPO’s etc.

To begin with, let’s recall some facts. In 1970, Dr. Winston Royce issued the document that defined Waterfall1. Probably it was already being done by others at that time, but it is considered now to be definitive. He marked 5 principles that must be added to reduce most of the risks of doing waterfall:

• program design comes first;

• document the design;

• do it twice;

• plan, control, and monitor testing;

• involve the customer.

Dr. Royce’s last lines about waterfall were:

“[This] summarizes the five steps that I feel necessary to transform a risky development process into one that will provide the desired product. I would emphasize that each item costs some additional sum of money. If the relatively simpler process without the five complexities described here would work successfully, then of course the additional

money is not well spent. In my experience, the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed.”

In other words, Dr. Royce suggested writing a lot of documentation, handling risks, repeating some stages several times. The result was a heavy, in contemporary opinion, waterfall model. In an ideal world, we would go through all levels of this system from top to bottom, like a waterfall flows, and in the end we would have a good system.

The waterfall development model quickly gained popularity in the West, and the vast majority of software development teams applied it some time ago.

Currently, Royce's name is strongly associated with the cascade methodology, while few recall that he criticized this approach, pointing out that the software development process should not resemble the conveyor line operation. IInstead of waiting for all the steps (phases) to be completed, Royce suggested using a phase-based approach with a short completion cycle of 1-2 weeks. Its essence is that initially all the requirements necessary for the project are collected, then divided into sub-projects, the target architecture is developed, the design is created, code is written in short iterations etc. The waterfall model may have

concretized and formalized the development methods existed, but it was not without its drawbacks.

Due to traditional cascade methodology imperfection, clumsiness and heaviness developers at that time already experimented with so called “iterative-incremental” approach2, which gave them increased development flexibility based on regular feedback from customers and users.

The main idea of this method is to develop the system iteratively using repetitive cycles at smaller time periods (incrementally), allowing software developers to take the advantage of what was learned during the earlier parts or versions of the system development. Learning occurs both in the development and use of the system, where possible key process steps begin with the simple implementation of a subset of software requirements and iteratively improve the evolving versions until the full system is implemented. At each iteration, design changes and new features are added.