The world is changing too fast to not be Scrum – the method explained

Before looking under the hood of the Scrum management machine, one should first put on the shoes of the person who is about to switch from petrol to diesel, or reversely - none is better, but some feel them differently. As most of us have gotten used to matrix management, going to Scrum might seem similar to increased pulling power of diesels - you drive the same roads but now you step on the gas more gently, without flooring it anytime you want to overtake who drives before you.

This analogy suits Scrum perfectly - you roam the same business roads but you distribute your energy in a new way. But then, how to tell the board in your company that you are about to change the management fuel, and what might worry them the most?

Scrum steps

What will shock all of us in Scrum is managing without scape goats… The structure of team is always the same and it is Scrum Master who is brought before the judge when the board is calling. The system of backlogs and DoD (Definition of Done – the completed status of a task) spreads the task in such a way that it would take half of the company to say who, for instance, failed. Besides, the priority for a Scrum Master is to solve the problem, not to point out the goat.

The other thing is that if no one but the Scrum Master has an access to the development team, and if the whole concept is based on delivering status in short terms which any time can introduce a new portion of unprecedented work, that might seem a bit chaotic.

"But it is not,” Piotr Piwoński, Software Quality Leader in VECTOR BLUE HUB, assures. "There is the system of Sprints preceded by Sprint Planning, and next finished with Sprint Review, and then summed up together with the team during Retrospective. The whole time you meet on Dailies to stay assured the work proceeds. There's no place for chaos. The swiftness, agility, abrupt redirections might seem disturbing but, in fact, they are well supervised."

However, one might say then: "Okay, so change this or that. Here I want to have a new functionality and there let's make the layout from green to violet!" No! Scrum entails waiting! Waiting for the Sprint to meet the end. Remember you follow: plan, do, revise, repeat. For the feedback the board has to wait to get it from the Product Owner after the Retrospective during which the Scrum Master, Product Owner and development team debate over what happened. Getting used to waiting for the moment to finally converse hurts many managers' pride, but the whole process only underpins assurance that the discussion is going to run to conclusions.

Is Agile Scrum, or is Scrum Agile?

Throughout the whole discussion over the innovative management we have come to making Agile almost a picklock for the answer: "What to do?" But Agile stays an adjective, and describes agile methods of management - not the answers. Thus, it is a broader term than Scrum and shows manners of problem tackling. What are they?

We do what is really valuable. That is why no one wastes time for searching who made the mistake. It is more important to think over what would prevent the mistake in the future rather than telling the grown-ups off.

Realizing short-term plans which build up long-term plans. And it is all about being agile in management. The development team is heading the end but they deliver values iteratively in short spans.

"It's the magic of asking if it is what the Product Owner and client had on their minds. And there might be a change of mind! And that's also okay. The team still delivers those changes," Piotr explains.

In other words, it is placing planning over the plan. No one is condemned to the destiny of the order made at the beginning any more. Midway, you repeat the simple process - inspect and adapt.

Before you run a Sprint

Above all, it is the software industry which absorbs the Scrum rules most keenly. But to do so, a few things must occur before starting any Sprint.

The definition of "done" is the roadmap for the development team prepared together with Product Owner With such tools like Jira, working in real time, Product Owner says which bullet points on the list must be crossed to call a task done. The twist of it guilefully spins in designing such a list. You think in advance because writing the code without testing will echo in the later stage when another part of the code is dependent on the prior one. So simple, and yet designing the process demands great alertness. Sly traps are scattered everywhere – saving your work and making a backup does not always call for being done in our heads. Before running any Sprint you sure want to have the DoD closed.

Kneading rolls and buns short of Scrum?

Scrum is not for the products of the low risk of changes. Implementing Scrum in bakery would be quite a show – image the bakers gathering around the table establishing how to swiftly bake the rolls for the upcoming week... We know how to do it step-by-step, day-by-day, so let us get the job done. The same refers to such projects like constructing buildings or roads and bridges, material processing, or goods distribution. In other words, on all the markets where the risk of changes is nonexistent or close to zero.

However, where Scrum is necessary are the projects characterized by complexity in terms of logistics, designing, planning and executing versus the high of changes. That is why new technologies and electronics are more than welcome to be managed in Scrum – the market development rapidity is so fast that what was innovative at the beginning of the project is very often outdated at its end. Then again, in Scrum planning over the plan is crucial. Moreover, services miss the point of the Scrum management. Some companies, of course, might support delivering their values in services using all the Scrum tools, but at the end of the day, Scrum is about products whose increments are measurable and developable. Can we do it alongside giving services? The question will always fall close to answering about the efficiency of values delivering.

Scrum appeases, not disturbs

The rapidness and changes in the process paint Scrum almost Pollock-like, but nothing is more decisive. The whole discussion breaks down to:

- short-time runs of task – mostly any Sprint takes two weeks

- productivity – Scrum works best for products

- empiricism – simple method of "inspect and adapt"

"What adds another value to Scrum is transparency. No one stores an excel file in their digital dungeons but everything happens on one ubiquitous schedule - accessible for Product Owner, the client, and the development team with support of Scrum Master. Everything, however, comes up during Sprint Review, when the increment of the tasks is to be shown and revised," Piotr points out.

New market changes and great speed of today's changes call for being not only agile but also smart. Is it not smart to adjust the system to the environment than the other way around? Sticking to what was falls nowhere near to what is – Scrum management lets some control into the disturbed roads of today's business.