Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^7: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship (terrible)

by eyepopslikeamosquito (Chancellor)
on Jun 14, 2015 at 06:24 UTC ( #1130347=note: print w/replies, xml ) Need Help??


in reply to Re^6: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship (terrible)
in thread Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship

I originally asked was "On the ground, in practice, what is achieved by the Agile process -- stand ups, sticky notes et, al -- that isn't (not can't be) achieved without it?" ... I might get a straight response from eyepopslikeamosquito
OK, the straight response. In summary, I mostly like small-A agile ideas, usually strongly agreeing with anything written by Alistair Cockburn and Martin Fowler, for example. Schwaber and Sutherland, not so much. :) I also like lean ideas, and it should go without saying that I do not endorse "waterfall". I'm astonished at how many agilistas trot out the tired old "waterfall" strawman, given that even the original 1970 paper "Managing the Development of Large Software Systems" by Winston Royce cautioned:
"the design iterations are never confined to the successive step" and model without iteration is "risky and invites failure"

I do not like Scrum. To me, there is little substance, and too much unnecessary and arbitrary ritual and dogma. To answer your question directly, there is nothing that can be achieved with Scrum that you couldn't similarly achieve with any other agile or lean or iterative framework, home-grown or otherwise. I like the look of Crystal Clear by Alistair Cockburn, for example. Unfortunately, mainly due to clever marketing, Scrum has become the dominant branded Agile framework. BTW, when I suggested we try Crystal Clear at work, this was rejected. I also had some ideas for a team-specific home-grown agile process but this was similarly rejected. Given that Agile exhorts you to "empower and support" rather than "command and control", I felt the command-and-control "you must use Scrum" commandment ironic ... which also explains the use of the word "imposition" in the title of these articles (see also Agile Imposition by Martin Fowler).

As for my personal experiences, to spare you having to read all eight parts of this series, I've extracted a few relevant anecdotes in this reply. From part I:

When I suggested team-specific adjustments to their process, it was implied that I "didn't get it" and that I'd benefit from attending another Scrum training course, maybe one day even attaining the coveted "Certified Scrum Grand Panjandrum" title. I felt sad and alone, a lowly novice in this new religious order.
During that early "evangelistic era", most of the folks around me seemed to be behaving like the guy in the photo at Going Agile Can Hurt Your Company by Ovid. I felt sad and alone, ostracized by this new religious order. I felt I had lost power and my opinions were not respected any more. In the old order, my technical skills helped to win respect from my workmates. With the agile revolution, Scrum knowledge suddenly was more highly valued than being able to actually write code.

I noticed that the mediocre programmers jumped on this bandwagon with great relish because now, instead of being powerless due to their poor technical skills, they become powerful due to their Scrum passion and knowledge. They tenaciously pestered their bosses to pay for them to attain the prized "certified Scrum Master" (for connecting butt to chair for two days). I was, and remain, an avowed certification skeptic (see, for example, Re^2: Selling swimsuits to a drowning man) and have always refused to attend any certification course on principle. BTW, I feel that clever marketing, such as certified Scrum Master courses and all the rituals and new words for old things, is the primary reason why Scrum became the most popular of the branded Agile frameworks.

From part II:

My new desk in the agile commons was situated next door to our internal systems team. And boy was it drafty! All day long, I listened to them responding to support calls and joking around while doing so. And they often built new PCs, so there was a constant whirring from new PCs under construction. Within a week I wound up with a nasty dose of tinnitis. While the improved (osmotic) communication within our team was certainly welcome, the elevated noise level, drafts, and constant visual distractions were not. I felt like I was living in a fish bowl, which reduced my general level of psychological comfort and well-being.
When I complained I was finding it hard to concentrate it was implied there was something wrong with me, that I should instead embrace all the extra noise and visual distractions because "it is more agile". It seemed saying something "was more agile" automatically won you the argument! That is, "agile" had become a synonym for "good". Madness!

Each project's ecosystem is unique. In principle, it should be impossible to say anything concrete and substantive about all teams' ecosystems. It is. Only the people on the team can deduce and decide what will work in that particular environment and tune the environment to support them.

-- Communicating, cooperating teams by Alistair Cockburn

Following Cockburn's advice, I lobbied hard for allowing teams to tailor the process to suit the way they liked to work, but this was rejected in favour of a "one size fits all" approach.

From part V:

As you might expect, the early meeting time slot was causing some unwelcome stress within my team. Sometimes a train was late or cancelled. On other occasions, family duties, such as taking a child to school, caused team members to be late or even to miss the daily meeting. And this stress was not reduced when agile coaches proposed the imposition of humiliating punishments or fines for being late to the daily meeting.
I could go on, but you get the picture. At a personal level, I struggled with Micromanagement-like aspects of Scrum and felt that it harmed my psychological well-being and may have contributed to a worsening of my anxiety disorders. Though it hadn't been written back then, I can therefore relate to this quote from Michael O Church:

Scrum induces needless anxiety about microfluctuations in one’s own productivity. The violent transparency means that, in theory, each person’s hour-by-hour fluctuations are globally visible– and for no good reason, because there’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. For people with anxiety or mood disorders, who generally perform well when measured on average long-term productivity, but who tend to be most sensitive to invasions of privacy, this is outright discriminatory.

-- Why agile and especially Scrum are terrible by Michael O Church

  • Comment on Re^7: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship (terrible)

Replies are listed 'Best First'.
Re^8: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship (terrible)
by BrowserUk (Pope) on Jun 14, 2015 at 08:51 UTC
    As for my personal experiences, to spare you having to read all eight parts of this series,

    I think I have read them. Or at least scanned most of them. I enjoy reading your articles; even if I'm not really that interested in the subject matter.

    Eg. I enjoy a good game of code golf. Up to the point where shedding the extra character come down to spotting (or knowing) that you can game the syntax in some obscure way to shave a point or two. I enjoy looking for an alternative approach to solving the problem that leads to a shorter solution; but I could never get into the whole running iterations for hours or weeks to discover magic numbers to shave another point. But I thoroughly enjoyed reading about how you went about it.

    I felt sad and alone, ostracized by this new religious order.

    I've seen that happen on two occasions.

    Since the abrupt end to my second ever programming position was brought about by a non-software manager, taking the advice from a 4GL team leader about the very complex and very low-level (C and assembler) re-design of a system I had been brought in specifically to do, and which he -- the 4GL guy from a different division -- clearly hadn't even the most basic understanding of; I chose not to be an employee ever again in my career.

    (*I've posted more details of this in the distant past; but basically, I estimated a total cost for the project of £30,000 (1980s), and added 25% for contingencies: £40,000. The 4GL guy didn't understand a word, but applied his rule of thumb and doubled my estimate. The non-software manager applied his rule of thumb (x 2 1/2) to that, and arrived at £1/4 of a million. Four programmers including me took the jump later that same day.)

    Since then, I've never been an employee who could be forced to be subject to such impositions; but as an independent contractor, I have been subcontracted to companies that ran under similar (but older) methodologies, and seen how they can change the nature of a work place entirely.

    Though it hadn't been written back then, I can therefore relate to this quote from Michael O Church:

    My brother, a post-sales support specialist (a salesman with pretty good general technical knowledge) who lives and works in the US; recently took his options and sold his stock (at something of a reduced price) in order to effectively buy his way out of the company he helped build.

    His reason was mostly down to watching the changes wrought to the company by the zealous imposition of Agile (sounds like a scrum-like variant; but I don't know the details) by a newly hired (more co-partnered) CTO.

    His words were something along the lines of: I got sick to the stomach watching the programmers and analysts, senior and junior -- many of whom had been around for most of the 7 years of the company's existence; and most of them good friends and trusted & talented professional colleagues -- being forced into performing ritualised self-humiliation to atone for the "technical debt" they had "lumbered the company with". It was more than he could bear and he effectively bought his way out of the company rather than watch it happen.

    That was late last year, so when this installment popped up; my previous passing interest and shallow distaste based mostly upon a gut-feel dislike of what I read about it; became more focused. Hence my question.

    I've got a half-written outline of my viewed-from-the-side-lines opinion about what I read about agile/scrum/et.al (and yes; that says that I don't really know the differences), kicking around on my hard drive somewhere. If you think you might be interested I could look it out, clean it up and finish it.

    Thanks for your reply. It makes for interesting reading and confirms some of my feelings whilst perhaps weakening others.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1130347]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (8)
As of 2019-05-20 11:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you enjoy 3D movies?



    Results (128 votes). Check out past polls.

    Notices?