Many of us head to the gym probably thinking of achieving splendid results which we eventually get. Once your body gets comfortable, a similar routine may assist you properly, however, you won’t get any further gains and you might think of skipping it completely. We believe Scrum as a technique for offering software projects is experiencing a similar issue. The entire cycle or the process of practicing scrum is either exercised too literally or adhered too strongly. As we know, the Agile Manifesto sets the brick for a revolution in software development. For engineers, it’s a bunch of principles that let them do constant work and short release cycles in a swifter, effective, and graceful way by covering changing needs on the fly, and enhancing dialogue with the business and the customer as well.
However, there is no sense of doubt that Agile is a great approach to software development when you completely understand the concept behind it and apply it effectively, it can truly assist teams to accomplish results faster. Besides, the issue with certain companies today is that when they consider agile, they are thinking of Scrum and they don’t see a difference. Scrum is simply an application of Agile. If you consider agile a bible, then think of Scrum as the catholic church. Moreover, we don’t feel that Scrum should apply to everyone considering Agile. So, what’s the matter with all this? Why has it been considered an issue that Scrum has seen as the de facto for Agile over the industry? Let’s dive in and view some of the components of Scrum and learn why scrum is important.
What is the objective of Scrum?
Scrum is a term that defines an attainable sprint objective for around 2 weeks. It should support all the teams to learn through their experience, self-organize while working on an issue, and later reflect on their gains and losses to grow constantly. As we have seen, scrum has, sadly, ended up damaging the middle tenet of Agile, which is individuals over the process. This all comes down to poor management skills and the growth of the certified scrum master.
Daily Standups for Managers
For the development team, Scrum is likely to be a 15-minute, time-bounded event to strategize for the next 24 hours. Unluckily, these daily standups have turned a medium to obsess with JIRA tickets going across the board. Running tickets over a set of swim lanes looks like counting lines of code as a measure of success. A dedicated developer can seem productive all day simply due to how swiftly they have moved all their tickets. On the other side of it, a complete focus on the board can lessen good developers working on daunting tasks to look average.
Benefits Associated with Daily Standups
- They ignore blockers – As we have seen, this only stimulates your entire team to introduce blockers on the daily standup. However, blockers should be labeled immediately, not wait for a routine.
- Enhances overall team communication – This seems suspicious, your extremely reliable team should be boosted to communicate ad hoc in advance, when needed in real-time, not wait long for routine to label problems. Always remember, the quantity of communication does not define its quality.
- It provides you better visibility of what everyone is doing- As exposed to working with a detailed and well-structured board where you can easily view this information in few minutes and not waste more than 15 minutes every morning discussing it?
- Suppose someone is not picking their weight, it represents on the standup- If this happens, then you have either hired a wrong candidate or they are not much involved in tasks they find stimulating. Moreover, we believe that the laziest individuals are frequently the ones that reveal the most at standups, wasting each others’ time.
- It develops trust- As we know nothing could build trusts like regular scrutiny of everyone’s activities and backlogs.
- Investing those 15 minutes every morning saves your time- This seems skeptical as mostly daily standups take longer than imagines as people frequently get engaged in long debates that produce no action items and may not include everyone in the team. Moreover, it’s not a matter of fifteen minutes, it’s fifteen minutes per member, so if you have 4 team members, then it implies one hour of company time. However, it does not finish here, generally, daily standups take place around half an hour after the beginning of your day to offer people time to reach the office. Sometimes, engineers take a longer time as they require hefty blocks of time of constant thinking. And we all somewhere know that most individuals are highly productive in the morning hours. If you get to the office by 9, you will not straight away get into the code thing, as you know that you have to wait a while for daily standup this shows that you may head for a coffee or tea. So, as per this, your company time finishes here.
We are not saying that daily standups are completely useless. Sometimes, you get the most useful stuff out of it while mostly they are a truly wasteful use of your time. Also, several high-performing dedicated teams do just great without daily standups.
Let’s look at the cases where Daily Standups can actually work well
- When you are creating a team or hiring a new team member- Now, it could be a little useful for people to have some thought collecting and starting discussions until team members are not much familiar with all the purpose and work included.
- Weekly or Biweekly Standups- Overkilling is what I get from daily standups, it should be done weekly or biweekly. But, then it would turn into more like a planning or retrospective session and not a daily standup.
- During a tough phase where you require some urgency- You will see here that the importance of daily reports results is useful to ensure things are on track.
- When you have fewer junior developers in your company that you wish to boost their speed
Apart from all this, we believe that meetings are way more useful if done in the right manner. However, we think that meetings should be more specific purpose-wise and where there is a defined value for every team member involved. Also, there should be some preparations before meetings and should contain some action items, otherwise, it would be more of a chatting round.
Scrum has a way to encourage your entire team to learn through their every small experience, self-organize well while still working on an issue, and ponder on their wins and losses to enhance continuously. According to some infamous scrum masters, you need to clear the tickets in Scrums. Furthermore, there would be no actual check on your work quality, which is frequently detected by a non-technical project owner. This complete thing adds on going to the void and concentrating more on outputting mode.
The main goal of the retrospective is basically to reflect. We look and analyze what all worked, what didn’t work well, and what all sorts of experiments we wish to try. Sadly, what it boils down to is making that same effort again and again like “good teamwork” and several meetings in the lanes as “what all went well or wrong”, and “what we will do better”. We believe that retro is now a complete waste of time. If you wish to try more fresh paradigms, then go for hackathons and some practical activities. In a hackathon, collaboration is inherent and you can only go further with good teamwork. Retro lets you get in a room twice weekly along with a repetitive and boring mindset with no dynamism. Nowadays, teams require fresh stimuli, not similar redundant sessions.
Scrum is nothing but the true rival of productivity, and it turns even less sense in the post COVID world. It does not come up with fresh ways of working instead it promotes repetition. Let great development teams organize themselves to their context. Besides, track what gets delivered to production, add the time it took, and then track later on. You need to focus on reality and not those vague burndown charts. Create an ultra-smooth pipeline and remove all the waste. If you need some suggestions regarding daily standups, we at Codersera are there for you to help regarding why scrum has become irrelevant!
- Why Scrum is considered bad?
A deadly flaw in Scrum is that it perceives itself as a hollow thing. It doesn't have its own opinion on how software should be built. Its association with Agile is more of a circumstantial thing rather than intrinsic. Agile involves a set of values and principles and not processes.
- Why Agile is bad?
The most seen issue in Agile is that it completely avoids technical debt, structures like Scrum are like red tape, and the programmers are made to commit to some deadlines and estimates and never get the time to think deeply about the features they are working on.
- Where does Scrum fail?
Scrum will definitely fail if you apply it to your company to change teams. It is an incomplete thing without a willingness to change and will not offer any value to your organization.
- Distinguish Scrum and Agile.
Agile is a philosophy of project management that employs a basic set of principles while Scrum is a particular Agile methodology that is used to run a project.