Agile Development Practices 2007
PRESENTATIONS
Building Agile Workspaces
An agile team needs a workspace that supports highly collaborative ways of working together. The team needs to be able to sit together and have visible "information radiators" of the latest status on planned work and code quality. Some teams also boost their spaces with "eXtreme Feedback Devices" such as lava lamps and audio signals linked to automated processes. It is vital to ensure that feedback mechanisms within the agile workspace are easy to interpret and low maintenance. |
Rachel Davies, Rachel Davies
|
Climbing the Decision Tree: Reaching High Quality Team Decisions
When teams "go agile," members of the whole team take on greater responsibility for thinking and deciding as a unit. Though individual team members may know how to make great individual decisions, few people bring the skills or perspective needed to make high quality decisions as a group. Teams need to plan for all elements of high quality team decisions, balancing technical quality, commitment to implementation, efficiency, and opportunities for team development. |
Diana Larsen, FutureWorks Consulting
|
Decision Making in Agile Teams: The Key to High Performance
Agile teams are encouraged to act collaboratively and make decisions as a team. And yet, some decisions must occur outside of the full team's consensus. For example, business or product owners ultimately must set their value and priority decisions even though they need to negotiate with the delivery team. Jean Tabaka explores the variety of decision modes and roles that are required for agile teams while they still maintain a high degree of trust and safety. Learn why agile teams rely so heavily on good decision-making. |
Jean Tabaka, Rally Software Development
|
Do The Right Thing: Adapting Requirements Practices to Agile Projects
Break out of the cookie-cutter mentality that some agile teams take toward requirements. Join Ellen Gottesdiener to explore what requirements models you should use to supplement (or replace) user stories for large projects. Ellen looks at the factors to consider when deciding on a requirements approach, including your project’s size and technology characteristics and your team’s domain expertise. Find out when to engage the product owner in requirements work and discover ways to leverage the role of business analyst in agile projects. |
Ellen Gottesdiener, EBG Consulting, Inc. |
Empirical Studies of Agile Practices
Gone are the religious wars of plan-driven vs. agile software development methodologies and practices. Recent surveys indicate agile practices are being adopted in many software development organizations, with others seriously contemplating making the switch. The question from most organizations now has turned from plan-driven vs. agile to which agile practices they should use in their development process to most improve their business results. |
Laurie Williams, University of North Carolina
|
Executable Documentation
Why is so much project documentation outdated and worthless? Simply put, the real value is in the final product; so, that’s where the money goes. Wouldn't it be nice if your documentation actually reflected the functionality in the system? One way to do this is to create executable documentation, also known as executable specifications. Join David Hussman for this class if you are struggling with ambiguous requirements, lack of collaboration with users, or a lack of communication among developers, business stakeholders, and testers. |
David Hussman, DevJam |
Five Practical Solutions to Agile Myths
The results are in-many ideas in the agile canon can actually decrease your velocity and slowly poison your code. James Coplien examines five of these common practices, why they can be harmful, and how to avoid their pitfalls. [1] TDD: Avoid architecture rot with a lightweight architecture and an appropriate level of testing. [2] YAGNI: Avoid being blind-sided by unexpected requirements by employing use case slices and lightweight architecture. [3] On-Site Customer: Avoid burning out the customer by adding a product owner. |
James Coplien, Nordija A/S
|
Flow, Pull, Innovate: How Agile Teams Mature and Scale
Jean Tabaka offers straightforward advice on how agile teams can mature and learn to scale up to larger and larger projects. The three steps of her approach emphasize a path based on principles of Lean Thinking--Flow, Pull, and Innovate. Flow is about creating smooth delivery of value. Pull is the way teams pull ready items for delivery, and the business pulls ready, tested, and valuable features into productive use. Innovate is about how the organization drives improvements rather than merely responding to issues. |
Jean Tabaka, Rally Software Development
|
Gradual Agile: From Here to There Gently
Agile practices are popular today because they are working so well for many projects and organizations. However, introducing new, agile practices--or any type of new practice--into an established organization can be difficult. One misstep during the introduction can set back change adoption for a long time. Jared Richardson explains why people tend to resist change and how you can side step that tendency. He describes a case study in which continuous integration was successfully introduced to a very large, established software company. |
Jared Richardson, Agile Artisans |
Guerilla Agile: Stop Playing Schedule Games
Chances are good that if you've worked on a project, you've encountered a schedule game or two (maybe, three or four). As part of a team, you may have seen Schedule Chicken played by management or Ninety Percent Done played by team members. If you're a project manager, you've probably pushed back against games such as: We Gotta Have It–We're Toast Without It, Queen of Denial, We'll Go Faster Now, or Split Focus. Using time-boxed iterations and other agile practices will help you stop playing-and even avoid-these schedule games. |
Johanna Rothman, Rothman Consulting Group, Inc. |