Tag: agile

bookmark_borderDaily at 9 AM

Posted on by kalkus

A software house is not a convenient store. The work can start pretty much at any time. What’s important is that people who perform the tasks together can communicate, meet, and share their thoughts. This flexibility is important because the chronotype is said to be like a human height – you can’t change it without breaking a bone.

What is chronotype?

Chronotype is being a night owl or the morning bird – it’s the preference of the organism to wake up early or stay late. Apparently, in traditionally living tribes it breaks down so that about 25% of the population likes nightlife, 25% morning, and the rest something in between. This would serve the survival of the group because at every moment of the night and day there is someone who watches.

So we have Mark, who gets up at 5 AM and Bill, who falls asleep at 1 AM. Theoretically, they both have flexible working hours and must meet from time to time on a call.

Then scrum master sets up the daily scrum meeting at 9 AM.

Mark is cool, he comes at 7 AM, he will eat breakfast, he will poop, he will browse cat pictures on the Internet and he is ready and fresh for confession from yesterday’s tasks.

Bill, on the other hand, gets up sleepy every business day, because he would like to come at 12 and cannot sleep earlier. Frustration grows, and IQ decreases. He sleeps well only on weekends and holidays. Every morning he’s in a hurry, sleepy at this damn daily and the whole day too. In addition, the team looks at him crookedly. Lazy, late, sleepy, cursed black sheep!

Meanwhile, research suggests that the night owls are more intelligent, not lazy: https://www.psychologytoday.com/us/blog/the-scientific-fundamentalist/201005/why-night-owls-are-more-intelligent-morning -larks

This seemingly unimportant organizational habit – organizing daily at 9 AM – drives the significant part of the team inefficient. How much of it depends on luck, but statistically around a quarter. There’s no reason why daily meetings can’t be scheduled at the end of the day or in the middle of it. It is simply a habit, a ritual that has spread and is mimicked in a reckless way.

To sum up: when organizing a scrum team, it is worth paying attention to the preferences of its members regarding the hours in which the meetings are to take place. This also applies to meetings at around lunchtime, when some people may simply die of hunger because of discussions lasting several hours.

Early daily scrum meetings can reduce the performance of the team as long as any night owls are the members. It is worth remembering.

bookmark_borderWhat happens when the scrum team gets too big?

Posted on by kalkus

Participating in an overgrown scrum team is a fascinating experience. It allows us to observe how the framework collapses under its own weight.

Basically, scrum consists of meetings. Daily stand-ups, backlog refinements, sprint planning, review, and retrospective. These meetings, in theory, can consume even 22.5% of developers’ time. That’s a lot. But as always – it depends.

Image result for office sleep

Observation 1 – meetings get longer

Let’s start with a daily scrum. It should last no longer than 15 minutes. As long as the team is just a few developers big – it’s easy. But when we have 15 devs we can give everyone only one minute to speak. It’s pretty impossible. Either we will destroy the idea of the daily meeting – where the team members can properly describe what they worked on and ask for help (by forcing them to speak extremely short) either we’ll extend the time. In the team of 14 developers, I’ve seen daily scrum to grow up to 25 minutes.

Exactly the same is the situation with every other meeting. But in case of refinements or sprint review, it’s getting even worse because these meetings are naturally longer than daily scrum.

Observation 2 – meetings become full of things you don’t need to hear

As the team grows, the scope of work grows. Naturally – as in any big enough group – the subgroups form up. It can be any kind of division – front-end and back-end devs; people who work on feature A, and another group working on feature B; Java, and JavaScript programmers. When they work on the everyday tasks they almost don’t talk to each other unless they need to discuss some API or contract which is necessary for the parts of the system to communicate. But if the scrum team doesn’t split they’re forced to participate in the meetings together.

Then you find yourself in a meeting where half of the time is spent on discussing the things you don’t need to hear. You’re let’s say a JavaScript developer and last 30 minutes of a meeting was a discussion about back-end, or you’re developing database structure while implementation of the UI of the system is estimated.

Observation 3 – productivity plummets

You want to code. That’s why you became a software engineer. You like to focus, you love to create lines of instructions. This is also why, all in all, you’re getting paid. You automate processes, therefore, people don’t need to be employed to make them manually and the company is more effective. The money saved on automation goes to your pocket. Everybody is happy.

Unless you can’t code.

When the length of scrum meetings get longer it consumes your coding time. When the meetings get boring it consumes your mental energy. You become less productive. Not cool.

That’s why Scrum guide recommends a scrum team to be between 3 and 9 developers. Even if it seems difficult to divide – it’s necessary. The alternative is a small crowd of unhappy, ineffective developers.

bookmark_borderModified agile

Posted on by kalkus

I can’t remember how many times have I heard a word Agile during recent years. We’re agile. We’re doing agile. We’re introducing agile.

It sounds like people dialogues in the kitchen. Yes, I’m going to the gym. Sure, I do cardio. Yeah, I do Crossfit. Of course, I consume supplements. Aero? Every week.

But somehow I can’t see the muscle grow.

The results of this supposed agility I can’t see as well. There used to be chaos and it still is. Estimations have been poor and they still are. The technical debt balance looks like the credit card of a young adult after the summer weekend. Deadlines are scary like cancer and deployments as painful as colonoscopy. And last but not least – the scope is still not flexible at all. But we’re agile!

Are we?

The worst failure of Agile is I believe its promise it can be modified and adjusted. Therefore let’s come back to the analogy of a gym. We are growing muscles. But we don’t take care of the diet because we like to eat. We don’t train our legs because on Fridays we go to the party. We don’t go to the gym when we have a headache.

Then we visit a gym for two years and we still are somehow ashamed owners of a beer belly instead of rock-solid ABS.

Can we be agile if we have a fixed scope? Can we deploy at the end of each sprint if we don’t have the whole organization prepared for it? Can we build better software without showing the client a new version at each iteration? Can we be agile if there’s no client yet, only the budget?

Maybe yes, maybe no.

But for sure if we will modify or remove half of the rules from Agile recommendations we will achieve mess, not benefits. So let’s be serious, responsible developers and not be tempted to eat a cookie when we’re on diet. We can’t eat a cookie and still have it.