I used to roll my eyes when proponents of a certain methodology, when confronted with failures of projects using that methodology, would say things like, “You’re doing it wrong! If you would just perfectly execute every suggestion in this book I’m selling, you wouldn’t be failing.” After a while you start to wonder if it’s so hard to do it The Right Way then maybe there’s a problem with the methodology itself.
Lately, I’m come across several posts from writers I respect criticizing Scrum and “Agile” methodologies as micromanagement and as ways for authoritarian managers to assert themselves over development teams
Scrum's standups are designed to counteract an old tradition of overly long, onerous, dull meetings. However, at both these companies, they replaced that ancient tradition with a new tradition of overly long, onerous, dull meetings where management got to sit down, and everybody else had to stand. Scrum's attempt at creating a more egalitarian process backfired, twice, in each case creating something more authoritarian instead.
My personal experiences with “Agile” teams have generally been good. By the time I entered the industry in 2005, Agile ideas had spread considerably and I can’t say that I’ve ever been in a software organization that was doing Waterfall.
But, I have seen dedicated micro-managers when required to “do Scrum” turn that daily standup right back into their familiar morning status meeting where the team one by one turns to the highest ranking person in the room and reports their status directly to that person. What I won’t do though is ascribe this phenomenon as a failure of Scrum as a methodology.
Just like any large body of literature, one can essentially read anything they want into it. As I said in a previous post, I believe that Agile is a philosophy akin to egalitarianism. And at its core it’s about self-organization.
In Succeeding with Agile, there’s a good quote from Jean Tabaka:
I work primarily with Scrum teams, and those that struggle the most typically have a command-and-control project manager or a decision-oriented technical lead as ScrumMaster. Without a facilitative, servant-leader mode of team guidance, the agile adoption will be only a thin veneer over non-empowered, demoralized teams.
One of the saddest things to see is a software organization where people at the top have convinced themselves that what matters about the methodology du jour they have cast upon their people is the list of practices associated with the methodology. “If I see my people doing these practices, then I’ll know they’re embracing the methodology.”
But the practices mean nothing without the philosophy. A team can do planning poker sessions until they’re blue in the face, but if they’re working under a manager that believes he knows better than the developers how long their work will take, the whole exercise is pointless. Any practice can be letter-of-the-lawed and still give you no benefit.
Author of the popular book The Art of Agile Development, James Shore, explains in a post from his blog:
Agile development isn't just about good engineering practices. It's also about acknowledging the importance of people in software development, forming cross-functional teams, obtaining high-bandwidth communication, constantly reflecting and improving, delivering value, and changing plans to take advantage of opportunities.
Scrum includes these other points. It says that the team should be cross-functional and recommends collocating the team in a shared workspace. It says the team should deliver a valuable, shippable product at the end of every Sprint, and that the team should self-organize, discover impediments, and remove them.
Oh, and it also has a few mechanical things about a monthly Sprint and daily Scrum. Trivial stuff compared to the rest. But guess which part people adopt? That's right--Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.
If you want to benefit from a particular methodology, whatever it may be, people must buy into the philosophy first, or don’t bother.
0 comments :
Post a Comment