Archive for June, 2009
Get ‘er done
Dave Rooney made an insightful post today regarding what happens in an agile team under pressure. Essentially they revert to their training, or to make it more simple, they revert to whatever their naturally formed programming habits are.
How does [an emergency] apply to software development? Well, consider the poor overworked software developer. They’ve had this bloody Scrum process thrust upon them meaning they have to deliver more, deliver it faster … Near the end of the sprint, this poor developer is running out of time and still has work to complete – they are facing an emergency! So what do they do? They revert to their original training.
What was that training? … They hacked something together that met the requirements for the assignment, and could afford to make it throwaway. Automated tests? BAH!! Simplest thing that could possibly work? … In the end, the attitude is to get something – anything – done in order to get the marks.
This was espoused in a previous workplace of mine as the concept of “get ‘er done.” What upper management was trying to address was an apparent lack of progress and too much time wasted on best practices. What this generated was an urgency of get as much done as fast as possible, and the result is catastrophic. People burn out, product quality takes a nose dive, and in the end, you’re in a worse place than when you started. “Get ‘er done” is almost as ineffective as “get nothing done,” simply because in the end the result you get is so poor that you don’t want it anyways.
This is such a flawed mentality to begin with that it’s difficult to address it; you pretty much have to change the attitude from the top down. Management must be understanding of the time it takes to produce quality over quantity, while developers must be willing to eliminate wasteful activities (that they may not agree are wasteful), and the Product Owners and Scrum Masters must assist the teams with committing to a reasonable amount of workload. This is partially a training issue and partially a culture issue. Training can be used to instruct change, but the participants must be willing to enact change.