3 ms·

Creating, optimizing and tuning "processes" with a help of buzzword bullshit is a bread and butter using which the certain layers of management justifies their,

by gesman 13y ago

Creating, optimizing and tuning "processes" with a help of buzzword bullshit is a bread and butter using which the certain layers of management justifies their, otherwise worthless existence. Developers often find themselves interrupted by needs to participate in processes that are necessary to "track or improve the progress" instead of focusing on making the actual progress happen.

ebiester 13y ago
It depends. Is an hour meeting every other week saying, "We tried thing A, it went badly. Let's modify A or stop doing it, instead trying thing B." At the end of a project, do an overall retrospective, and perhaps make changes for the next project. Small, incremental experiments and changes are great for process improvement. They can even feed up the chain and promote cross-team experiments, so long as there isn't a top-down directive to implement new thing B at the same time. Do experiments, keep what works, discard what doesn't.
UK-AL 13y ago
Its not about tracking for the sake of tracking. Its about finding problems in the development process and improving them. Its helps identify problems, and once identified you can make adjustments and fix it. In our sprints people can 'flag' stories if something is slowing them down, and normally you find it's consistent issue with multiple stories. If you remove it, then you have a instant productivity boost. When we implemented scrum we found a lot of stories were going back and forth between requirements and development stages, so we knew where the problem was. It's also about guidance. The people implementing the project, probably don't have accurate representation of customer value, only the customer does. Teams often have vision of how things should be, but normally its inaccurate and you implement things with the wrong priorities. The constant feedback from the customer helps ensure the right things are being worked on.

by gesman 13y ago

ebiester 13y ago

It depends. Is an hour meeting every other week saying, "We tried thing A, it went badly. Let's modify A or stop doing it, instead trying thing B." At the end of a project, do an overall retrospective, and perhaps make changes for the next project. Small, incremental experiments and changes are great for process improvement. They can even feed up the chain and promote cross-team experiments, so long as there isn't a top-down directive to implement new thing B at the same time. Do experiments, keep what works, discard what doesn't.

UK-AL 13y ago

Its not about tracking for the sake of tracking. Its about finding problems in the development process and improving them. Its helps identify problems, and once identified you can make adjustments and fix it. In our sprints people can 'flag' stories if something is slowing them down, and normally you find it's consistent issue with multiple stories. If you remove it, then you have a instant productivity boost. When we implemented scrum we found a lot of stories were going back and forth between requirements and development stages, so we knew where the problem was. It's also about guidance. The people implementing the project, probably don't have accurate representation of customer value, only the customer does. Teams often have vision of how things should be, but normally its inaccurate and you implement things with the wrong priorities. The constant feedback from the customer helps ensure the right things are being worked on.