> In the end, it's not the process you follow, it's the results that matter.
I was nodding along with this post up until this last sentence.
Yes, the results are what matter, but process is what drives the results. It is thus critical to the success of a project to ensure that the process is appropriate.
For example, the entire purpose of agile is to have short iteration cycles where you deliver to customers and get feedback before starting the next cycle. If you have a product where you cannot get feedback, agile is a bad solution! You will deliver every two weeks - and then continue to do what you would have done anyway. That makes all the agile ceremonies quite the waste of time.
Conversely, if you ARE getting feedback regularly it's insane to do waterfall when you're two weeks into a 6 month project, and the customer doesn't like what you're showing them.
This can get a lot more detailed at the micro-level for managing process on teams - there are tradeoffs between developer happiness, speed, quality, visibility, and many other axes that process can adjust, and a team that is set up with good process will be set up to execute better than one that isn't.
I tend to be someone that is perceived to "hate process", but I don't, I hate bad process that is counterproductive to execution and achieving results.
I was nodding along with this post up until this last sentence.
Yes, the results are what matter, but process is what drives the results. It is thus critical to the success of a project to ensure that the process is appropriate.
For example, the entire purpose of agile is to have short iteration cycles where you deliver to customers and get feedback before starting the next cycle. If you have a product where you cannot get feedback, agile is a bad solution! You will deliver every two weeks - and then continue to do what you would have done anyway. That makes all the agile ceremonies quite the waste of time.
Conversely, if you ARE getting feedback regularly it's insane to do waterfall when you're two weeks into a 6 month project, and the customer doesn't like what you're showing them.
This can get a lot more detailed at the micro-level for managing process on teams - there are tradeoffs between developer happiness, speed, quality, visibility, and many other axes that process can adjust, and a team that is set up with good process will be set up to execute better than one that isn't.
I tend to be someone that is perceived to "hate process", but I don't, I hate bad process that is counterproductive to execution and achieving results.