Agile Transformation in IT-organizations

• Involve the customer. Your project customer and stakeholders should be involved in all phases of the development. They will help to design and implement a system that will meet their needs closer. Moreover, the stakeholder may change their opinion about the system and give new requirements. As a Project Manager you should meet the changes with pleasure because after all your customer will be satisfied.

Waterfall is based on a logical sequence of steps that must be taken throughout the software development lifecycle. Each stage is coordinated by competent employees, documented and passed on.

Although the popularity of the Waterfall model has waned in recent years, but the nature of the sequential process used in the waterfall method is intuitively close to developers.

The model proposed by Dr. Royce is extremely simple and clear. It consists of several blocks, each of them covers its own area of responsibility.

Let's look closer at the difference between Agile and Waterfall methodologies.

In management, there is a concept of a project management triangle14:

It includes the amount of work, time and quality. It is important to note that the balance in any methodology is created due to a system of assumptions, so in cascade approach quality can be reduced, and in Agile the amount of work can easily grow.

The project management triangle clearly displays the so-called triple limitation problem associated with the need to balance the scope of the project, its cost and time for implementation without compromising the quality of the final product. Taking into consideration the concept of project management triangle, the difference between approaches will look like this:

In recent years, the waterfall model has been losing its leading position to more flexible methodologies. This is due to the general dynamics in IT, when teams of 5-9 people are responsible for software development, and the deadline can be easily shifted due to the increase in functionality.

Nevertheless, the cascade model is still relevant for large projects and organizations:

• It is resistant to personnel changes. Developers can come and go throughout the life cycle of the project, but thanks to detailed documentation, this practically does not affect the timing of the project;

• Waterfall model forces developers involved in the project to be disciplined and to stay within the plan. If necessary, a management body responsible for decision-making is added to the general model, while performers are required to work within the system framework15;

• Flexibility in the early stages. Changes in early phases can be made immediately and with minimal effort, since they are not backed up by code. Thus, the customer and the contractor have a significant time margin for a radical change in the concept of software work;

• Focus on deadlines and finances. Due to the fact that each stage completely outlines the contour of the future software, all developers understand their role, the boundaries of work and deadlines. This allows you to cooperate with the customer knowing the real cost of development and makes, therefore, the project model attractive.

In the 1970s, Royce's ideas were relevant. But after almost 50 years, the cascade development method is less and less suitable for IT:

• non-adaptive software structure. At the first stages, the waterfall model can be flexible, but if problems in the overall structure are identified during the testing phase, this entails deplorable consequences in the form of disrupted deadlines and even customer failures;

• ignores the end user. The lower the process progresses in the waterfall, the less the role of the customer in it, not to mention the users he represents. Making any changes to the functionality of the software starts the entire chain of stages anew, so the products obtained by the cascade model are far from targeting the mass user;

• later testing. It is here that mistakes made at each of the stages are most often identified. More flexible methodologies use testing as a fundamental operation that occurs continuously. Waterfall, on the other hand, admits low qualifications of employees at each stage and poor quality of execution, because with late testing, problems cannot be solved fundamentally, only with the help of "patches".

Let's fix both approaches pros and cons:

Everything seems to be transparent, but in practice the question often arises which methodology to apply in each specific case. This scheme helps us mostly to make the right choice:

It turns out that the cascade methodology is an excellent solution in terms of deadlines and reporting, but very weak in terms of quality.

Despite the fact that these 3 points are increasingly rare in real practice, the cascade model will be popular and in demand for a long time because of its clear organization. This means that any professional developer should understand its basic principles and be ready to exist within the framework of this approach.

LET'S SUMMARIZE WHAT WE’VE LEARNED IN THIS CHAPTER:

Agile and Waterfall are the most common but opposite to each other software development approaches. While commending the waterfall methodology, it is necessary to move forward and look ahead, addressing contemporary challenges here and now. Agile is just what you need for this. We have also learned, that:

• software development methodologies should be evaluated using project management triangle;

• Agile methodology gained great popularity and changed software development forever by now;

• Waterfall or Cascade methodology is still in demand, so developers should be ready to exist within this approach.

CHAPTER 3. IMPLEMENTING AGILE APPROACH IDEAS INTO PRACTICE. LET'S BREAK DOWN THE INSTRUMENTS AND TECHNIQUES

Let’s look at frameworks that are used to implement Agile Approach ideas into real practice, but first let’s explain what a framework is.

Framework is a ready-made set of tools that helps the developer to create a product quickly: a website, an application, an online store, a CMS system.

Imagine that you decided to assemble a toy car: it should drive and look almost like a real one. Obviously, there are several ways to solve this problem:

• the car can be assembled independently, from scratch: create all the parts manually or with machining equipment, do electronics and electrics, paint everything. So you can control the whole process, but it will take a lot of time;

• a similar car can be assembled from ready-made kits: body parts, engine, electronics will become modules that are important to choose and connect correctly. If desired, you can improve any module, but generally this is not necessary, everything will work right out of the box.

The framework is the same ready-made set, only for the developer. It saves the time and effort of a specialist who would have spent on creating basic things and correcting simple mistakes.

The most common Agile framework is Scrum.

Scrum is a set of rules allowing the team to establish a flexible workflow. Development is carried out in iterations, the goals of each iteration and the tasks of each team member are clearly outlined. Due to Scrum, companies can apply the principles and values of Agile and work on projects of any complexity. Agile and Scrum concepts are regularly confused, considering that Agile and Scrum are the same.

The difference lies in the scale of two approaches: Agile is a special way of thinking, a mindset. Scrum is an instruction for use. A clear plan describing each step of Agile implementing in product development. This is a methodology with specific stages, in which roles and events are clearly defined.

Scrum is based on empiricism and lean thinking.

EMPIRICISM asserts that the source of knowledge is experience, and decision-making is based on observations. Lean thinking reduces losses and focuses the main.

Scrum uses an iterative-incremental approach to optimize predictability and risk

management. It involves groups of people who collectively possess all the skills and experience to do the job, to share knowledge and acquire the necessary skills as needed.

Scrum combines four formal events for inspection and adaptation into a container event – Sprint. These events work well because they implement the empirical pillars of Scrum: transparency, inspection and adaptation.

TRANSPARENCY: the emerging process and work should be visible both to those who do the work and to those who get results. Important decisions in Scrum are based on an assessment of the state of three formal artifacts16. Artifacts with low transparency can lead to solutions that reduce value and increase risk. Transparency makes inspection possible. Inspection without transparency is misleading and is a waste.

INSPECTION: to identify potentially undesirable deviations and problems, it is necessary to regularly and thoroughly inspect Scrum artifacts and progress towards achieving agreed goals. To help with the inspection, Scrum provides a cadence17 in the form of five events.

Inspection makes adaptation possible. Inspection without adaptation is considered meaningless. Scrum events are designed to provoke change.

ADAPTATION: if any aspects of the process go beyond acceptable limits, or if the final product is unacceptable, the process used or materials produced must be adjusted. The adjustment should be made as soon as possible to minimize further deviation. Adaptation becomes more difficult when people involved do not have authority or are not self-governing.

A Scrum Team18 is expected to adapt the moment it learns something new during an inspection.

SCRUM VALUES

The successful use of Scrum depends on how much people share its five values: commitment, focus, openness, respect and courage.

A Scrum Team is committed to their goals and supporting each other. Their most important focus in working at Sprint is the maximum possible progress in achieving goals. The Scrum Team and stakeholders are open to discussing work and challenges. Scrum Team members respect each other as professionals and independent people, and in the same way they are respected by the people they work with. Scrum Team members have the courage to do the right thing and work on solving complex problems. These values set the direction for the work, actions and behavior of the Scrum Team. The decisions taken, the steps taken, and the way Scrum is used should reinforce these values, not weaken or undermine them. Scrum Team members comprehend and discover these values while working with Scrum events and artifacts. When these values are brought to life by Scrum Team members and the people they work with, the empirical pillars of Scrum – transparency, inspection and adaptation – come to life, building trust.

SCRUM ROLES19: TEAM (DEVELOPERS)

The main unit of Scrum is a small team of people, a Scrum Team. A Scrum Team consists of one Scrum Master20, one Product Owner21 and Developers. There are no subcommands or hierarchy inside the Scrum Team. This is a close association of professionals focused on one goal at any time given – Product Goal.

Scrum Teams are cross-functional22, meaning their members have all the skills needed to create value in each Sprint. They are also self-governing, that is, they decide who does what, when and how. A Scrum Team is small enough to stay agile, and large enough to do significant work during a Sprint – usually consists of no more than 10 people. Overall, we found that small teams communicate better and are more productive. If Scrum Teams become too large, participants should consider reorganizing into several cohesive Scrum Teams, each focused the same product. Therefore, they must have the same Product Goal, the same Product Backlog23, the same Product Owner.

A Scrum Team performs all product activities: cooperation with stakeholders, verification, maintenance, operation, experiments, research, development and all that may be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a steady pace improves the focus and consistency of the Scrum Team.

The whole Scrum Team is responsible for valuable and useful Increment creation in every Sprint. Scrum defines three responsibility zones in the Scrum Team: Developers, Product Owner and Scrum Master.

Developers are the people in the Scrum Team who are committed to creating any aspect of a ready-to-use Increment in every Sprint. The specific skills needed by Developers depend on the subject area of the work being done and can be very different. However, Developers are always responsible for:

• creating a plan for Sprint - Sprint Backlog24;

• striving for quality through compliance with the Definition of readiness (Definition of Done)25;

• daily adaptation of your plan to achieve the Sprint Goal;

• mutual accountability to each other as professionals.

SCRUM ROLES: PRODUCT OWNER

A Product Owner is responsible for maximizing the value of the product resulting from the work of the Scrum Team. The ways to achieve maximum value can be very different and depend on organizations, Scrum Teams and specific people. The Product Owner is also responsible for the effective management of the Product Backlog, including:

• Product Goal developing and accurate communicating;

• Product Backlog elements creating and explaining;

• Product Backlog elements organizing;

• Product Backlog transparency, accessibility and understanding providing.

A Product Owner can do this work himself or delegate it to other persons. However, Product Owner remains responsible for it. In order for Product Owners to succeed in this, the entire organization must respect their decisions. These decisions are reflected in the content and order of the Product Backlog elements, as well as in the Increment being inspected during the Sprint Review26. A Product Owner is one person, not a committee. The Product Owner can reflect the needs of many stakeholders in the Product Backlog. Those who want to change the Product Backlog can do this by trying to convince the Product Owner.

SCRUM ROLES: SCRUM MASTER

A Scrum Master is responsible for applying Scrum in accordance with Scrum Guidelines. They do this by helping everyone understand Scrum theory and practices, both within the Scrum Team and organization. The Scrum Master is responsible for Scrum Team effectiveness, helping the Scrum Team improve their working methods within the Scrum framework. Scrum Masters are true leaders who serve the Scrum Team and entire organization.

A Scrum Master serves the Scrum Team in several ways, including:

• advising team members on self-management and cross-functionality;

• helping the Scrum Team focus on creating Increments with high value that meet the Definition of readiness;

• helping to eliminate obstacles that hinder the progress of the Scrum Team;

• making sure that all Scrum events occur, are positive, productive and do not go beyond the time limits.

A Scrum Master serves the Product Owner in several ways, including:

• helping to find techniques for effective Product Goal detection and Product Backlog management;

• helping the Scrum Team realize the need for clear and concise Product Backlog elements;

• helping to apply empirical product planning in a complex environment;

• facilitating interaction with stakeholders upon request or if necessary.

A Scrum Master serves the organization in several ways, including:

• directing, training and advising the organization in Scrum application;

• planning the transition to Scrum and advising on Scrum application within the organization;

• helping employees and stakeholders understand and apply an empirical approach to complex work;

• removing barriers between stakeholders and Scrum Teams.

SCRUM EVENTS

Sprint is a container for all other events. Every event in Scrum is a formal opportunity for inspection and adaptation of Scrum artifacts. These events are specially designed to provide the necessary transparency. Failure to conduct any of the Scrum events in accordance with the description leads to a loss of opportunities for inspection and adaptation. Events are used in Scrum to create regularity and minimize the need for meetings not defined in Scrum. A good practice of reducing complexity is to hold all events at the same time, in the same place.

SPRINT

Sprints are the pulse of Scrum, where ideas turn into value. This event has a fixed duration of no more than one month to ensure consistency. A new Sprint starts immediately after the completion of the previous one. All the work needed to achieve the Product Goal, including Sprint Planning, Daily Scrum27, Sprint Review and Sprint Retrospective28 events, is done within Sprints.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

Waterfall methodology, also called cascade or waterfall, is a classic model of the software development lifecycle.

2

Combination of both iterative and incremental software development methods when the development progress is achieved by short time periods (iterations), each of them delivering an increment to the product development process.

3

Approaches to software development based on the cascade model, with clear sequential stages, and comprehensive documentation.

4

Approaches to software development based on the iterative incremental method.

5

The most common and popular Agile framework.

6

A short time period during which a scrum team performs a given amount of work.

7

A short meeting from 5 to 20 minutes a day, at which team members tell share what is happening in their work tasks.

8

The meeting that starts each sprint, and is intended to determine the team's work plan throughout the sprint.

9

This is a software testing method by which individual units of source code are tested to determine whether they are fit for use.

10

This is a product management method in which you develop a strategy for its phased release.

11

The product or service test version with a minimal set of functions (sometimes even one) that delivers value to the end user.

12

A person or an organization that has rights, interests, requirements or interests regarding the system or its properties that meet their needs and expectations.

13

The information systems creating concept, including their planning, development, testing and deployment.

14

This is a model, illustrating the three constraints interdependence: time, money and scale, as well as how changing one factor requires changing others.

15

A ready-made set of tools that helps a developer to quickly create a product: a website, an application, an online store etc.

16

This is the information with which the Scrum team and stakeholders describe in detail the product being developed, as well as the actions to create it and the activities within the project.

17

An Agile cadence is a reliable series of events and activities that occur on a regular, predictable schedule.

18

This is a small group of people, within which there is no hierarchy, mini-teams or leader and all participants work on the same goal.

19

A Scrum team participants’ roles.

20

A Scrum role which does not imply anything other than the correct Scrum process conduction. Thus, the Scrum master is the server-leader of the team.

A Scrum role, a person responsible for the product creation and

management. (S)he monitors its development process, records the necessary

metrics and is responsible for the result.

21

A Scrum role, a person responsible for the product creation and management. (S)he monitors its development process, records the necessary metrics and is responsible for the result.

22

A team that has all the skills necessary to do the job and is independent on those who are not part of the team. Cross-functional Teams are more flexible, creative and productive than teams where people are specialized in one competence to do their job.

23

An ordered set of elements, a queue of tasks, a list of all the functions that you want to get from the product. This list contains brief descriptions of all the product features desired.

24

A list of specific tasks to implement the product backlog selected elements.

25

This is a list of process and increment conditions under which the backlog item can be considered done.

26

The meeting at the end of each sprint intended to present the product developed by the team during the sprint.

27

This is a Scrum meeting, one of 5 Scrum events, that lasts no longer than fifteen minutes and is held every working day in the same place at the same time.

28

This is a workshop which is held to discuss how to improve the workflow.