Can Scrum and Lean principles ruins the life of professionals?

Question

Hi There, I work with scrum about 2 months and don’t have all the experience I wish, so I would like to hear some inputs about it.

My concern is people never say about drawbacks for the two sides; company and workers. I know the benefits of a cross-functional team but which are the drawbacks? What is hidden beside the amazing Eden Garden?

I'm confused because as a company benefits of replaceable people, for the team is good because the opportunity of having knowledge and share experience (besides all teamwork benefit).

Again, I know all the benefits but I want explore the drawbacks just because in the middle there are the ordinary people. Normally these people dedicate heavily to gain knowledge. They buy books, courses, attending seminar and so on.

In every company when someone knows much more than everyone else, people and managers get desperate wishing or even demanding that these ordinary people share all their knowledge.

And that’s strange.. Because these are communism thoughts and we live in capitalism society and since I was born, everything was so competed and now people say about collaborative.

Can Scrum and Lean principles ruins (or making hard) the professionals' life?

Answer 1

I'm not totally sure of the question because it was kind of hard to follow.

Basically... no? I fail to see how an agile principle could 'ruin a professionals' life'... if implemented incorrectly it could waste some of their time, meaning a small lack of experience gained. Other than that, if the methodology fits the business and is implemented correctly, then is is a powerful tool that is useful to everybody.

Any methodology only works if the people are competent.

Silly question imo.

Answer 2

I'm no expert in any particular methodology (Agile, Scrum, etc.) but I empathize with your feelings. One of the biggest issues I've seen is that a team that really isn't interested almost unanimously in the methodology will tend to have problems. A few outliers isn't a problem, but if 1/3 or more of the team isn't interested, it becomes a nightmare. Writing good software is important and a company should hire professionals that help them meet that goal, but if the team is forced to meet that objective without finding the experience rewarding the quality will soon drop off.

No, I don't think it will ruin your professional life, but it can be pretty miserable if a company is pig-headed and doesn't realize that they need an environment where their workers are finding rewarding work.

Answer 3

Scrum and Lean, in and of themselves, cannot ruin anybody's life. Nor can they, alone, make your life.

The culture of your organization will always be a far more dominant factor than the particular product management or development management method in place. Scrum can be misused. Lean can indeed make workers feel replaceable and pressured to perform all day, all the time.

On the other hand, both tools (they are just tools) can be used to create high-performing teams where all members value each other and each others' contributions. Being on a team that delivers consistently good results at high velocity feels great.

You will also find every result in between. It depends much more on culture than process.

I believe that culture flows from the top. Therefore, look at how the company leaders treat each other, their subordinates, their vendors, and their customers. That will tell you much more about what your life will be like than which methodology the company follows.

Answer 4

I've certainly seen things packaged as Scrum and Lean make the development process more difficult. Usually the result of managers picking and choosing the aspects that support their purpose, without buying in to the underlying spirit. Any process can work if properly applied, and process can fail if applied poorly.

Answer 5

I'm only going to address your comments about sharing knowledge reducing your own value. In an ideal team culture, knowledge itself isn't as valued as someone's ability to acquire new knowledge and solve problems they haven't seen before. When I think about the star engineers I have known, it's not because they know this or that, it's because it's obvious they could be on nearly any task, on nearly any team and they would both begin to solve the problem and raise the level of the entire team.

Answer 6

There are a few things I've seen from agile methodologies which I'd put against it when you're weighing it up.

From a developers perspective there are two things:

1) The short sprints often lead to short term decisions - which is as intended but can be frustrating for some developers. While delivering "just enough" is great for the project, asking a developer to do something that they know that they're going to have to very heavily refactor, if not rewrite, two sprints down the line can be demotivating.

2) Where you've got opinionated developers (and is there any other sort) I've seen conflict over prioritisation. Adding not only what should be done but how important it is and therefore when it should be done brings on a whole other level of disagreement. In theory the developers don't have a say here but hard delination never works.

From a management point of view they don't like the uncertainty. "When's it going to be ready?" "No idea, when we get to the point you say you're happy". Essentially for them it's a leap of faith - if they do it once then generally they're sold but getting them to do the first time is hard.

Answer 7

I will assume, that as one commentator suggested, you meant to ask: "What are the drawbacks of Scrum?"

I think that the biggest problem with Scrum is that it is easy to understand - but very difficult to implement properly. Scrum, like XP, like most methodologies is not built on individual atomic practices, each capable of improving an existing process. Scrum requires a shift in the organizational mindset. It requires a shift from ego-centric to communal behavior. The entire organization should focus on bringing the most value, constantly, and do so over perceived self-interest. For example, a cross-functional team member may be required to do things out of his comfort zone (the flip-side of being able to experiment with new interesting tasks), because it needs to be done by somebody. Team Leaders and project managers need to relinquish authority when they are called to take on the role of servant-leaders, and when they are asked to stop telling team-members which tasks to pick, instead relying on the team to manage itself. Stakeholders are forced to face the reality that they can't eat the cake, and have it whole, when they are forced to choose between having all of the scope they want or having it by the date they want it done (this is always true, but Scrum is really in-your-face about it).

Most of all, the drawback of Scrum, is its tendency to disillusion beginning practitioners. This comes from people expecting something from it that it can't deliver: A solution to their problems!

That's right! Scrum does not solve an organizations problems. It highlights them. It is up to the organization to step up to the bat and do something about them. Incidentally, this is done with what I consider to be the single most important ceremony of Scrum - The Retrospective! If you do nothing else in Scrum - do the retrospective:

• Find out what you did well, and continue doing it.
• Find out what you need to improve and do something to improve it.
• Rinse and repeat!

In a presentation by Ken Schwaber to Google on Scrum, he once said that Scrum isn't necessarily good for the organization. It could tell you early on that your project is doomed to fail. If you avoid Scrum, you may have a few more months of ignorant bliss to prepare you for the day you lose your job. Funny, but true. Think on that.

Hope it helps, Assaf.

Answer 8

Cross-functionality isn't a means to make people replaceable. It's a means to solve flow bottleneck problems that decrease productivity.

Cross-functionality doesn't mean that everyone can do everyone else's job, it means that people are capable of assisting with the work step that come (immediately) before their work or (immediately) after their work.

A better term for this is "Local Generalization", or "Special Generalization". And again, the goal has nothing to do with making people more removable from the organization. Creating the kid of people who can use Local Generalization to their advantage costs a lot of money in teaching and guidance. Once an organization makes such an investment in a worker, they're even less motivated to remove them. And organizations tend to only make such investments in people that they already want to keep around.