During the last few dozen years the IT industry, including in Poland, has undergone a huge metamorphosis. The technological leap we are witnessing has been complemented by a change of approach in the context of IT project management.

The waterfall model is more frequently replaced by an Agile one, of which many have heard, many believe in practice, but which is still misunderstood – mainly by business representatives who are willing to start cooperation in the Agile model. In today’s article I will try to show the value of Agile techniques and answer the simple, yet troublesome question: ‘What does Agile really mean?’

Agile basics

Let’s start with the ‘Agile Manifesto’, which is the basis of each Agile software development framework. It values:

  • Individuals and Interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

So taking all that into consideration, putting the emphasis on communication (with the client as well), focusing on the delivery of high-quality software instead of creating comprehensive documentation, and being flexible in terms of carrying out the project – all these factors influence the planning stage.

In contrast to the cascade model, in which long-term planning is still standard, we divide workflow into Sprints. Why then, despite its rising popularity, is Agile still misunderstood? Below I will attempt to answer this key question.

Agile organization

Daily, Review, Retro… All those who work in the Scrum framework hear these terms over and over again, sometimes each and every day, and their meaning has no secrets for them. But are we aware of why we use them? To facilitate understanding, I shall briefly remind my readers of the aforementioned terms: clarify their meanings and why they are so important.
Being familiar with Agile planning is essential in order to avoid Agile-related mistakes.

Firstly, let’s have a look at so-called events, which make it easier to create regularity and are conceived in such a way as to assure transparency and allow for the verification of work at each stage during the project delivery process. “The heart of Scrum is a Sprint” – a defined period of time during which an Agile team delivers an Increment, as mentioned earlier on.

The Sprint itself is not an event; however, it consists of them, which allows for better work organization. The scope and manner of delivering Increments during the Sprint is planned by the Development Team during Sprint Planning. Daily, Retro and Review meetings make it possible to optimize the workflow scheduled beforehand.

Daily Scrum meetings ensure transparency and enable the Development Team to catch any potential issues, and a Review allows them to verify what has been delivered during a particular Sprint. A Retrospective is needed to examine successes as well as issues which require improvement.

Does it sound like a piece of cake? According to the popular saying: “Scrum is easy to understand but hard to master”. Let’s examine how it works in practice and what are the most common reasons for Agile-related misconceptions.

Read more: Trust in Scrum Teams

Agile in practice – common mistakes

1. Misunderstanding the rules

The principles of Scrum as defined by the “Agile Manifesto” seem to be simple; nevertheless, the majority of people who work in the Agile framework might grab their heads in amazement while reading the above: “It doesn’t work this way in my team!”

From my own experience as a Scrum Master I may admit that valuing people and communication over processes and tools is respected; however other rules are a common matter of misunderstanding.It happens very often due to business expectations of being provided not only with functioning software, but also with project documentation, which results in Agile being oversimplified to “Delivering a biweekly functionality package by development”.

Misconceptions related to the Agile approach may stem from a lack of knowledge in organizations (both Polish and international) about the efforts of the development team, which tries to deliver a package that would meet functional, quality and security standards. It may turn out that contract agreements pose a barrier to ideas and the improvement of development teams and the rule “cooperation with the client over formal agreements”is not respected as a result.

Understanding the fact that an agile organization aims to deliver a high-quality product is a key factor in terms of a team working in the Agile model achieving its full potential. This is where a Scrum Master / Agile Coach plays a key role. It is his task to educate both the team and the business representatives.

2. Misunderstanding Agile organization principles

A cascade approach to artefacts and events is another common issue in IT projects. The majority of business representatives are not aware of the importance of the Definition of Ready in the context of future delivery of the product, the Increment and the single task.

It may also turn out that the Definition of Done is underestimated as a guarantee of quality and, very often, perceived as an obstacle in the process of delivering the package of functionalities after a Sprint. A client trying to force the development team to deliver functionalities before the date declared during Sprint Planning is also a familiar occurrence.

Agile techniques are aimed at delivering particular Increments within a particular timeframe. It is a bit like building a house – we don’t start by choosing the colors to paint the walls but rather plan the whole process stage by stage.

This is what the Sprint Planning, Daily, Retro and Review meetings I mentioned earlier on are for: they allow us to plan work at each stage without focusing on tasks that may arise in the future, which allows the team to focus on the particular tasks that they are currently working on.

3. Misunderstanding roles

A misconception around roles in Scrum is the other cause of Agile-related misunderstandings. This may result from a misunderstanding of the idea of a self-managed team. As a Scrum Master I will provide an example regarding my role, which is very often misunderstood by individuals from outside of Scrum teams. One may wonder: how can teams function without a leader? Leadership has existed from the beginning of time and there have always been leaders taking responsibility for management.

Sometimes the role of a Scrum Master is belittled as a “Project Manager who is not a manager” and omitted in the team-building process (“He does not bring any value; we could hire a developer instead”).

The Scrum Master neither codes, nor tests, but… does it mean that he is redundant? No. Scrum is an empirical approach, based on experience and communication, and the Scrum Master’s input in tasks is immeasurable, since it is his role to make the Development Team aware of how to act in accordance with Agile rules. You will not see the Scrum Master’s value on a Burn Down Chart, but his input is always observable in the team members’ approach to work.

Summary

In Agile techniques each event, artefact, meeting or discussion matters. The agile approach in each framework, not only in Scrum, is a complex process; it is like a system of connected vessels, where each action (or inaction) causes reaction. Being aware of that is a key factor in terms of understanding the idea of Agile. Also, it is important to comprehend that Agile goes beyond a Development Team, hence formal agreements and clients’ representatives have a direct impact on the work of Development Teams. What could we do to ameliorate this state of affairs? Communicate, react to changes, and emphasize everyday communication between the client and the Development Team. This is how we get back to Scrum principles. Putting them into practice is the best way to educate both the Development Team and the client. It is a strenuous and time-consuming process, but I believe that within each IT organization using Agile we can benefit from the help of a qualified Scrum Master (or even an Agile Coach) willing to explain why ‘Agile’ means ‘different” and what benefits it brings with it.

Author
Igor Karkoszka

Experienced Scrum Master. Enthusiast of using an agile approach not only in IT projects but also in other aspects of life.

Comments:

CONTACT US!

Would you like to learn more about the possibilities of cooperation? Do you have a question? Write to us!

I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for commercial purposes.
I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for marketing purposes.
I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for recruitment purposes.
I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for future recruitment purposes.
I have been informed by JCommerce Sp. z o.o., 3 Ks. Piotra Sciegiennego St. 40-114 Katowice – the personal data controller – that: - The provision of the aforementioned personal data is voluntary but essential for commercial purposes if I have chosen a request for proposal, or recruitment purposes, if I have chosen the remaining options;
- I have the right to access the content of my data, including to receive copies of it and correct it, delete it and limit the processing of it, as well as the right to transfer it, the right to object to the processing of it, and the right to withdraw my consent at any time. However, the withdrawal of my consent shall not affect the lawfulness of processing carried out on the basis of the consent in question prior to its withdrawal;
- A statement of withdrawal of my consent to the processing of personal data should be submitted to the headquarters of JCommerce Sp. z o.o. or sent to the following e-mail address: zgody@jcommerce.pl. The withdrawal of consent to the processing of personal data shall result in the inability to fulfil the aforementioned processing purposes;
- The personal data provided shall be shared by JCommerce Sp. z o.o. with the company’s authorised employees and individuals collaborating with JC under civil-law contracts, who are involved in the implementation of the purpose of the processing;
- The data provided shall be processed on the basis of the relevant provisions of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), ‘GDPR’;
- Should you have any questions regarding the protection of your personal data, please contact us by e-mail: odo@jcommerce.pl;
- The personal data provided shall be processed for the purpose for which it was supplied, or until I express my objection in this regard. In the event of filing an objection, JCommerce Sp. z o.o. shall no longer process my personal data for the aforementioned purposes, unless it can demonstrate that there are valid and legally justified grounds overriding my interests, rights and freedoms or my data is necessary to establish, pursue or defend a claim, if any;
- I have the right to file a complaint to the supervisory authority if I consider that the processing of the aforementioned personal data violates the provisions of the General Data Protection Regulation of 27 April 2016.