Featured Whitepapers
- Apples, Oranges, and Acorns - All Agile Development Tools Are Not the Same
- One's Enough for Agile Application Development Management
- Requirements Management 101 – 4 Basics Everyone Should Know
- Tips on Requirements Traceability – Learn How to Control Change and Improve Quality
- Scaling Continuous Integration to Large and Distributed Teams
|
Agile Methodologies - September 2010
Many enterprises and teams that aren't already applying agile-lean product (system-software) development are interested in doing so. But many of these enterprises and teams aren’t completely clear about what agile adoption really entails. As a result, enterprises and teams that adopt agile-lean product development are often surprised by the amount of change that's required. This edition of the Agile Journal answers frequently asked questions about agile methodologies and processes and what it really takes to "be agile-lean." Alan Shalloway, in his article An Overview of Lean-Agile Methods, describes if you want to go Agile, you have a great many choices: Not just about which method to use, but where to start, whether to go top-down or bottom-up, and what should be the scope of your effort. In my article Is “Agile Methodology” an Oxymoron and Counterintuitive to Agile-Lean Product Development and Craftsmanship?, I’ll explore the differences between a process and methodology. Then discuss why the word process or methodology is a wrong word to use to label and encapsulate agile-lean product (system-software) development. I will also provide guidance how a team can move forward inspired and motivated to uphold the team’s agile-lean product (system-software) development approach, continuously improve and confident in the security such guidance provides. Ken Clyne, in his article The Risk Management Game: Shared Accountability Through Collaborative Risk Analysis, why release planning is more than just stuffing the highest ranked stories into iteration buckets. To be meaningful the whole team needs to participate. He goes on to make the case that lightweight risk management techniques are not orthogonal to an agile approach They can be help proactively address previously hidden concerns and the planning process benefits all-around from shared dialog on release-impacting risks. Graham Parsons, in his article Integrating Performance Testing into the Agile Development Process, describes the importance performance testing plays in delivering valuable quality software and how performance testing traditionally requiring weeks to set-up can pragmatically and effectively be reduced to within an Agile project’s iterations. Jean Tabaka, in her article “Dear Agile” – A Love Letter, she cleverly and insightfully introduces a technique to help folks convey an agile-lean adopter’s attraction to Agile and reveal where they are concerned about it as well. Your agile buddy and editor,
|
|||||||||||||||||||||||||||||||||||
| Last Updated on Wednesday, 08 September 2010 09:28 |
Agile Marketplace - Announcements and Special Offers
The Business Case for ALM Transformation
Are legacy systems holding your company back? Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper








