I came across this post about how Google thinks Agile development is nonsense by Michael Church. You can check out the article here.
Where to start?
Ok, lets start at the beginning. It appears Michael Church has made the leap that Agile is Scrum and Scrum is Agile. That is quite the leap and one that I disagree with. I myself have had a couple of posts on why I don’t believe Scrum to be an optimal method. Of course, I would never say Scrum is nonsense.
What else?
“It’s a culture of terminal juniority. Product development and architecture aren’t the programmer’s job, because they take longer than two weeks. Rather, the programmer works on atomized feature-level “user stories”. This is OK for a junior who’s learning the codebase and software engineering principles and may appreciate the guidance, but anyone with more than 5 years of experience is going to find it to be a dissatisfying way to work. There is no place for an actual senior engineer on a Scrum team.”
I would say that Michael has never been on a well-run Agile team and doesn’t understand User Stories. User Stories are designed to include Architecture issues and deliverables. Certain frameworks like Disciplined Agile Delivery actually formalize this role as well. The two-week limit doesn’t need to be adhered to like a commandment. Some exceptions should be made. For someone who has worked at Google like Michael, his lack of Innovation seems to be adhered to solely for the sake of the article. If the Scrum process doesn’t fit, change it. I find it hard to believe Google doesn’t innovate like this elsewhere.
“It’s aggressively short-term, by design. These methodologies are designed for scrappy, unproven consulting firms that need to bear down and pass their first high-profile project. In that context, they probably work– at the expense of technical debt and tired workers.”
Not sure where Michael gets this opinion. If anything, Agile is the one framework that is focused on sustainable pace and ensuring that technical debt doesn’t get built up and people don’t work excessively. User Stories are not just for user functionality, technical debt gets added there as well to ensure it is addressed as part of the sustainable process.
“It has no regard for the programmers’ career needs or desires. See the points above about Agile’s short-term orientation. Now, people are willing to give up their career goals to pitch in on a short-term crisis, for two reasons. First, if it’s genuinely important to the firm, then it does help their career to do so. Second, a story of having solved a genuine crisis under time pressure can be a career booster. Saying, “I was in the War Room and had 20 minutes each day with the CEO” means that you were important and valued. Saying “I was on a Scrum team” means “Kick me”
Wow. Again Agile is the one movement that talks about respecting people and having people choose what they work on and where their career is going. The concept that Agile is only for short-term crisis mode is a falsehood that Michael can’t seem to let go. And trust me, just being in the same room as a CEO doesn’t mean you were important. It sometimes means he doesn’t trust you.
“It’s micromanagement. User stories and backlog grooming are there to control what the engineer works on. The absurdly frequent meetings (and so many different kinds of status meetings!) are to intimidate him into not slacking. The story points are there to track productivity (in some superficial, inaccurate way). The talk of “removing impediments” is code for “spotting slackers”. Even for people who have nothing to hide– even for people who’d be strong performers in a more sane, relaxed, progress-over-rapidity organization– a surveillance state is an anxiety state. It sucks, and if you’re good at what you do, it’s insulting to have to justify days and sometimes even hours of your time, and to be jerked around if these estimates are even slightly displeasing to the “product owner”
Absurd. Again the developers pick what they work on so there is more control that someone assigning tasks in a traditional project. Michael, I think thou dost protest too much. 😉
“At identifying low performers, it has an unacceptably high false-positive rate. Let’s not kid ourselves. The reason “Agile” is so popular is that it carries this mythology of spotting low performers immediately– in two weeks instead of over months– and giving objective cause to fire them. (Agile/Scrum is, in essence, a permanent PIP.) I’ve heard it put this way: “use Scrum to spot your Scum.”
OK, I think we will leave it there as subsequent points are along the same line. I have never heard of anyone promoting Agile as a means to spot low performers.
I’m not sure what the motivation is for Michael writing this article, but I do know three things:
- Agile is not Scrum
- Michael has not been on an Agile team and would benefit from that context before writing on something he does not know about. Me writing on how Google teams are organized similar the Lord of the Rings Fellowship would be equally as uninformed and wrong.
- The article reads almost like a ‘shot across the bow’ of Agile being used at Google. A warning to not use it or bad things will happen with developers leaving. A good dose of Fear, Uncertainty, and Doubt.
Hate to break it to you Michael, but with Google promoting code thousands of time a day, you are already very Agile! I recommend reading about other Agile methods and suggest changing Agile methods to suit your needs. I know Google has the ability and track record.
BTW, the client engagement and customer focus of Agile may just have avoided that whole Google+ thing…
Just Sayin’
Agile PMO 