SCRUM monks

one upon a time one of higher managers of one of the corporations ruling this Earth's telecommunications heard somewhere about SCRUM – the agile approach to software development. now imagine huge project with tens of developers spread around sites, dealing with their components using vendor-specific-incremental-waterfall for their work. after 2 years of separation, all components were meant to move to SCRUM. just like that.

despite overall implementation results (which has not yet been decided whether funny or sad) one of main principles came across my mind: technical excellence. it's great and should be always true, i.e. ppl who does not know what software development is, should not touch it, but what about practice? in many cases new corporate employees are hired because higher management came to terrifying conclusion: “if there will be more of us, we'll have higher position on the market and develop faster!”. it means of course that technical level on many sites is at most average. this implies lower technical skills, far from “technical excellence”.

agile is all about smart ppl doing smart things and managers not disturbing them with their brilliant “technical” ideas. but what if such a new SCRUM team will agree upon creating loose poo (see http://bajs.vmh.net) instead of actual software? most cases they will even not be aware of it… what about cooperation then? when most of equaly-important-developers in SCRUM will not agree to do nice work but will code shit instead development dies…

it's so corporate way – lets hire 3 ppl with lower earnings than one with 1.5 of regular payment, but who really knows what (s)he's doing…

see also: agile manifesto, be agile! sir, yes sir!.

blog/2009.07.06.txt · Last modified: 2021/06/15 20:09 by
Back to top
Valid CSS Driven by DokuWiki Recent changes RSS feed Valid XHTML 1.0