Blog

FIS-SST

Scrum and Agile from a developer’s perspective

Anna Nawrot

Agile and Scrum – terms that are hard to tell apart. After all, Scrum is a flexible Agile framework that we software developers know particularly well. But do we really know it, when so often certain aspects are misinterpreted?

Daily Scrum

In theory, a simple stand-up meeting that should give the whole team an overview and provide simple answers to the question: “Where do we stand as a team?” As simple as it sounds, the mistake is made again and again that participants tell the team what they have done the whole day! The team doesn’t really want to know! That’s why you should always keep the rules in mind so that it is short and to the point.

DAILY RULES:

Each person reports

  • What he/she has done since the last Daily
  • What he/she plans to do until the next Daily
  • Where there are problems or help is needed

As a rule, each participant should not speak for more than about 2 minutes. If more in-depth discussions are necessary, these should be outsourced to a separate meeting!

Work Agile

Agile means being flexible and also that late changes to the project requirements are welcome. But what if the requirements are requested in the middle of the running sprint? Sure, in theory the sprint scope should not be changed, in practice it doesn’t always look that easy. Therefore, should developers who are bombarded with tasks voluntarily work overtime with a smile on their face? Of course not. You can accommodate the client, but he should be aware that the following rule applies at this point:

If something comes in, something has to come out, i.e.
NEXT with highest priority IN, LAST with lowest priority OUT

Imagine that two planes are supposed to take off, but shortly before take-off one of them breaks down – then you won’t squeeze all the people into one plane because that would be uncomfortable and also too risky to have a standing place only – you either try to rebook the flights or offer the customer an overnight stay in a hotel. Unfortunately, this is also sometimes the case during a sprint, when unplanned bugs come in from production or the customer notices that they still absolutely want time-consuming changes in the version, then you should “rebook” tickets with the lowest priority – i.e. take them out of the sprint, instead of squeezing everything together with the conscience – it won’t go well and we will crash as a team.

It should be one of the exceptions that tickets are taken out of the current sprint, but if this occurs, it should be communicated to the client well in advance.

Refinement Meeting

Refinement Meeting is a process of nurturing the Backlog, i.e. supplementing its elements, adding details, dividing and estimating tasks into smaller ones, or simply deciding on the order of implementation. It makes sense to have a refinement meeting once a week. The following topics should be considered:

  • Where do we stand as a team with the next delivery version?
  • Have the customer’s priorities changed and should certain tickets be prioritised differently?
  • Are there new customer requirements that absolutely have to be delivered with the upcoming version (do tickets have to be taken out?)
  • Have the customer’s priorities changed and should certain tickets be prioritised differently?
  • Does the team have enough tickets that should be implemented?
  • Are there blocker tickets that are preventing work?
  • What needs to be estimated for the upcoming sprint?

Dates in the sprint

The more regular the sprint and thus the review, retro, planning and delivery day, the less time the team will waste on always checking and asking when something is taking place. For most teams, a 4-week sprint is recommended, so that there is enough time for development and the review is not so time-consuming. Bad practices include the constant postponement of delivery dates (or even worse – at short notice before delivery), because everything has to be rescheduled and accordingly a lot of time is spent on discussions about when review, retro, planning and smoke test will take place. The biggest challenge here is that the calendar appointments of the individual people in the team, often also internationally, have to be observed and many of them collide with each other.

Agile project, Agile developer?

What has proven to be very good practice in my teams so far is the flexibility of the developers. What does that mean exactly? From my point of view, that the developers are at least well oriented in different areas. Of course, it will never be the case that one developer is very well versed in all areas, this mostly concerns the small projects where only 1 developer is involved, but one should make an effort that at least 2 developers from the team are well versed in one topic. This has some advantages:

  • You always have a substitute during holidays or illness – they are rarely scheduled and do not pay attention to whether the developer has been assigned high-priority tickets,
  • You can come back from holiday and there are not 100 tickets waiting on the first day that have to be urgently clarified and fixed by yesterday(!),

But flexible also means giving others in the team a chance. Every developer has his or her own experience and often a different point of view. If a developer from the team does not find a satisfactory solution to an existing problem after much deliberation, then another developer should look at the problem. That is also part of agile working – changing perspectives, discussing problems with other people in the team and looking for solutions together.

A Know Issue is sometimes better than a Fix

Even if you work in an agile way, it doesn’t mean that you will only encounter certain problems on the day of delivery. When troubleshooting, you should be aware of one thing – the more you fix under time pressure, the more you can break. This is unfortunately a fact that is so often forgotten. When working under time pressure, not all test cases are considered, let alone carried out, due to time constraints.

Instead, you should stay calm (easier said than done, but rushing doesn’t help anyone!) and consider together with the product owner/Scrum master how critical the error that has occurred is, what options the customer has to work around the error and, above all, what risks the fix could bring. As a developer, you have to be able to clearly express your opinion, because often it is not the customer himself, but the product owner and Scrum master who put the pressure on. You should therefore clearly present the risks and put the brakes on.

HotFix should not become a HotChange!

Agile means flexible, but it doesn’t mean that you can bend certain processes of software development around as it suits you. A hotfix is a delivery of packages to fix a problem in a software product – usually often to fix a specific customer situation. However, there are situations where the customer tries to force new requirements into the HotFix under the accusation that “the team is flexible after all”. This is not a good practice and one should remember that the customer gets used to certain measures very quickly and sees them as problem-free – because once you have made an exception, you can make it again and again, can’t you?

Agile projects under time pressure?

Is it necessary to put pressure on the end customer in an agile project? To a certain extent, yes, especially when it comes to testing the application. The software should be tested as quickly as possible after going live or, if necessary, already in the integration environment, ideally by clearly defining a deadline for acceptance. Why the hurry? Firstly, because the end customer will use the product and has a different view of it than the developer, and thus certain aspects that were forgotten during the conception can be caught early on. Secondly, if the test results are only delivered months later, the developer has to think again, because he has long since left the subject. This costs time and money, and customers should always be made aware of this.

Conclusion

As a developer, you always have the right to influence certain processes and each of us should have a voice in the decisions in the team. After all, it’s about our work and our everyday life and mostly we developers end up being affected by the decisions. Working under pressure and heavy load can lead to mental problems of the team and make the work ineffective. Therefore, certain aspects should be communicated clearly and in everyday situations. A clear opinion is always better than silence.

Contact form

Patrycja Pałus

Office Administrative Assistant

Please feel free to contact me by phone or email

Download

Damit der Download erfolgen kann, geben Sie bitte hier Ihren Namen und Ihre E-Mail Adresse ein.

Unternehmensinformationen herunterladen (PDF)

Damit der Download erfolgen kann, geben Sie bitte hier Ihren Namen und Ihre E-Mail Adresse ein.

Grenzüberschreitendes Unterstützungskonzept

Damit der Download erfolgen kann, geben Sie bitte hier Ihren Namen und Ihre E-Mail Adresse ein