At DeSmart, we have been working Agile for years. Our faith in Agile isn’t blind, though. Over the years, we have gathered the knowledge that lets us draw from this approach what we currently need in every project. The experience we possess is so vast that we thought it would be a shame not to share it.
That’s why we are starting a series of articles about the Agile way of working. For starters, let’s take a look at the seemingly obvious issues – the ones everyone familiar with Agile has heard of. Does everyone understand them, though? Read on to learn what our experts say to shed some light on five popular features of Agile people tend to misinterpret.
#1 Agile and Scrum – what’s the difference, anyway?
Bartek Rożan – Agile Coach and Project Manager at DeSmart, Scrum Trainer
Obviously, Agile and Scrum are not the same. If I were to explain the difference, I would compare Agile to religion, let’s say, Christianity. Agile is a philosophy you adapt to work in line with its principles. It’s a philosophy that helps you focus on delivering excellent products.
In every religion, there are different churches. Like in Christianity, which includes the Catholic Church, Protestantism, Eastern Christianity, and several other divisions. In each church, there are certain rituals members are obliged to perform. There are also other practices that are not compulsory. Scrum is like one of the churches comprising the Agile philosophy. It’s a set of frameworks or, in other words, methodologies you can follow.
Scrum has an advantage over other Agile “churches” – it’s very popular and well documented. Besides, there are specific rules in Scrum, defined in the Scrum Guide. It’s a concise document, consisting of only around 20 pages, which is a great asset. Who would like a guide book to be as thick as a phone directory, anyway? In the Scrum Guide, you’ll find the rules your whole team needs to know.
Kamil Fojuth – Software Developer, CTO at DeSmart
Agile is the team’s ability to react to changes. It’s not like in Waterfall, where you get a long list of requirements, and you start developing the product only to learn, after a year, that it’s a disaster. The client wanted something completely different. In Agile, week by week, we refine the product together with the client who is, in fact, a member of the team. Together, we take the decisions on what each feature should look like.
Agile is also the team’s ability to accept the fact that there are going to be some changes. Let’s say one day your client approaches you and says: “Hey, I know we planned this and that for next week, but our priorities have just changed. So, we decided we need something else at the moment.” What is your answer? Definitely, it’s not: “Oh, no, no way, that’s impossible!” Instead, you say: “Okay, let’s meet, let’s estimate the time we need, and see what we can do.”
And as for Scrum, it’s simply a framework, the way you work. Scrum defines the work process, the meetings and the frames in which we proceed in the project.
#2 Are we going to work faster as soon as we implement Agile?
Bartek:
Implementing Agile is not a way of speeding up your work. Instead, you can improve your performance and limit the amount of unnecessary work. Besides, Agile helps you adapt not only to the needs of the market but also to the team’s needs, to the situation you are in and to the level of maturity we have as a team, with the client as its integral member.
In an Agile project, everything develops at its own pace. When the team kickstarts, its members need some time to get to know each other and to mesh. They need to consider the fact that the other party may not know the answers to all the questions they want to ask. Developers cannot expect the Product Owner to have answers ready. And similarly, the client has to accept the fact that the development team can give them helpful advice. In general, in the beginning, as the project starts, everyone learns. We get to know each other, too. As a result, the work may be slower, but it is closer to reality.
I’d like to emphasise one thing – deadlines. They help Agile teams discipline themselves. The majority of us suffer from what I call student syndrome. We tend to procrastinate, to postpone tasks we have to deal with. Scrum lets you get rid of the student syndrome once and for all. That’s because in Scrum you have iterations. The iterations we work in are no longer than two weeks, so you cannot really procrastinate.
To sum up, there are plenty of aspects that speed up work in Agile projects. And in the long run, I truly believe that Agile teams work faster. How do I know that? At my workshops, I often assign tasks to my students, and then I check who’s the fastest to deal with their job. That’s not the rule, let me admit it, but the truth is that in 70 per cent of cases Agile teams finish work much faster.
Kamil:
You need many sprints before you achieve the optimal velocity. And the speed you are aiming at can be influenced by small factors. For instance, you need to set the sprint start date. You have to decide when you are going to upload the new version of your software to the production server. You must schedule meetings and choose whether to hold them in the morning and have plenty of time for work afterwards or to have them in the middle of your workday and mess up your plan for the rest of the day. You can gather all your meetings in one block, on one day. Or, you can have them scattered over the whole week.
Another critical issue is to diagnose and write down all user stories accurately. If you define them really well, you can quickly implement each of them and immediately show a working feature to your client. At the demo, you can present finished components that can be uploaded to the production server. As a result, week after week, the client sees incremental advances in the project you develop together.
So, can we say that Agile speeds up work? I would instead say that after – let’s call it – the initial labour pain Agile can indeed speed up the delivery of the product within the set time.
#3 Do we always have to be 100 percent Agile? No compromises?
Bartek:
From my own experience with beginners’ teams, I know that they always try to work in line with what they have learned from a consultant or what they have read in a guidebook or on the Internet. That’s okay as long as we are at the initial stage of setting up the team.
However, have you heard of Shuhari? It’s a Japanese martial art concept according to which Shu means Follow the rule. Ha – Break the rule. Ri – Be the rule. That’s the way martial arts students gain their skills. You may remember The Karate Kid, a film about a young man who wanted to learn karate. His training consisted of seemingly pointless activities, like painting fences or washing cars. For each of these activities, he had to move his arm in the same, specific way. Finally, he mastered the movement, in other words, he followed the rule. Thanks to that, he could break the rule and move his arm in the opposite direction when he needed it during a fight.
That’s what Agile is about. We don’t have to be one hundred percent Agile, but we know its rules inside out (Shu). We know them so well that when it comes to breaking them (Ha), we can consciously choose our own way, without the risk we will compromise on quality. And all the time we remember our primary goal.
And what about Ri – Be the rule? At DeSmart, we are moving away from Scrum in its standard dimension. For example, as a Scrum Master, I’m working less with our teams at the moment. Instead, I’m working with the whole organisation. Our aim is to stop implementing the framework (Scrum) and start organising our work on our own. We want our clients to feel that we are not some sort of a superficial formation, but we are a real team, able to establish good relations.
Kamil
100 per cent Agile? No way! Agile is a set of suggestions on how you can work. You cannot force them all upon yourself. If you assume you are 100 per cent Agile, it will mean you are resistant to changes, and changes can make your work more effective.
As Bartek said – you have to get to know Agile and Scrum to be able to understand what tools you have at hand. And when you know that, you can draw from your knowledge what is best for the project you are working on at the moment. If you know the rules, you can break them, and you know very well the consequences of your decision.
#4 What does the Scrum Master do?
Bartek:
In Agile projects, we tend to say that we are ready to continually improve our processes and agility. However, people are not that eager to implement changes. That is why we need the so-called change agents. Scrum Masters are such change agents and, in my opinion, that’s their crucial role.
The Scrum Master is not the team’s assistant, or a person responsible for removing impediments for team members. The Scrum Master constantly looks for improvements, inspires team members, shows them things from a different perspective and keeps reminding them of what they are doing, for who and why. It is a person whose aim is also to build the team. Their most significant success is when the team becomes informed and can independently define and grow the strategy of developing products that users really need.
The Scrum Master’s role is to encourage members of the team to take responsibility – both for technical and product matters. For instance, responsibility for keeping the deadlines they have set for themselves. And finally, the Scrum Master is supposed to encourage team members to be active. Not everyone is willing to take action. At the same time, in Agile teams, you need to be active, especially if there are no fixed rules and you all work together.
Kamil:
My opinion on the topic may be controversial. I believe you don’t need the Scrum Master in every project. I think less experienced teams need a Scrum Master to be their facilitator. You need one in teams whose members haven’t known Agile before, and they don’t get the idea of Scrum.
Many people think the Scrum Master’s task is to make sure meetings are held according to the schedule. I know, however, that experienced teams can see to it themselves. People know what they are supposed to do and don’t need anyone to remind them about meetings. Like in our current project: very often, you can see two people sitting in front of one computer, doing some analyses. No one forces us to work like that. That is the way this team functions.
#5 How to communicate within the team?
Bartek:
First and foremost, you need to understand everyone involved in a project, both developers and the client, work as one team. We are not divided into US and THEM. At DeSmart, we always encourage our clients to treat us as members of their own team. As if they employed us to work at their office.
Second, we work in an international environment, with people from various cultural backgrounds. That is why we have to agree on certain conversation standards, entirely focus on communication and work on it regularly. And that’s where the Scrum Master comes in – it is their responsibility to ensure everyone in the team not only heard a message, but they also understand it.
I should also mention language issues. We all have different accents when we speak English. You need to make sure your interlocutor understands what you are saying. I know a guy who works with native speakers of English and teaches them how to talk to non-native speakers, so they fully understand the message.
And finally, communication should promote active behaviours. What does it mean? At DeSmart, we always encourage our people to paraphrase what the other party says to make sure they understand it correctly. Also, everyone can host a meeting or give a presentation at a demo.
Kamil:
First of all, everyday communication in an Agile team is informal and direct. There are no intermediaries. Every developer can reach out to the Product Owner and ask a question if they have any doubts. It drastically reduces the time needed to get an answer. Sometimes you wait only 2-3 minutes to learn what you need to learn.
So, if one day it turns out a user story is unclear, developers will not wait until a meeting starts to ask a question. They just go on Slack, message the client and requests for clarification.
At DeSmart, we have friendly relations with many clients. We can chat about nothing, tell jokes and have a laugh sending funny memes.
Bartek said that developers and the client are one team. Still, we are based in different geographical locations. The client is usually in another country, which may set up a barrier. To reduce it a little bit, we use cameras to see one another during meetings. We can observe each other’s faces and our body language. It’s a crucial issue that influences the mutual understanding. Sometimes it’s only a wince on someone’s face, and you immediately know they don’t like your solution. We don’t have to guess anything. We respond at once.
Conclusion
These are just a few features of Agile people think they get right while, in fact, don’t fully understand. And when you don’t know how things really work in Agile, there is a risk you won’t reap all the great benefits this “religion” offers to its “believers”. That’s why it’s always a good idea to get in touch with true Agile practitioners who can share experience gathered in their everyday work.
