A big Enterprise often has plenty of different components. These components might work for One Big Goal but in fact, they don’t interact with one another and don’t affect one another either.
Thus often people who work on such components are gathered into teams in order to simplify resource management. And here the problems begin.
In all such projects I had, Scrum only brought tension and made many people leave after 2-3 months of work.
Let’s see how it happens.
Estimates – we give you no details, now tell us how long it will take to do it
This is Peter. He communicates with the development team about tasks business needs. Peter wants to know when certain features will be ready. It’s a kind of surprise for him when such a question takes a long time for people to respond.
Estimating is one of the most popular holy wars. It’s the dark matter of Scrum – someone provided it but no one knows what it is. If the company decides to hire Scrum Guru the first thing you may hear – “Your understanding of estimates is wrong”.
The problem is in how to define story-point – it’s often said to be some “complexity” level of the task. You should “feel it”. In reality, story points are related to working hours/days needed for tasks. And tasks are re-estimated after some time.
|The whole team agrees on story points for the task because each team member understands the context and the goal||No one understands for which purpose this task is because it’s hard to keep information about 8+ components in mind, everyone still has tasks to do which are not related to the new task. 6 of 8 developers haven’t seen that component yet because they worked on other modules. As a result you forget the context of this task 5 minutes later. Also, you’ve been asked to estimate bug fixes. Ha-ha.|
Sprint – you’re in timeframe you never fit in and they have no sense at all
Peter works in the business department and allocates money for IT department for the new features. A customer comes to Peter and says that there is a very important legal regulation which comes into force next week. Peter wants Scrum Team to implement this feature ASAP otherwise the client will eat him with some fava beans and nice Chianti. Scrum Team responds that they were told by Scrum Guru they can’t break the Sprint and Peter needs to wait 2 weeks. Try to imagine Peter’s reaction and counterarguments.
|You’ll have a well-defined scope and a backlog for at least a month, you’ll plan your work for 2 weeks easily and deliver features on time||You never know what will happen tomorrow. The sprint scope is constantly broken, management has to justify it to clients, developers need to switch the context of work 4 times per day. You’re riding a bicycle. In hell. Which is on fire. And your bicycle is on fire too. And you are on fire.|
Dailies/meetings – team members often are treated as helpless idiots
Meetings are a “must-have” thing in big corporations. Thus everyday work looks more like military service where each step is under strict control. Every single day a development team stands up and reports its Scrum master what they did, what they will do. Then you probably have a meeting for a couple of hours with Peter who tries not to be eaten by customer (see “Sprints” paragraph). Somewhere in between, you may have backlog grooming meeting where you will estimate/re-estimate tasks you personally will never work on (see “Estimates” paragraph). The whole Team participates in each meeting but 80% of members have no clue what is this meeting about. After that, you see it’s 17:00 already and you need to recall what you promised to do on Daily meeting.
|We are a team, we help each other, we know what we are doing and what is the goal, we are a team arrrrrrr!||
“Jenny, you’re on mute”;
“Hey, thi.. is of..ice from Antarc..ida do you …ear us well?”;
“Sorry I was on mute”;
“Guys I need to leave, thanks for informative call (no)”;
what the hell is that I can’t even pronounce that word;
what am I doing here?…
Scrum is not a magic stick. It can’t fit every single project or team. There are other process frameworks like Kanban, Waterfall. Anyway, it’s not mandatory to follow some predefined framework – create your own process your team and client will be happy with. Let it contain elements of mentioned above if needed. Just don’t do some things for the sake of process framework.
Too much concentration on “teamwork” on projects where the team is not working on one product is almost always harmful to each developer.
The best option for such a team is not making everybody work together on something each of developers doesn’t need in the near future. Usually, 2-3 engineers per component is enough.
Participation of the whole team in each meeting will make the team tired very soon. Elon Musk described 3 rules regarding meetings. They are brief and will fit for any big project.
And if the initiative still comes from management it’s usually good to calculate how much money a project will lose if the work is organized in such away.
The main goal of everything here is the result – on-time product delivery, happy customers, happy and mentally healthy team.