I think you have the same misconception about the first rule that many people do (forgive me if I'm wrong).

> Individuals and interactions over processes and tools

This does not mean that you minimise process and tools. This means that individuals and interactions trump processes and tools. So if you have a process that doesn't fit the people on your team, then you change the process, not the team. Similarly, you try to encourage interactions through as many avenues as you can. You don't say, "You must use this tool and only this tool to communicate".

But it's a mistake to think that you want to remove process. That's not "agile". That's "ad hoc". There is nothing particularly wrong with ad hoc processes if you are successful, but the "we'll just use common sense" approach that many teams attempt is usually anything but successful.

Process is there to support individuals. When I am coaching a team, I never go in with the idea of introducing any particular process. Of course, I am more skilled with some processes than others, but imposing my skill on a team I am coaching is not going to be successful. Instead, I watch what people are doing and write it down. That is the process. At that point I start looking at problems that we can solve. I look for places where the process is not consistent, or where people are struggling because they don't know what to do. Then I try to extend the existing processes so that it is consistent across the team. Finally, I start introducing things that I'm skillful in where I am sure it will make a difference. At this point the team is already delivering with their process and we are just looking at ways to optimise.

There is a lot more to it that this, of course. However, for me this is the minimum thing that you need to do to coach a team. I've tried other approaches (when forced to by upper management), but I've never been successful.

I think process is important. If there isn't some kind of method or process, it isn't really engineering. You can't build modern bridge or building just by going at it.

My comment wasn't clear: scrum is sold the majority of the time as a whole new process and it's seen that way by most, from the minute they do the training.

I've read the scrum book and to me it seems like a process that helps develop your own process. I think that's a fantastic idea.

The problem I'm talking about is that 90% of scrum masters and companies moving to scrum, well, are moving to scrum, as though it's a whole new process as opposed to organically developing new effective processes that fit the company like a glove.

On a smoke break, I heard about a company "doing agile" that's now moving "back to waterfall" after laying off 2/3rds of their team. Another big blue chip I work with also got shafted in a big way by a consulting company that tried "moving them to agile".

What you do is a world apart from what most people attempt and it's the latter that devastates.

> But it's a mistake to think that you want to remove process.

It's also a mistake to keep a process that isn't delivering any benefit though. I've seen very few stand-ups that provided a benefit and zero where there was no other way to get the same benefit.

especially as the team and code grow there's little reason for standups, nobody cares about what most of the other people tells anyway unless they're effected in their goals.

much better to have a team leader who knows the tasks for everyone and warn people when they are operating an area where they can step on each other toes, so that they know they need to coordinate.

the Nx(N-1) rigid reporting structure of stand up makes very little sense

One of the reasons SCRUM wasn't very popular in our team was that we realized it meant having a lot more meetings than we were having before. I think if you go by the numbers, standard scrum has you spending nearly 20% in your time in developer meetings.

Stand ups didn't really work for us either as we are doing our own thing most of the time, so there is little to coordinate, and when there is a need, we usually just work closely together.

Capital-A-Agile puts a lot of emphasis on very fine-grained collaboration and reducing the amount of time people are "doing their own thing". Some advocates are pretty open about this being a form of micromanagement[1].

Some people thrive in high-visibility, fine-grained-collaboration environments. On the other hand, if you've got people who are already doing good work without many meetings, it's hard to see Scrum-flavoured setups being anything other than intrusive.

[1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...

That's what turned me away from Scrum. When you do something really difficult you end up reporting the same thing for weeks. Or you feel you shouldn't even try something difficult because you can't break down into little daily chunks.

I prefer my people solve difficult problems and not just little bite-sized tasks that only touch the surface of the system.

Micromanagement is indeed what it looked like to me with all the daily stand ups (what did you do yesterday), review meetings (what did you do last week ?), scoring (what do you mean it would take you longer than that other developer to finish something ?) and sprints (we HAVE to do this THIS WEEK).

That's certainly what it can be used for and probably is on a large scale.

The most important one that a lot seem to miss is the "did you face any road blocks?", with a culture where the whole team thinks and removes the roadblock such that it is removed for everybody for good.

Morphine is a pretty damn good painkiller. Unfortunately, it is extremely easy to abuse to the point where there are more people abuse it than people who genuinely benefit from it.

On a larger scale, communism as it was originally conceived sounds like a utopia. Unfortunately, the only thing that's actually happened is an abuse that takes anything from democracy to authoritarian regimes well towards totalitarianism, the anti-thesis of communism.

Scrum and agile is the same in that respect. Sounds great. Works well on paper but very rarely used correctly or with the original intention.

That blog post is really odd. It's like "sure you're being micromanaged, but its by a mob instead of a tyrant", as though thats a comforting thing. How is that better?! You cant just throw the word "team" in there and pretend it makes things ok.