Agile Development Practices East 2010

PRESENTATIONS

Big Agility Requires Little-a agile

The hardest part of big projects is that they are BIG. Of course “big” means different things to different people. What some measure in cash, others measure in technology. Little value flows when we focus on the number of people “doing agile.” Big value is more likely to flourish when agility is a tool for overcoming complexity. Instead of a talk about “doing agile in the large”, David Hussman speaks to agility as a tool instead of a mandate.
David Hussman, DevJam
Build and Test in the Cloud

Many organizations are looking to cloud computing to reduce equipment costs, eliminate some overhead, and improve go-to-market time. As an agile practitioner you may be wondering how you can leverage dynamic cloud computing to its best advantage. Darryl Bowler shares ways agile teams use cloud provisioning techniques today to provide instantaneous build-test resources and how they scale and grow build-test farms on demand.
Darryl Bowler, CollabNet
Coaching Large Company Agile Transitions

Today, many larger companies are taking notice of agile practices, starting agile transition programs, or testing the water with pilot projects. Unfortunately, the realities of inter-team dependencies, ingrained cultural issues, and human nature quickly get in the way and threaten progress. Multi-team development environments can foster excessive standardization, gaps in dependency management, and vague reporting structures. Fortunately, good agile coaching can help you avoid many of the issues and mitigate others.
Rob Myers, Agile Institute
Comparative Agility: How Agile Are You? How Agile is the Industry?

Are you curious about how "agile" your organization is? Do you wonder how you compare with other companies that have been using agile for a similar period of time? Do you want an authoritative source of information to help guide your successful transition to agile? Kenny Rubin presents Comparative Agility, a framework for assessing your organization's agility and benchmarking it against similar companies. Kenny examines the areas of teamwork, requirements, planning, technical practices, quality, culture, and knowledge creation.
Kenny Rubin, Innolution, LLC
Continuous Integration: It's Not About the Tool

In the earliest days of agile development Continuous Integration (CI) began as a people practice. Teams focused on finding issues as soon as possible so they could rapidly adapt to change. As tools such as CruiseControl and others became available, the focus shifted to CI server feature sets, build management, and deployment pipelines. Paul Julius explains the stages through which development teams evolve as they adopt CI. All too often, teams allow CI to become the neglected integration server to which no one pays attention.
Paul Julius, Independent Consultant
Critical Success Factors for Acceptance Test-Driven Development (ATDD)

A good analyst or tester knows what questions to ask to quickly bring clarity to a murky subject. When they first hear about Acceptance Test-Driven Development (ATDD), a core practice on agile projects, their initial questions often are "Can examples really capture functional requirements?", "Where do user stories come from?", and "Will the analyst and tester roles become extinct?" When Jennitta Andrea worked on her first agile project in 2000, she asked all of these questions and more.
Jennitta Andrea, The Andrea Group, Inc.
It's the People, It's All About the People

As organizations transition to agile, they often notice "people problems" not previously seen in their traditional project structures. Agile team members lose patience with each other. Some team members, rather than moving toward becoming generalists, specialize even more. Managers fail to let go of perceived control and don't collaborate. Team members fail to develop good interviewing skills, so they can't offer valuable insight-and they don't like the candidates who are hired.
Johanna Rothman, Rothman Consulting Group, Inc.
Lean, Kanban, and the Art of Flow

It doesn't matter what you're producing-physical goods, software, or other products. When efficiency and workers' time utilization become more important than the value of the work product, the production system is optimized for the wrong thing. Lean thinking shifts the emphasis to creating value through the concept of "flow." The goal of flow is to eliminate delays and bottlenecks producing the product to speed up its delivery and earn value for the organization sooner.
Jean Tabaka, Rally Software Development
Meaningful Metrics for Agile Teams and Organizations

The old adage “If you can measure it, you can manage it” also implies that meaningless metrics lead to meaningless management and harmful metrics lead to harmful management. When agile methods encounter metrics that were designed-and have organizational credibility-for non-agile processes and practices, the potential for harm is great. Niel Nickolaisen shares case studies and examples to describe the principles of meaningful-and meaningless or harmful-agile metrics.
Niel Nickolaisen, Energy Solutions
Measuring Team Velocity

The velocity metric is often misunderstood, poorly measured, and misused by both management and development. Managers want to know how to increase this number. Developers worry they're being evaluated based on it. If velocity is not measured-and used-correctly, planning efforts quickly unravel, often sabatoging the team's efforts. Through simple analogies that make it more understandable, Rob Myers clarifies velocity-its definition and proper use within agile teams.
Rob Myers, Agile Institute

Pages

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.