|
|
 |
|
|
|
|
|
|
| Joachim Herschmann, Borland (a Micro Focus Company)
|
|
|
| Agile development provides the opportunity for new levels of productivity and value for software delivery—yet the agile approach brings new challenges that impact people, teams, and processes. Joachim Herschmann describes how a traditional waterfall-oriented development organization can become more agile and how software delivery can be transformed into a managed, efficient, and predictable business process. Using the real-life example of the Borland Linz development center, a traditional organization that has been undergoing an agile transformation for more than two years, Joachim shares the company's experiences throughout this culture shift. Because not everything in this transition was easy and straightforward, Joachim discusses the pitfalls and challenges that the Borland Linz development center encountered—short sprint cycles, shared quality responsibility and accountability, and an increased need for test automation. Take away the best practices and lessons learned from a team that is succeeding in its quest to “go agile.” |
 |
| Learn more about Joachim Herschmann |
|
|
|
|
|
|
| Why do some agile communities succeed while others are struggling or failing? Communities that struggle often do so because they are prescriptively follow processes instead of descriptively adopting practices and principles that amplify their existing strengths and address their challenges. David Hussman shares successful coaching techniques he uses to grow sustainable agility that lasts beyond the early iterations or the first few agile projects. David begins with a series of initial adoption tools—assessments, pragmatic practice selection, personas and story maps, chartering, and development manifestos. He then moves on to discuss ideas and tools for keeping the agile spark alive and glowing. As a full time working coach, David uses coaching stories and experiences to discuss establishing strong, sustainable delivery cadences while also building the essence of coaching and coaches. Learn the tools for finding your groove, the definition of which is not in any book. If you want to grow your coaching skills and your ability to truly deliver real value, this session is for you. |
 |
| Learn more about David Hussman |
|
|
|
|
|
|
| Continuous testing is a practice that involves automatically running tests after every program change. Just as modern IDEs provide instant feedback about the code’s syntactic correctness, continuous testing gives you instant feedback about the semantic correctness of the code. Continuous testing has a profound impact on the way you use test-driven development (TDD) and continuous integration (CI). TDD provides rapid feedback through the frequent execution of a small set of related tests. CI provides broader feedback on a less frequent basis. Continuous testing combines the immediacy of TDD with the breadth of CI to redefine the experience of developer testing. Rod Coffin describes the history, theory, practice, and daily application of continuous testing, including its application on different platforms, and his ongoing experiences with continuous testing on real-world systems. Rod demonstrates continuous testing practices using Infinitest, a free tool for Java, and ends with a discussion of the future of continuous testing. |
 |
| Learn more about Rod Coffin |
|
|
|
|
|
|
| When making choices about a system’s functionality, the easiest thing is to ask yourself, “What would I like the software to do?” Unfortunately, when a team uses this approach, the result is usually constant argument, uncomfortable compromises, and that never-popular “designed-by-committee” feel. A persona is a simple model that describes an example user of a system. It’s easy and fun for a team to create pragmatic personas that describe what we know about our users so we can talk about the product from their perspective. A good set of personas help us avoid the trap of self-referential design, and the act of building personas helps us identify what we don’t yet know about our users. Jeff Patton shares the basics of creating simple personas and leads you through an exercise of creating one during class. Join Jeff and learn to write better agile user stories and identify characteristics your software must have to “wow” your users. |
.jpg) |
| Learn more about Jeff Patton |
|
|
|
|
|
|
|
| Lean production has made it possible for many industries to develop products faster and more profitably, building a loyal customer base while lowering business risk. Now, Lean has proven it can do the same for software development—and do so better than any development approach to date. Lean is more than a management system, method, tool, or environment; the areas where software methodologies normally focus. Lean is a worldview—a way of thinking that fundamentally changes and humanizes industry. The power of Lean is in the goals it leads us to pursue and the ways in which we coordinate our work. Therefore, Lean allows us to continue using many of our current software techniques. James Sutton returns to the beginnings of Lean, as conceived in the mind of W. Edwards Deming, and moves forward in time to compare and contrast Lean with agile development. Then, James explores with you ways to apply the “five lean principles” to software development to help you and your organization move toward its own worldview. |
 |
| Learn more about James Sutton |
|
|
|
|
|
|
| Agile adoptions can only be successful if corporate values match the key values outlined in the Agile Manifesto and in agile frameworks such as XP and Scrum. Michele Sliger explains the agile values that play a key role in driving individual and team behavior. Learn the real meaning behind the often heard phrase "agile is value-driven, not plan-driven". Discover how to determine your company’s values and how to compare and contrast them to agile values—and what to do if they are different. Practice visioning exercises that you can conduct on your own and with your team to better understand what you and your team members personally value and what you can do to better align your present values with agile values. Find out how to define values at the team level—a must to ensure effective working relationships. Take away a framework to apply what you’ve learned in your own company and team. |
 |
| Learn more about Michele Sliger |
|
|
|
|
|
|
| Many teams have a relatively easy time adopting the tactical aspects of the agile methodologies. Usually a few classes, some tool introduction, and a bit of practice can lead you toward a somewhat efficient and effective adoption. However, such teams quite often are simply going through the motions—neither maximizing their agile performance nor delivering as much value as they could. Borrowing from his experiences and lean software development methods, Bob Galen explores essential patterns—the ”thinking models” of mature agile teams—including large-scale emergent architecture, relentless refactoring, quality on all fronts, pervasive product owners, lean work queues, stretching above and beyond, providing total transparency, saying “no”, and many more. Bob explores the leadership dilemma of self-directed teams and why there is still the need for active and vocal leadership in defending, motivating, and holding agile teams accountable. |
 |
| Learn more about Robert Galen |
|
|
|
|
|
|
|
Peer code review is one of the most effective ways to find defects – but is it agile? Because agile teams loathe heavy process, code review practices can easily fail. However, lightweight peer code review aligns well with the central tenets of agile—keeping feedback close to the point of creation, increasing team velocity by finding defects faster, and improving collective code ownership through frequent collaboration. Gregg Sporar shares recent research on code review practices and describes an agile code review approach—how much time to spend, which code to review, how much code to review at a time, how to set goals, the value of annotation, and more. After comparing four styles of code review—pair programming, over-the-shoulder, email, and tool-assisted—Gregg gives specific advice for creating review checklists and dealing with the social effects of code review in an agile environment.
|
 |
| Learn more about Gregg Sporar |
|
|
|
|
|
|
| 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 as: Production, Analysis, Cleanup, Infrastructure/Environment, Business Support, or Other. Within each of these categories are different “storyotypes” —patterns that define the commonalities among the stories themselves. Dan defines and describes some of the most prevalent storyotypes, explains why they are useful, and demonstrates the concept with examples. These examples include “Alternate Path” and “Clean-Up Interface” for the production category, “Talk to Stakeholders” and “Exploratory Testing” for the analysis category, among others. For each storyotype, Dan provides sample tasks and canonical “doneness” criteria that make planning and backlog grooming easier and more consistent. By employing storyotypes in developing your stories, your team will produce more consistent, higher quality requirements that are easier to work with. |
 |
| Learn more about Dan Rawsthrone |
|
|
|
|
|
|
| If XP and Scrum are the first generation of agile methods, Kanban software development is the next generation. Kanban integrates lean and agile principles to create better software faster and at less cost. Kanban does this by defining explicit methods to manage work flow, paying particular attention to the number of things being worked on simultaneously, and how the available resources are allocated. Alan Shalloway reviews the basic Lean Principles of “fast, flexible, and flow” along with the systemic nature of errors Kanban addresses. Alan describes the differences between time-boxed software methods such as Scrum and flow-based methods such as Kanban—and when you would want to use Kanban instead of Scrum. Learn how to implement Kanban by defining a workflow, managing your work in progress, and establishing a Kanban board to make the workflow and progress visible. Learn what to expect—both the good and the bad—if you undertake using Kanban. |
 |
| Learn more about Alan Shalloway |
|
|
|
|
|
|
Agile methods emphasize trust, empowerment, and collaboration—moving us away from command and control project management to harness the passion, creativity, and enthusiasm of the team. In established organizations, success with agile practices hinges on how well traditional project managers adopt new ways of thinking about project structure and control. Building on the principles of the Project Management Body of Knowledge (PMBOK®), Mike Cottmeyer explores how PMPs experienced in traditional development can adapt their styles and practices to become effective agile project leaders. Mike tackles the hidden assumptions behind the PMBOK® and explores agile approaches for managing time, cost, and scope. Taking an in-depth look at PMI processes and knowledge areas, he also explores ways you can adapt them to agile projects. Project managers, business analysts, and all stakeholders will leave with a new way of thinking about project management practices within the agile context and new tools for delivering value in the face of uncertainty.
PMP® and PMBOK® are registered trademarks of the Project Management Institute.
|
 |
| Learn more about Mike Cottmeyer |
|
|
|
|
|
|
| Within the agile development lifecycle, the role of “iteration manager” is crucial for maintaining the rhythm and flow of the project. From leading the stand-ups, reviewing plans and estimates, communicating the status of the iteration to the customer, and escalating roadblocks to executive management, the iteration manager focuses on and supports the team's daily efforts. Tiffany Lentz and Petra Skapa describe the role of iteration manager and compare it to other roles, including ScrumMaster, technical manager, project manager, and product manager. Tiffany and Petra describe the key activities and skills required to be an effective iteration manager from the beginning of the iteration to its end, including the characteristics of a good IM, the best methods for acquiring necessary skills, how to apply them, and the risks your project incurs if no one takes on this role. In that situation, communication and visibility suffer, customer trust in the team erodes, and morale declines. The Iteration Manager ToolKit, provided on CD to participants, gives agile teams a jumpstart on taking their development to the next level. |
  |
Learn more about Tiffany Lentz
Learn more about Petra Skapa |
|
|
|
|
|
|
| Scrum frameworks deliver working code in time-boxed sprints. Many communities find Scrum to be a wonderful balance between discipline and agility because it tames turbulence and focuses teams. However, Scrum requires dramatic rethinking of the traditional role of testing in a development project. Rob Sabourin explores critical testing incidents in Scrum projects – key turning points, difficult decisions, major problems, brilliant successes, and dismal failures. Rob identifies key skills, practices, and techniques used to confidently deliver working code each sprint. Rob shows how testing is implemented by teams in different organizational, business, and technical contexts. His findings raise important questions and identify some novel solutions. Do we really need testers in Scrum? Learn how teams solve tough security, performance, reliability, scalability, usability and regression testing challenges. Explore ways testers and developers collaborate preserving tester independence within small cross functional teams. |
 |
| Learn more about Rob Sabourin |
|
|
|
|
|
|
| Despite our wishing it were so, software architecture is not static throughout a project, especially within an agile development environment. Agile architecture is defined by our willingness and ability to embrace and accommodate architectural changes that emerge during the project. Agile architecture issues are both temporal—when to make architectural decisions—and structural, demanding that the architect and architecture remain flexible and able to accommodate change. Kirk Knoernschild examines these two aspects of agile architecture, exploring the concepts of architecture throughout the agile lifecycle and describing the activities agile architects perform. Join with Kirk to discuss architecture modularity issues, and how to deconstruct large systems to increase flexibility, reusability, maintainability, extensibility, and testability. Explore the inextricable links between temporal and structural agile architecture as you examine the patterns and technologies that lead to a truly agile architecture. |
 |
| Learn more about Kirk Knoernschild |
|
|
|
|
|
|
| Early in 2004, Chris Shinkle’s company began adopting agile practices. Unfortunately, agile did not have the desired cultural impact within their organization—and the adoption floundered. Several years later, Chris found himself coaching a fellow project lead several months into a difficult project. The project team had experienced developers, but faced a seemingly impossible deadline. Discontent and frustration were rampant and something needed to change. Chris decided that a Kanban implementation could improve the situation. The team quickly discovered the primary reason for their long lead times—a huge Work In Progress (WIP) count. As the team sought to reduce its WIP using Lean principles, they eliminated considerable waste in their processes, reduced bottlenecks, and made significant process improvements. In a short six months, they moved from chaos to a state of continuous improvement. Chris shares their lessons learned and explains how the team grew during the project. Learn the effect of expedited work items, the real cost of rework, and how to make quality a focus throughout your software process. |
.jpg) |
| Learn more about Chris Shinkle |
|
|
Top of Page
|
|
|
|
|
 |
Software Quality Engineering • 330 Corporate Way, Suite 300 • Orange Park, FL 32073
Phone: 904.278.0524 • Toll-free: 888.268.8770 • Fax: 904.278.4380 • Email: [email protected]
© 2009 Software Quality Engineering, All rights reserved. | | | |
