A blog on Agile software development and Scrum
There is a growing consensus that the Scrum community should do a better job of promoting Agile engineering practices along with the project-level guidance provided by the Scrum process. I agree.
But I feel cautious about a debate that seems based on the assumption that any Agile technique is the de-facto standard for developing software. It's true that Agile has been around for over a decade, but its adoption isn't a given. Many development teams have a fundamental misunderstanding of what Scrum is and what it accomplishes. There is a majority of developers openly scornful of Test Driven Development. Both "code and test" and Waterfall software development lifecycles are alive and well in the software industry. Which leads to the questions:
- How can Agile practices (including but not limited to Scrum) be adopted in situations where the highest-placed managers in a company demand software within extremely aggressive deadlines?
- How can Agile practices be adopted by teams that do not perform a continuous cycle of new development, such as those whose sole purpose is to reproduce and debug customer issues?
Many software engineers think of software as something that must stand the test of time in terms of performance, scalability, and maintainability. Business personnel seem to think that software is a disposable commodity meant to generate revenue for a period of time and then be replaced. It explains the unrealistic deadlines, the emphasis on developer specialization, and the lack of emphasis on collaboration, cross-training, and many Agile tenets.
Developers who excel in this kind of environment seem to feel that Agile methods are for intranet software (software used within a company), while "real" software - revenue-generating customer-oriented software - is something that groups of experts produce as quickly as possible before moving on to the next revenue-generating activity.
Agile cannot become a practice of the majority of software developers until it can convincingly dissuade people from the "disposable software" mindset. As practicioners we all know that disposable software is a fallacy, that maintenance is a large but avoidable cost, and that reuse is nonexistent for hastily produced products. But by promoting Agile or Scrum as an efficiency technique, both lose persuasive force when the efficiency doesn't materialize. Misrepresenting Agile will be the primary reason its adoption loses momentum.
So I'll end with a two final questions:
- How can a team measure if its development efforts are both Agile and employ sound engineering practices?
- How can Agile be explained in an accurate way that describes its benefits to sceptical developers and/or revenue-focused non-developers?
It's my hope to come up with some attempts at answers for these questions, but I'd love to know if anyone already has the answers.
Technorati tags: Agile Scrum