4 ms·

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 t

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.

flukus 10y ago
> 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.
- LoSboccacc 10y ago
  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
jwdunne 10y ago
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.

flukus 10y ago

> 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.

LoSboccacc 10y ago
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

jwdunne 10y ago

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.