Agile Thoughts
I mentioned the book Drive: The Surprising Trube About What Motivates Us last time. I got that book from a reading list from Allen Holub, who I suppose is an Agile thought leader. I watched a couple of his videos on YouTube, as recommended by folks at work. Both are linked on his website http://holub.com.
The first was “The Death of Agile”. In this, he discusses what Agile is and isn’t, and makes a pretty decent, or at least loud, argument against using Scrum. His argument is that by using Scrum, you are basically putting a structure to the work, and that is really not what agility is about. Stories and Sprints are really just ways to push project management down into the teams.
The second was “#NoEstimates”, in which he argues against making time estimates for tasks. Estimates, he loves to say, are really just guesses to begin with, they’re never really right, and things change quickly that affect the estimates. In essence, spending time creating estimates is a waste of time in the literal sense….programmers should be programming and not doing anything else.
I won’t break down these arguments individually, as they both seem to me to lead to a similar conclusion. Mr. Holub, for some reason, thinks programmers are all hard-working, eager-to-please people who shouldn’t be burdened with anything that they need to be held accountable to later, other than making working software. In an ideal world, SURE! It would be great if every programmer wanted to do nothing but churn out awesome code and do awesome things, and in such a world, they could just go to work every day and do what they need and go home. But that’s simply not how the world works.
I’m not always onboard with the old addage “It can’t be improved if it can’t be measured”, but in many cases, it is true. Unfortunately, not every programmer is a rock star. A task that may take one programmer a day may take another one two or three days. One programmer may be very detail-oriented and leave very few bugs, while another may be better at finding new ways to do old things! People are just different.
Businesses cannot just hire a bunch of programmers because the programming manager says she needs more. Businesses cannot hand over a slush fund of money and tell the team to use it as they wish. If programmers are working 15 hour days to get the work done, and there is no method of tracking that effort, more programmers cannot be hired nor can the workload be scaled back.
All this said, there are a lot of things I agree with Mr. Holub on. I do think that having daily meetings for updates is overkill. I agree that the project management methodology is not well-suited to software development teams. I agree that it is more important to get the work done right than it is to meet an arbitrary deadline or to keep a burndown chart looking nice. I agree that the role of the manager in an agile organization should be to enable the staff to build the best product, both by having a hand in people-development and by clearing obstacles keeping them from reaching their potential. I even agree that counting the stories is a sufficient way to determine workload.
Still, his belief that a team can completely manage itself without having to make any time estimates to be held accountable to is just too idealistic. There have to be numbers to go by, and the stories have to be estimated so the working periods (sprints or whatever you want to call them) can have a balanced amount of work assigned. Without the numbers, the business cannot be held accountable for assigning too much at once nor can they determine the need to hire more people.