Scrum and Agile for Dummies

To start. Scrum and Agile - what's the difference? In short, Agile is a philosophy, a family of flexible approaches to software development. Scrum is one such approach. He has a brother - Kanban. It is also the approach used in Agile.

Elena Truskova says:

This week, I took a two-day Agile/Scrum training (pronounced "agile" and "scrum"). A lot of abstruse and not so literature has been written on flexible software development methodologies, I read a lot. But only after two days of immersion in the topic did I finally have a basic understanding of the subject from which I am writing this note.

Agile and Scrum help organize the process of teamwork in such a way as to release a product that is interesting to the user regularly and often.

In some banks, thanks to agile, the path of an idea to users was reduced from two years to six months - in other companies, a six-month development cycle was compressed into three. In these hectic times, this is a true competitive advantage, especially for smaller players.

Scrum principles can be applied to absolutely everything: for example, to work on a creative product. This, of course, is not “canonical agile”, Scrum evangelists will grind their teeth, but your processes will move more cheerfully. Checkers or go?

Some of Agile and Scrum can even be taken into individual work. Ensure regular publication of posts, measure the load on the performer, evaluate future tasks in terms of time and do not forget to analyze the quality of the work done - look, everything has already been thought of for us. It remains to implement.

Agile

(English agile - "agile, smart, quick-witted")

Flexibility concept:

Substitute your type of activity instead of the word "development" - and these principles will become close and understandable.

“A working product is the main indicator of progress”, “simplicity as the art of minimizing unnecessary work” and “people and interaction are more important than processes and tools” - does it sound reasonable?

Scrum

(eng. scrum - crush in the fight for the ball in rugby)

It is worth recalling here that this is my personal and subjective point of view on Scrum. Here I reflect on the applicability of Scrum elements both in creative projects far from IT, and in individual work (say, on a blog). Many precise details for this will have to be omitted; I try to keep the text simple and not overfeed the reader with terminology.

The rigidity of Scrum lies in the structure. There is a certain set of approaches that work better together than separately. Pull something out and use it for you, I hope no one forbids.

Scrum usually occurs where there is a certain product that has value for users and customers, and you need to understand as quickly as possible on the way to the goal whether we are running in the right direction or if we need to correct the course. The Scrum format allows you to release the next version more often, receive regular feedback and quickly refine the product, as well as improve the work process.

If you work in a team, Scrum requires all participants in the process to strive for interchangeability, the ability to “pick up” a sagging task if a neighbor is sick, the exchange of skills and collective responsibility for the product. There is little individualism in Scrum. Decisions are made collectively (according to strict principles), no one can pressure and force them to choose another solution if the team is sure that they have settled on the right one.

Having such confidence in Scrum is not scary, since each march lasts exactly one sprint (a clear period of time, usually from one to four weeks). After the sprint is over, there comes a moment of analysis: how did we get through it? What could be done even better next time?

Therefore, even if we all confidently ran in the wrong direction, we will have at the end of the sprint the opportunity to correct it and fix what is leading us in the wrong direction. The team in Scrum is self-organizing and self-tuning.

Team in Scrum

The standard size of a Scrum team is 7 plus or minus 2 people. That is five to nine. There is scrum scaling: you can build a system of work on a giant task out of 25 teams. But the basic unit of Scrum is the team.

Each team has:

• participants (in the case of IT - developers, who are these seven people you have - decide for yourself)
• product owner (product owner, product owner). His role: to understand the market and the user, to formulate tasks in the language of business and users, to keep in mind the awareness of the direction in which value and benefit should develop, to invent and select tasks for product development. Something like a product (not a team) leader.
• scrum master (scrum master, scrum evangelist). His role: follow the process, observe the inner life of the team, motivate people, remove obstacles. Kind of like a coach.
  Around the team there are users and stake-cholers (stakeholders, customers). The product owner goes to these people for advice.

Device sprint

Scrum work consists of sprints. All sprints are set up the same way. It is assumed that with each next sprint, the team becomes more cooperative and efficient. In Scrum, you learn from your mistakes, but quickly - every sprint you analyze what exactly you did and how you want to fix it.

The product owner has a list of business ideas to keep users happy. It's called a "product backlog" (a list of product ideas). In it, ideas are sorted by importance and significance.

Each sprint has a sprint backlog (sprint backlog, list of tasks for a sprint) - a sorted list of ideas that the team decided to do in the next sprint. The meaning of Scrum is that the team itself evaluates the complexity of each task and decides which tasks will be included in the next sprint.

The task in the sprint has a weight known to the team (it is known how long it will take), a performer is attached to it, it is understandable and important. If you don’t know how long a task will take, you need to break it down into smaller parts.

At the beginning of their life, the team always plans badly. This is an objective reality. But she keeps statistics of what she manages to do in a sprint, and plans more accurately over time. She is helped by the final meeting of the sprint - a retrospective. There you can discuss the weak points of the outgoing sprint and come up with ways to do it differently.

Usually 5 plus or minus 2 ideas fit into a sprint. If the ideas are too big, the team splits them up so that in each sprint there is something small to show.

In Scrum, ideas are called user stories (user stories, stories about users) and are formulated as follows: “I like (role?) want (what?) in order to (why?)”. Thus, the team sees not only the functionality, but also the meaning of its creation, and for a specific role: user, customer, buyer.

The result of a sprint is always something to show. Shows the work of the team on the demo at the end of the sprint.

In my opinion, the Scrum process is similar to working on a team blog. Such a process would help maintain regularity, bring together the expertise of the authors and not recruit so much that you can’t do it.

Sprint Structure

The sprint begins with planning: the team sits down and discusses: we take this idea, we don’t take that one. In IT, this process can drag on for a couple of hours, because the discussion goes down to the details. In the case of working with a blog, this can turn into a discussion of topics and a plan of articles, which you then have to sit down and write - understanding what we write, when and why.

Every day there is a stand-up meeting (stand up meeting, standing meeting) for 15 minutes. It is important to do it while standing: if someone talks, the rest will eloquently shift from foot to foot and scratch their ear. You can use some object so that only one participant speaks at a time, and pass it around in a circle.

Each stand-up participant takes turns answering three questions:

• what i did yesterday
• what will i do today
• what slows me down

All the detailed conversations that are tied up in the process go beyond the limits of stand-up. Stand-up is a point at which you can catch problems or find out that for some reason a colleague and I are doing the same thing at the same time, which means that one of us can do something else.

In general, the maintenance of all these clear rules of behavior should be handled by the Scrum Master. These are usually the ideologues of technology, who believe in it and are ready to build a process for the maximum efficiency of the time spent together. Without a Scrum Master, processes will degenerate into the minimum possible, because a person is lazy and economical.

At the end of the sprint, there is a demo (demo, demonstration) showing what we managed to create during the sprint, a sprint review (sprint review, sprint review) with a revision of the product backlog and talking about WHAT we do, as well as a retrospective (retro ) - what we did not do the best way the whole sprint and want to improve further - about HOW we do it.

“If I had eight hours to chop down a tree, I would spend six hours sharpening an axe.” (Attributed to lumberjack and President Abraham Lincoln)