I had the opportunity to take a class on Agile development recently, Scrum, and it was a fascinating way of doing development. I have been pretty lucky over my career that I have not been dragged through a lot of heavy development processes. Yet, while working on some projects I have experienced the joys of slow processes, excessive meetings, indecisive users, as well as plenty of scope changes. Management would blame us if we didn’t deliver on time something that was completely different than their original program.
Initially while sitting in my class I was thinking that Scrum might be the solution to all those problems.
No specific due date is given for delivering on those features, just a series of releases each with more functionality than the last. There is no real penalty for change, well not for the developer; Perhaps for the product manager depending on the company culture. You even have your own advocate to deal with either incidental or structural problems.
About the time that I was convinced Scrum was the solution to all problems everywhere that I started to have a few doubts. I personally am not a big fan of writing up specifications or user documentation and the people have a tendency to not read it much either. This much unloved type of documentation is however requested by auditors.
I asked about this in class and oddly enough documentation was not one of the artifacts of the process. Sure, you could define “done” to include this but developers are not natural writers and from a productivity standpoint you would really want them to write code. What about adding a layer around the scrum team of technical writers?
That might be just as bad as not doing scrum in the first place. You will have a constant flow of people waddling over to the developers breaking their concentration.
Then why does Scrum work?
- The developers set their own due dates rather than management
- A product manager is available to answer all questions about the tasks being developed
- The product manager can make decisions regarding the direction of the product
- The number of meetings for the most part are all defined and limited
- The developers are expected to be capable, independent and have courage
- The scrum master is dedicated to eliminating impediments to team progress
- The list of features have been ordered by priority and the important ones should be well defined.
The transparency helps management to realize that with the resources in place some of their requests are not possible.
What development methodology wouldn’t be better with these as preconditions? If you have dedicated group of smart people doing the work who are able to get feedback on their work along with someone fighting to remove difficulties then you will see good results.
Just like all other processes in the world the better your inputs the better your final results. These results could be faster, smaller or less bug laden. I guess this could be summed up with use better staff and try and stay out of their way … well, that’s my thoughts on agile.
