|
|
Getting Ready for Your First Iteration - Cancelled Many agilists take little time to prepare for the first planning session of their first iteration on a new project. They dive right into the "work" and, sometimes, ultimately deliver software that lacks much value. Some newly formed teams believe that collocation breeds instant success and altogether ignore early planning. While sitting together always helps, it does not mean that people spontaneously collaborate to create sustainable value. Before holding the first planning session, a bit of preproduction work helps communities learn about each other, the value they will deliver, and their newly forming ecosystem. Pragmatic preproduction does not need to imply empty ceremony or Big Design Up Front (BDUF). David Hussman shares practical ideas for mining value, connecting communities, and creating productive working environments.
|
David Hussman, DevJam
|
|
|
What's More Important: Being Agile or Creating Value? Agile processes and tools have become very popular over the past few years. They promise success where many organizations have had failures. Concerned over struggles to "be agile" and worried that they are not doing everything that every agile consultant says they must, some organizations are worrying whether their projects are really agile or not. Is worrying about whether or not we are really agile the point? Are we, in our rush to be "agile," losing sight of what's really important? Shouldn't our question be, "Are we creating software our customers value?" Jonathan Kohl focuses on understanding why we are developing software, for whom, and what our end-users and team members value. It's easy to get caught up with the newest trends and tools and measure our success based on their adoption, while forgetting about the basics.
|
Jonathan Kohl, Kohl Concepts Inc.
|
|
|
A Manager's Role in Agile Development: The Light Bulb Moment Many managers have a large part of their personal identities wrapped up in their jobs and company responsibilities. We define who we are by what we do for a living. In agile development, the manager's job is very different from what most have learned and practiced. Managers struggle with what precisely their responsibilities are—and what to do each day. Some try a simple replacement strategy—shift from Gantt charts to burndown charts, from weekly status meetings to daily stand-ups, and from project post-mortems to iteration retrospectives. Because agile teams are supposed to be self-organizing, many of the "classic" management tasks are no longer important or even appropriate. Michele Sliger shares stories about how agile adoption has affected people like you and how it has changed individuals—their perceptions of agile, their leadership styles, and even their personal lives.
|
Michele Sliger, Sliger Consulting, Inc.
|
|
|
End-to-End Testing in an Enterprise Agile Environment All too often, surprises occur late in development when independent projects-agile or not-at varying stages of completion must merge into a cohesive deliverable. These surprises often result in schedule slips and unfulfilled customer needs. At Intuit, Billie Bell found the root causes of these problems and developed an end-to-end testing model to address them. Billie discovered that test progress reports did not contain the right information to help decision makers anticipate issues early, resulting in design defects being discovered late in development. Join Billie to find ways to prevent end-of-project surprises by identifying dependencies early with use case analysis, mapping functional touch points to test cases, empowering test teams through knowledge sharing across projects, and rethinking standard project milestones.
|
Billie Bell, Intuit, Inc.
|
|
|
Agile Testing: Solving the Agilist's Dilemma One problem with iterative software development is that teams are forced to write and test software incrementally-and repeatedly. Testers know that any change could break features in both obvious and hidden ways. Developers know that a change to their stable design is just around the corner. So, should we go back to designing software all up front and testing the whole product just before delivery? Of course not! So how do we solve this "Agilist's Dilemma?" Rob Myers describes the two popular practices that can solve this dilemma: unit level test-driven development (TDD) and acceptance test-driven development (ATDD). Join Rob to explore the similarities and differences of these agile practices and learn how they support each other. Find out why ATDD is much more than traditional test-automation and how its practice drastically alters the role of the agile tester.
|
Rob Myers, Independent Test Consultant
|
|
|
STAREAST 2009: Seven Key Factors for Agile Testing Success Agile development approaches present unique challenges for testers and test teams. Working in short iterations, often with limited written requirements, agile development teams can leave traditional testers behind. Common testing-related activities, such as user acceptance testing, testing inter-product relationships, and installation testing, need different approaches to fit into agile projects. Lisa Crispin explains seven key factors for testing success within agile projects that you can also apply to more traditional methodologies. Using a whole team approach and adopting an agile testing mindset are among the important components of a successful agile testing strategy. Learn how to overcome cultural and organizational obstacles and barriers to success in areas such as test automation.
|
Lisa Crispin, ePlan Services, Inc.
|
|
|
Retrospectives in Action - Looking Back at the Conference In this last-day, last-hour session, Jean Tabaka invites you to apply a fundamental practice of agile teams-retrospection. Jean guides you in facilitating your own retrospectives about the Agile Development Practices conference you have just attended. You will mine your experiences by creating a timeline of your conference observations, your high points, your low points, and your conference activities. Each team will then use their timeline of observations, impressions, and actions to interpret how their overall conference experience might impact what they could do differently at the next conference, what they would recommend as changes for the Agile Development Practices conference organizers, and what they might recommend even outside of the conference context. Finally, each team will prioritize their recommendations to be collected and delivered to the Agile Development Practices conference organizers.
|
Jean Tabaka, Rally Software Development
|
|
|
Scaling Agile Up and Out: A Tale from the Trenches It seems like everyone wants to scale their agile teams. As projects grow in scope, the agile approach to software development needs to scale up to larger team sizes. Agile also needs to scale out to handle geographically distributed teams as businesses expand into new markets and seek the best talent available globally. These are challenging propositions for many teams. Ade Miller talks about his experiences at Microsoft®-scaling agile up on the Visual Studio® Tools for Office team and scaling out on the radically distributed teams within the patterns & practices group. Ade covers the approaches used-some which worked well, some not so well-and shares that the important thing is what was learned and how this new knowledge can be applied successfully to other projects. Ade presents some successful practices when scaling agile projects as well as some key pitfalls to avoid on your projects.
|
Ade Miller, Microsoft Corporation
|
|
|
Agile Growing Pains Often, examples of agile successes are presented in the context of small, software-only development teams. Michael Kirby describes what it took to deploy agile development techniques in a large, embedded software development organization. Michael describes the successes-and some of the failures-of deploying agile development in Xerox's Production Printer Development Team. Learn about the adaptation of Scrum (what happens when the project manager gets voted off the island), agile planning (what's a user story when the only observable behavior is to power up the device), and test-driven development and automated acceptance testing (until a paper jam occurs in the middle of the night). Michael describes the cultural barriers encountered at Xerox in trying to transition a large development team from "traditional" software development to a more agile development approach.
|
Michael Kirby, Xerox Corporation
|
|
|
The Business Value of Pair Programming After ten years in the public eye, Pair programming (two people seated together, working on the same programming task) is still one of the most controversial of all the agile programming practices. Managers are concerned about the cost of having "two doing the work of one," and developers are concerned about what will happen to their privacy, their reputations, and their personal performance metrics. Rob Myers dispels these and other concerns by examining the Lean aspects of the technique and by describing subtle (yet high-dividend) benefits. Rob's "Top Ten" contains only benefits that provide clear and significant value to the organization, the team, and the individual. Rob also gives some clear advice on how to try this technique and evaluate the results. You will be better equipped to weigh the costs, benefits, and ROI of pair programming, and to decide whether or not it is valuable for your organization.
|
Ken Pugh, Net Objectives
|
