SCRUM IN ANCIENT EGYPT AND NOW

The history of Agile goes back to February 2001, when a document called the Agile Manifesto was published. The text of the document consists of obvious philosophical formulas (simplicity is the art of not doing unnecessary work) and a number of controversial statements (the best technical requirements, design, architecture are achieved by self-organised teams). The document is a curiosity not only for its content, but also for the changes in software development that followed. In the shortest time on its basis were built the techniques of “agile” development methodology, which started their way all over the world, capturing contractors and customers. Adherents present the manifesto as a ‘silver bullet’ for all problems. In the most extreme cases, an ordinary programmer is ashamed to admit in public that he works in a company with a traditional development methodology (waterfall). In this article, I would like to invite you to consider and analyse with me the causes and consequences of this phenomenon, using the most widely used framework - SCRUM.

AGILE METHODOLOGIES WILL NOT SAVE YOU FROM PROJECT FAILURE

– We won’t make the deadline!

– Use Agile!

– It won’t help us if we don’t have enough people!

– Then find another clever word!

Many people associate project failure with the choice of development methodology: if they had chosen Scrum/Agile/DevOps, everything would have been fine. To be honest, these people don’t understand software development.

Alistair Cockburn analysed several software projects delivered using different models. He found no correlation between success or failure and the development methodology used. Cockburn concluded that development effectiveness does not depend on the methodology used.

A BRIEF SUMMARY OF THE SKILLS OF AN IT PROJECT MANAGER

There are a huge number of project managers on the market with different levels and experience. But can all project managers on the market be IT project managers?

If you look at the market for project manager candidates, everyone has a wealth of experience. There are candidates with experience in construction, medical projects, aerospace. The level of responsibility and requirements in these industries is God willing. Are these candidates familiar with IT? In most cases, if you ask whether it is worth inviting such a specialist, the answer will be ‘what difference does it make whether he knows IT or not, he has experience and knowledge of methodology - and that is the most important thing. He will be able to build us a system for working on projects’.

TASKS ARE NOT PROJECT MANAGEMENT

- Hey there. Long time no see. How are you? What are you up to?

- Good to see you. It’s been a while. I got a job as an IT project manager for a big company.

- It’s cool. Scrum, TDD, Agile. Hard?

- Not really. I write technical tasks and send them between techs and customers. It’s not a big deal.

Unfortunately, such conversion still be real. It’s relevant to many people who are not part of the large vendors or integrators, where all processes are better than Swiss watches and projects are really projects. But small and medium sized companies often ignore the concept of ‘project’ and work is done as it happens. A project manager in such company is more like a supervisor who gives the programmers a task to develop functionality as quick as possible, then asks testers to verify it, and then makes sure that it all go to production and customer. He gets a list of bugs from a customer and cycle starts over again. Such manager doesn’t distinguish between the critically and importance of the required functionality and the bugs. If the customer reports even a minor problem, the developers hear ’everything is broken’. This is an extremely unhealthy situation and this is what I want to talk about in this article.

12 KILLERS OF DEVELOPER PRODUCTIVITY

One of the most important and popular issues for project managers and technical leaders is increasing developer productivity. Many articles have been written on the subject. Let’s take a look at the root of the problem.

Almost 30 years after Tom DeMarco and Timothy Lister’s book ‘The Human Factor’ was published, projects continue to suffer from huge productivity losses. And there are many reasons for this misery.

Breaks and meetings

Interruptions are a major killer of developer productivity. It can take up to half an hour to pick up where you left off. The more interruptions, the harder it is to get back to work. Bottom line - more bugs and errors.

11 PECULIARITIES OF AGILE IMPLEMENTATION

After the article on the myths associated with Agile, it would be strange not to discuss: how to understand if the implementation of Agile is done correctly, which framework to use when, who in the company should be responsible for the transition to Agile.

I have divided the specifics of Agile implementation into two categories: company related and team related.

How do the specifics of the organisation affect the implementation of Agile?

Peculiarity #1. Industry preference for agile.

According to surveys, Scrum is the main method used in software development, financial institutions prefer Kanban, and telecommunications companies use both Scrum and Kanban.

9 MYTHS ABOUT AGILE

Agile development methods work both in IT and out of IT. In the time since the Manifesto was published, they have acquired ideas, stereotypes, superstitions, legends and myths.

Agile principles have transformed the development process and earned respect. The modern world is changing and evolving too fast - dozens of new solutions, applications and services appear every day. Agile methods enable companies to develop new products quickly enough to keep up with the pace of the market and of life, and to provide users with solutions to their problems as quickly as possible.

IS THE ENGINEERING PROCESS OVERRATED

Many engineers and managers focus too much on the process and overlook the far more important aspects of running a successful engineering team.

This article is a quick reminder of what really matters and where engineering managers should be spending their time and energy.

In the course of my work I have interviewed many people. And every time, the question inevitably came up: ‘How is your engineering process structured? Are you in agile team?" At the moment the terms agile, scrum, sprint are used very loosely and I dare say we hardly all understand them in the same way. How did we get from the original Agile Manifesto to where we are today?

CHANGE MANAGEMENT THROUGH RETROSPECTION

Retrospective is a collaborative team format that combines elements of brainstorming, coaching and feedback. Regular retrospectives that lead to change are an important sign of a self-organising team. But in most cases, retrospectives are purely formal rituals that are done for the sake of ticking boxes (well, we have Scrum). A successful retrospective requires a facilitator (preferably with experience of retrospectives). This is particularly important in new teams. In this article I will try to share my views on retrospectives and, if possible, give some tips on how to conduct them so that this ritual does not become an empty formality.

RISK MANAGEMENT PRACTICAL TIPS

Despite the super-accessibility of information, there are still people who turn a blind eye to a number of obvious things. This results in wasted time, money and effort. In this article I will try to make risk management as simple as possible.

Working with risk is, in my opinion, one of the most important aspects of being a project manager. Have you ever been in a situation where you have solved a big task, spent a lot of time on it, and just before the finish line you started to feel insecure? And how often have you had thoughts of ‘do or die’, ‘wasn’t done’, etc. in your head when completing tasks? Were there times when, at the finish line, you said to yourself or out loud ‘it’s over’ and felt relieved? Or, on the contrary, did you pound your fist on the table in frustration?