My first thought was that working for such a company would be torture.
My second thought was that this basically describes Agile/Scrumm and has taken over the entire industry.
My first thought was that working for such a company would be torture.
My second thought was that this basically describes Agile/Scrumm and has taken over the entire industry.
On the other hand, if your work is a bit more repetitive, it can be a nice way to actually see your contribution change.
On the other other hand, there's the obvious drawback of competition undermining coordination and cooperation among team members, making the experience more toxic, or sacrificing quality for quantity.
Short feedback cycles are good. An employee shouldn't wait 3 or 12 months to find out that they aren't doing something right- it's bad for them and for the company. It isn't a silver bullet, though, and there are better ways to get there.
Sure there are story 'points' for describing complexity in an int and daily check-ins but I thought counting tickets was up there with lines of code produced?
The basic premise of people being simultaneously really good at estimating work and at the same time absolutely garbage at it when you make them use real dates naturally evolves a number system. Make up an arbitrary unit, have people estimate tasks in that arbitrary unit, and behind the scenes without telling them determine the conversion factor for that person so you can plan accordingly. Everything else is just flavor around the core gameplay loop.
Still, the GP wants to know if there are ways of working without assigning “arbitrary” points to stuff, i.e. systematization for its own sake. You can certainly quantify things in a meaningful way for your problem.
While scrum and SAFe may be the right approach when working to find a technical fit to a customer problem, where estimates of “complexity” linearly map to some unit of time (conversation factor). These agile implementations fail completely whenever there are non-trivial, system level, non-functional requirements to satisfy. If you don’t have a platform supporting your work, and you’re in the act of building it, you’re no longer doing programming, you’re doing engineering.
In this case, the “systematization” that can be adopted are knowledge based approaches. DoD systems engineering has adopted “knowledge points” as an approach, which ties work to capabilities, which can be utilized at a program level. Which capabilities you have achieved is a metric that demonstrates work, and ties to things you actually want, as opposed to made up metrics, like points, which really tell you how good you are at estimating, but nothing else.
Other approaches are priority based. If you’re in a more service based environment, where work capacity is constant and goals change, a kanban board can be used to limit work in progress and prioritization can be set by either a risk based approach or a using cost of delay.
The only time I know clearly is when the deadline looms. But the majority of the time everyone around is me cosplaying productivity.