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 Practices - February 2010
Vince Lombardi, one of, if not the greatest coach in football history, once said, “Practice does not make perfect. Only perfect practice makes perfect”.
Our working definition of “practice”, for this month’s topic is: A practice is a common and adaptive approach for doing something with a specific purpose in mind. When a team is “being” agile, one of the things they will do is self-organize & self-direct around practices; selecting one or more practice to apply to an iteration/sprint. My article, “The Truth about Practices and Being Agile,” describes two candidate practices: Mastering the Iteration and Three Level Planning. Matthew Leach in his article “Put Business Analysts to Work for You!” insightfully shares how the introduction of a business analyst, and their experience in communication, elicitation, and enterprise architecture, to an agile development team can reduce risks and improve project success and agile adoption rates. Matthew’s article shares insights about the practice of Business Driven Development. In his article, “Managing Successful Agile-Build Management Teams,” Chayim Kirshen shares with us the practice of Build & Release Engineering. Chayim does an excellent job describing his team’s collaborative approach in providing customer-focused engineering services while also “being” agile and applying the Scrum framework. Likewise, in her article “Helping Agile Teams Tip Towards Greater Emotional Maturity,” Ellen Braun excels in describing how “being” agile aids in the development of high-functioning teams-- like recognizing and fostering key behaviors which are markers of emotional maturity, thus enabling teams to gain resiliency to further innovate and accelerate in highly complex environments. Ellen’s observations exemplify the practice of Organizational Learning & Development. In their article “Product Road-Mapping using Agile Principles,” Anupam Kundu and Tiffany Lentz outline a modest agile-enabled framework seeking to charter a product roadmap and simultaneously providing the “big picture.” Anupam and Tiffany share insights about the practice of Product Management. Bob Small and Chuck Gadnis in their article “The Value of Concurrent Testing” and Alexander Podelko in his article “Agile Performance Testing” contribute to describing a common and adaptive approach to Concurrent Testing and Continuous Integration. Finally, Roman Pichler, in his article “Grooming the Product Backlog,” shares with us how grooming the product backlog is an ongoing process that ensures the product backlog is DEEP and that a well-groomed backlog is a precursor for successful Sprint planning. Roman’s article share insights about the practices of Business Driven Development, Mastering the Iteration and Product Management. Check out the future editions of the Agile Journal, as Mr. Pichler will share additional articles based on his forthcoming book, Agile Product Management with Scrum: Creating Products that Customers Love. Have a great reading experience! Your agile buddy and editor,
|
|||||||||||||||||||||||||||||||||||||||||||||
| Last Updated on Wednesday, 08 September 2010 10:02 |
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



A misnomer is labeling a practice a “best” practice; a practice is only best in the specific context in which it exists.






