|
|
Agile vs. Agility: Doing vs. Being To be agile or not to be agile … that is not the question anymore; agile adoption is on the rise and there seems no turning back. The real question is whether we are focused on boiling agile down to a list of prescribed practices or are we dedicated to embracing and internalizing the core values and principles of agility. Ahmed Sidky explores why “doing” agile over “being” agile could be the reason some organizations do not produce hyper-performing agile teams. He challenges the current thinking of many agile proponents and suggests a solution to the problem. Ahmed offers a value-based roadmap for agile adoption consisting of five steps-collaborative, evolutionary, integrated, adaptive, and encompassing-to help teams and organizations embrace principles over practices. Ahmed helps you crystallize your thinking about the issue of agile vs.
|
Ahmed Sidky, Santeon
|
|
|
Boundary, Authority, Role and Task (BART) Analysis If your Scrum practices-or any agile processes-aren't working as effectively as they might, this class may be just what you need! When teams have trouble executing their work processes, the root cause is often ambiguous definitions of boundary, authority, role, or task-what Dan Mezick calls BART definitions. Although the Scrum framework, effectively implemented, provides excellent BART definitions and structure, sometimes theory and practice don't match. Dan describes how agile teams can employ BART analysis to uncover organizational problems that impact group performance. With a detailed BART analysis, you can identify and isolate effective ground rules for interactions among group members. These ground rules positively impact behavior and foster cultural improvements. In a lively discussion format, Dan introduces the fundamentals of BART analysis and applies it to Scrum.
|
Dan Mezick, New Technology Solutions
|
|
|
Making Agile Work in Highly Regulated Environments Highly regulated industries-avionics suppliers, medical device companies, and pharmaceutical manufacturers-must meet rigorous quality standards to ensure their products are not a danger to the general public. Although compliance has traditionally been achieved with heavyweight waterfall or V-model development methodologies, you can implement agile-or lean-agile-development practices that adhere to standards-based regulations while reducing the risk and improving software quality and reliability. Colin Doyle identifies the constraints that agile and lean-agile software development approaches must address: traceability to clearly defined requirements, formal risk analysis and mitigation, and separation of roles between development and validation.
|
Colin Doyle, MKS, Inc.
|
|
|
Managing and Eliminating Technical Debt Many organizations look at technical debt as an inevitable byproduct of developing and delivering software. They struggle with managing their existing debt as well as searching for ways to make it go away. Instead, learn how to manage and eliminate your current technical debt while avoiding additional debt in the process. Lee Henson shows how-no matter what your organizational role-to make sensible business decisions for development and avoid technical debt at the same time. Using consumer credit card debt as a comparative analytic, Lee explores ways to eliminate technical debt the same way a conscientious consumer addresses personal debt. Discover sound principles for debt relief: how to define and identify all aspects of technical debt, how to empower team members to take steps toward eliminating that debt, and steps to take to avoid future debt no matter what.
|
V. Lee Henson, VersionOne
|
|
|
Mastering Dependencies in Your Product Backlog Agile teams may unintentionally assume significant risk and excessive rework by not addressing dependencies in the product backlog. While the business defines the minimum requirements needed to deliver value and when to deliver that value-delivery dependencies-the agile team determines the necessary sequence of development-development dependencies. The challenge for everyone is balancing delivery and development dependencies. Taking a holistic approach to the product backlog enables the team to evaluate the impact of these dependencies and, as needed, adjust release and iteration plans. Ellen Gottesdiener and Mary Gorman share techniques they have used to master dependencies in backlogs.
|
Ellen Gottesdiener, EBG Consulting
|
|
|
Agile Test Automation Development We can apply agile development practices to test automation like any other software development project. The good news is … using agile practices for test automation projects addresses some of the classic problems of test automation: when and what to build, increasing automation execution to achieve extended return-on-investment, and test automation teams “going dark” for long periods of time. Sharing a case study, Monica Luke demonstrates how adopting agile principles increases the test automation team’s visibility and productivity while providing higher value automation. She addresses the special challenges of building automation in real-time while the product is also under development and explores GUI test automation issues. Learn how to incorporate stakeholder feedback, time-boxed iterations, demos, and other agile concepts into your test automation initiatives.
|
Monica Luke, IBM Rational
|
|
|
Story-o-types: The Patterns Within the Stories Have you noticed that similar stories appear over and over again as you develop a system? According to Dan Rawsthorne, stories-those small chunks of work that make up your backlog and provide demonstrable value to the project-can be categorized by purpose: production, analysis, cleanup, infrastructure/environment, business support, or other. Within each of these categories are different “story-o-types”-patterns that define the commonalities among the stories themselves. Dan defines and describes some of the most common story-o-types, explains why they are useful, and demonstrates the concept with examples including “Alternate Path” and “Clean-Up Interface” for the production category, “Talk to Stakeholders” and “Exploratory Testing” for the analysis category, among others. For each story-o-type, Dan provides sample tasks and canonical "doneness" criteria that make planning and backlog grooming easier and more consistent.
|
Dan Rawsthorne, Danube Technologies
|
|
|
Estimating Business Value Agility focuses on delivering business value to the customers as rapidly as possible. So, how does the team assure the business that it’s delivering the most value possible in the right priority? It’s more than prioritizing user stories or estimating development effort with story points. Through presentation and interactive exercises, Ken Pugh explains how to estimate and track business value throughout an agile project. He presents two methods for quickly estimating business value for features and stories, and shows the relationship between business value estimates and story point estimates. Ken illustrates how to chart business value for iteration reviews and demonstrates what estimates really mean in both dollars and time. On a larger scale, Ken shows business value as a portfolio management tool for prioritizing feature development across many projects.
|
Ken Pugh, Net Objectives
|
|
|
Scaling Agile Adoption Beyond the Development Team Given the success of agile at the development team level, managers are exploring the possibility of implementing agile methodologies across the entire product lifecycle organization-beyond software development. Managers who have launched such adoption efforts are uncovering many myths, misperceptions, and obstacles that derail their efforts before they really get started. Product delivery organizations fail to become agile because they don't really understand what makes agile teams work. Mike Cottmeyer describes an agile adoption roadmap that begins with an individual team and then demonstrates how multiple teams can work together to deliver more complex projects and portfolios. He expands the agile concept beyond the development team and shows how organizations can optimize their value stream across the enterprise.
|
Michael Cottmeyer, Pillar Technology
|
|
|
Better Software Conference West 2010: Concurrent Testing Games: Developers and Testers Working Together The best software development teams find ways for programmers and testers to work closely together to build quality into their software. These teams recognize that programmers and testers each bring their own unique strengths and perspectives to the table. Only by building upon this combination can we reach our full potential to consistently deliver quality. To do this, we first have to unlearn the anti-patterns that traditional development taught us. In this interactive workshop, learn how to use Concurrent Testing to overcome these common "testing smells" by having programmers and testers working together, rather than against each other, throughout development iterations. Play games to demonstrate just how powerfully dysfunctional systems can act against your best efforts and how agile techniques can help you escape the cycle of poor quality and late delivery.
|
Abby Fichtner, Microsoft
|
