Why would you need Agile?

You need Agile to develop an IT project which, on the one hand, can be exciting, new interesting experience, creative realization and independence. Everything that drives the team to create. On the other hand, to make your project properly, you will have to invest a lot of time and effort. Stories about successful newcomers and geniuses, who achieved everything at once, embellish reality so that people would listen to these stories. These are stories about Cinderellas, who married princes after a dance party, or teenagers who invested their pocket money in stocks that made them millionaires overnight. There is luck in life. For example, you can win in a lottery. But, as life shows later, this success does not change anything in the values and lifestyle of the winner. Therefore, if you want to conquer peaks, you have to plan the conquest. Agile is an approach to developing an IT project that adresses important features of development. I'll lay out some of them, to explain the importance of Agile.

Distinctive features of IT development

The diagram on the left shows two types of processes that require two different types of management: process-oriented and competence-oriented. Conveyor output (marked in blue at the bottom left), for example production of packaged milk, is notable for having very clear requirements for its product. If the package of milk that says "1 liter" contains 0.9 liter, the buyer will be very unhappy. On the contrary, getting a pack of 1.1 liter at the price of 1 liter, the buyer will be satisfied, but the manufacturer will lose profit. It is also desirable that the milk always has about the same colour, taste and smell. If the milk suddenly starts smelling like roses, the buyer will be as unhappy. What requirements should we suggest for the milk? These requirements should aim to unify the production process by describing it as clearly as possible. So that the more precisely the manufacturer meets these requirements, the better the product turns out. And "better" means "meeting the demands and expectations of buyers".

Constructing a house is different from producing milk as concerns the price of change. If a manufacturer decides he or she wants to see green meadows instead of a cow on a pack of milk, they will pay some money to the designer and buy less black and more green ink for the printer. There are extra-costs, but they are conceivable. If we lay the foundation for a five-storeyed building and then decide to add another couple of storeys, our never-ending construction will soon hover above the city center, gaping with its empty windows. Introducing a change to production of buildings is much more expensive and should meet a lot more requirements than production of milk.

Now let's look at IT products, whether it's a website, an app, or a program. If we are not talking about developing a whole package of tools or, heaven forbid, a new operating system, then in terms of price, it’s about the same as a pack of milk. Today, everyone who uses the Internet can make websites at website builders. There are even shareware application makers and online databases. However, let's imagine that we have two cheese factories that are fighting for leadership in their block: do these cheese factories need a website that looks exactly like competitor's, as milk in one pack tastes like in another? This is where the vagueness of demands begins. You have to make a selling website. (Although sometimes milk manufacturers lay as much importance on images of meadows and cows.)

What kind of website is called selling? To figure it out, you sign up for a webinar about selling sites, study works of Dale Carnegie and the biography of Steve Jobs, remotely get a Master of Business Administration (MBA) degree, and eventually become a certified specialist in selling sites, but you still can't express what they are in one clear and brief definition. This is the vagueness of demands as concerns IT products. At the same time, if a customer suddenly wants you to make the background on your selling site not yellow like cheese, but blue like the sky in may, one click.. and the colour changes. Of course, first you need to pay a certain sum to the web-designer, so that he or she would capture that very shade of blue, just the right one, the selling blue (or, maybe, red?). But the price for this service is conceivable.

How can we manage the production process under conditions of vague demands? This is where the competency-based approach enters the scene: you need a team in which each person is valued for their unique competencies and is equally responsible for the result. Such a team usually does not need strict demands and heavy sanctions if they change something (like blue color to red). How does one become an expert in the field of "selling websites"? One absorbs the skill and mastery of gurus and eventually forms a certain inner competency that is difficult to express in a clear definition (but is easy to certify). Like a sponge or vessel, one carries the author's (original, artisitc) ability to select the selling colour. For this, one is valued in the team and paid a salary. However, most likely, the salary will also be vague: you will have to be convincing, to be able to prove that it was for your designer colours that the cheese factory thrived.

What about Mars? The principle is the same as with the sites, but you will have to be as convincing as Elon Musk.

Competency-based management in Agile

Managing teams in Agile is not the same as managing a conveyer, but such teams also need management. Agile is based on the principles expressed in the Manifesto for Agile Software Development:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

So, on the right, we have a plan, contract, tools, documentation. These are serious, important things that are carried in leather folders, signed and stamped. A step to the side from the plan leads to courts, fines and avoidance of the contract. You can't create a selling site in such conditions, but you still need to rely on something. And here other values come to the fore, flexible and vague soft skills: the ability to communicate and be persuasive, presentation skills, diplomacy, flexible thinking and no fear of change. Serious and important things remain with us, although they have now been sidelined. Because the salary still needs to be expressed as a positive integer, and the site still needs to sell before the competitor takes over the market. The main thing is that the chosen approach should be flexible.

But how do you plan such a complex activity, in which much depends on soft skills? First, Agile is not for large teams: if you have 5-7 people, or 10-11 at most, then somehow you will have time to agree by the deadline. A small group of people should be able to do it with sufficient motivation and a reasonable deadline. Second, Agile is done in sprints. Imagine that on a running lap, all the team members stand behind the line and start at the signal. A sprint is a race that lasts for a certain period of time. Usually, sprints in IT last from one week to a month. When everyone has reached the finish line, the stage of preparation for the next race begins. That's why in Agile, it's very important to have staff meetings, briefings and assemblies before each sprint, where three main questions are posed: What was done? What's left to do? What are we doing now? This approach to planning has led to the popularity of Kanban boards, which organize the answers to these questions in three columns.

By the way, "reasonable" in relation to "deadline" is the same as "selling" in relation to "site". No one can tell you with absolute certainty that your deadline is reasonable. You just know it.

Kanban board

Third, in Agile, everyone is the developer of the project and is equally responsible for the result. Usually there is no point in looking for who is to blame for the client's rolling eyes. In milk production you can simply fire an employee who drank 0.1 liter from each pack and because of whom the store received packages of 0.9 liter. In Agile each participant is too valuable. Everyone brings in their unique contribution that no one else can replace. Everyone has invested in the project equally. And that is what makes the project so unique. Hence, whenever something goes wrong everyone is responsible. There are no other clear roles in Agile teams, except for two: a product owner and a scrum master.

The product owner represents the customer's interests in the team. He or she communicates with the customer and strives to achieve the desired final result, the main idea of the project. The scrum master is a manager with special characteristics. The term scrum came from rugby. Imagine a crowd of players who at the whistle have rushed at each other in a fight for the ball. At this moment, one player is not participating in the fight, but is running somewhere in the direction of the opponent's gate. Suddenly, a ball flies out of the crowd and goes straight into the hands of this player. Moreover, the player is running almost without looking back, confident that he will catch the ball at a specific point on the field at the right time. The key task of the scrum master is to organize the team so that all players know what, where and when will happen during the sprint. Teamwork is the result of the scrum master's work. The rest of the people in the team are developers; and the product owner and scrum master can be developers, too.

How to find out that you and your team Agile:

You are not many. You are all equally responsible for the result, and each of you has unique competencies.
You actively use soft skills, communicate a lot, try different options and tools.
You work in clear time periods (sprints) and hold meetings before each of them.
You are using a Kanban board or something similar.
Each of you is a developer of the project.
The team has a product owner and a scrum master.

Acknowledgments. I would like to thank Veniamin Kizeev and Artem Chaptsov for their tutorials on Agile at the advanced training course "School of academic excellence" (Tyumen State University, autumn-winter 2018-2019).

You can read about Agile in Mike Cohn's book "Agile Estimating and Planning". Or, here is a good website.

Page updated

Google Sites

Report abuse