Go to:
Agile approach 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 organisation and prioritization
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.
Agile project management in Scrum
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.
Elevate Your Application Development
Our tailored Application Development services meet your unique business needs. Consult with Marek Czachorowski, Head of Data and AI Solutions, for expert guidance.
Schedule a meetingUsing Agile in practice – common reasons for misunderstanding Agile
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.
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.
Misunderstanding Agile development approach – summary
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.
EXPERT KNOWLEDGE
Agile Methodologies in Software Development
Find out what agile means and what are different agile methodologies in software development. Go to article!Misunderstanding Agile development approach – 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.
Consult your project directly with a specialist
Book a meeting
Experienced Scrum Master. Enthusiast of using an agile approach not only in IT projects but also in other aspects of life.