Agile and Hyperproductivity
Apr 14, 2012 22:10 · 266 words · 2 minute read
I was wondering around my office, which is housed in a co-working location, when I saw on a whiteboard in another company’s office, “Agile: Hyperproductive!” As an engineer type, I had to restrain myself from going in and telling them they were wrong, but I do have some thoughts on the subject.
I like Scrum. I think in the future for most teams, Scrum and similar processes won’t be controversial. They’ll just be how software engineers do things. That said, it’s not going to make you more productive. Its sprints have a higher overhead with daily standups, retrospectives, planning, and grooming meetings. The smaller the sprint, the higher the overhead is.
I’ve seen claims that Scrum will increase productivity by 800! That is incredible. And unbelievable. Are people typing faster? Are they designing faster? My speed of implementing is the same whether for waterfall or Scrum.
With the additional overhead of more meetings, you’re arguably *less* productive compared to an ideal waterfall scenario. But that’s okay, because a development cycle that doesn’t run into issues is a myth. Either a design flaw was found, or the business requirements changed, or some key player leaves. Something will happen, and Scrum’s smaller cycles deals with that better than a waterfall process.
I truly believe the team will come out ahead, although the sweet-spot of the best sprint length is different for all groups. I’ve worked with sprints from weekly to tri-weekly in size and it really depends on the culture of the project.
Just don’t say Scrum makes you more productive.
A nice, hype-free look at Scrum meetings.