I find that Scrum is a lightweight management process. In-and-of itself, it is not agile. But it is (or can be) lightweight. And it definitely can be a win-win, if used in conjunction with agile development. Even in the Scrum guidebook, it intentionally does not prescribe any specific agile engineering practices. Rather Scrum explicitly leaves agile development in the hands of the developers.
Agile development, in contrast, is not as much about the management process. Rather it is about agile engineering practices such as: continuous integration, unit testing, developer centric source control like Git, sustainable pace, test-drive design, aggressive refactoring, SOLID, GRASP, KISS, YAGNI, emergent design, simple design, design patterns, emergent architecture, continuous learning, collective code ownership, coding standards, pair programming, BDD, ATDD, code coverage, continuous deployment, cyclomatic complexity metric, other metrics, domain drive design.
No agile development team will use all of those agile engineering practices. But hopefully they use at least a few.
I’d agree for the most part. In general I was trying to make the point that a team can follow all of those practices but if no one is steering the product in the right direction (either out of laziness or refusing to satisfy the customer) no practice can help you change.
I find that Scrum is a lightweight management process. In-and-of itself, it is not agile. But it is (or can be) lightweight. And it definitely can be a win-win, if used in conjunction with agile development. Even in the Scrum guidebook, it intentionally does not prescribe any specific agile engineering practices. Rather Scrum explicitly leaves agile development in the hands of the developers.
Agile development, in contrast, is not as much about the management process. Rather it is about agile engineering practices such as: continuous integration, unit testing, developer centric source control like Git, sustainable pace, test-drive design, aggressive refactoring, SOLID, GRASP, KISS, YAGNI, emergent design, simple design, design patterns, emergent architecture, continuous learning, collective code ownership, coding standards, pair programming, BDD, ATDD, code coverage, continuous deployment, cyclomatic complexity metric, other metrics, domain drive design.
No agile development team will use all of those agile engineering practices. But hopefully they use at least a few.
I’d agree for the most part. In general I was trying to make the point that a team can follow all of those practices but if no one is steering the product in the right direction (either out of laziness or refusing to satisfy the customer) no practice can help you change.
I fully agree. Someone has to be steering the product in the right direction.
Otherwise...
If you don't know where you are going, how do you know when you get there?
👍