Agile Software Development in the Large: Diving Into the Deep
Agile or "lightweight" processes have revolutionized the software development industry. They're faster and more efficient than traditional software development processes. They enable developers to:
*embrace requirement changes during project
*deliver working software in frequent iterations
*focus on the human factor in software development
Unfortunately, most agile processes are designed for small or mid-sized software development projects - bad news for large teams that have to deal with rapid changes to requirements. That means all large teams!
With Agile Software Development in the Large, Jutta Eckstein - a leading speaker and consultant in the agile community - shows how to scale agile processes to teams of 100 to 1000. In fact, the same techniques are also relevant to teams of ten or more developers, especially within large organizations.
Topics include:
*the agile value systems as used in large teams
*the impact of a switch to agile processes
*the agile coordination of several sub-teams
*the way project size and team size influence the underlying architecture
Stop getting frustrated with inflexible processes that cripple your large projects! Use this book to harness the efficiency and adaptability of agile software development.
Review By: Meredith Otto
03/11/2005It is no wonder the software development lifecycle is under pressure to deliver products "faster, better, and cheaper" as the business community and the world markets change according to the demands of consumers. Business organizations then become the consumer part of the equation for the production of software, hardware, and infrastructure solutions.
As a novice on the topic of Agile development processes, I like Julia Eckstein’s provision of the Agile process usage requirements’ outline:
Eckstein went on to warn the reader that these principles aren't to be followed blindly. Obviously processes and tools should help rather than hinder the individuals and their interactions; documentation isn't a party favor for the current project team, it is an artifact for future resources when maintaining, servicing, improving, or sun setting the application. In today’s litigious environment, contracts are a necessity and the reality. And if the team doesn't have a plan to build the software (or one that is used or remotely correct)…well, I think any team member has been in that position before. Not pretty and not conducive to mental or physical health of team members.
Agile Software Development in the Large: Diving Into the Deep does provide substance, but it also promotes silos in software application development. As an important FYI, Eckstein’s definitions of acceptance, systems, and integration tests do not match those provided in the Certified Software Test Engineer (CSTE) Guide to the Common Body of Knowledge. Nor do they make any sense. But the real issue I have is that the book continuously ignores the above requirements of Agile processing (e.g., Individuals and interactions over process and tools).
Overall, this book works with one premise: communication is the key to using Agile development processes for the creation, revision, management activities, etc., associated with successful end-products. Using this topic, Eckstein explores communication and its importance in all chapters. This is refreshing, since communication is crucial to any IT effort’s success. Eckstein does a reasonable job explaining the barriers to using Agile development in large organizations: cultural resistance to change, process overhead, the lack of automated testing tools outside the Unit level space, bottlenecks created by ownership and turf issues, resource constraints, and even the ever-changing need of the customer. I am not sure, however, that any of the content is “new” or groundbreaking in its presentation.
This book needs to be read by testers for a "reality check" on the realized gains of the promotion of testing as both an art and a science as well as how much of our journey still remains. This journey is the continued effort to educate our project teams, our management and our organizations that testing isn't confined to the end of the project or even the end of the creation of a component.