|
|
Coaching Agility--Producing Value If you are an agile coach and your team or organization is struggling to adopt agile methods or is backsliding, this class is for you. David Hussman shares coaching techniques you can use to grow sustainable agility that lasts beyond the early iterations and the first few agile projects. David begins with a series of tools to help you build a solid foundation: assessments, pragmatic practice selection, chartering, and product planning tools. He shares his coaching experiences that you can adapt to help your teams establish a strong cadence while also building the essence of coaching within your organization. You'll learn to step back from prescriptive practices and use the agile principles and values to amplify existing strengths and address challenges. Whether you are new to agile methods or a seasoned player, David helps you grow your coaching skills and your ability to discover and deliver sustainable, real value.
|
David Hussman, DevJam
|
|
|
Enterprise Agile Adoption: Barriers, Paths, and Cultures While agile adoption continues to grow rapidly in the software product development world, it has not been as widely adopted within enterprise IT departments. Even within a single company, different software organizations can have widely varied views on adopting agile concepts. Some groups are fanatical about the “A-word”; others are skeptical and dismissive. Using Medtronic as a case study, Mike Stuedemann examines the barriers to agile adoption within large, multinational corporations. He shares his experiences at Medtronic to illustrate the varied adoption paths that teams can employ to realize the benefits of agile within the enterprise. Mike learned that many of the supposed barriers to enterprise agile adoption were myths; others were real and really difficult to overcome.
|
Mike Stuedemann, Medtronic
|
|
|
Being There: War Stories from Collocated and Distributed Teams Since the early days of agile, we've known that face-to-face communication is optimal. In fact, one of the twelve principles in the Agile Manifesto is, “Business people and developers must work together daily throughout the project.” So, what are the real differences between collocated and distributed teams with the advent of “closeness” technologies-Web-based meetings, shared project whiteboards, Skype, Wikis, video conferencing, and more? Through a series of stories about teams he’s worked closely with over the past few years, Michael Feathers explores the issues surrounding team collocation. Whether you are lucky enough to have your entire agile team together or are required to work apart most or all of the time, you'll discover new ways to encourage collaboration and build personal relationships. In the end, you'll arrive at your personal understanding of what "being there" means.
|
Michael Feathers, Object Mentor
|
|
|
Agile Brushstrokes: The Art of Choosing an Agile Transition Style Agile software processes vary in detail, depth, impact and endurance as much as painting styles like graffiti differ from Baroque or Impressionist art. What can artists teach us about successful agile transitions? And what can past agile transitions teach us about styles that endured or faded away? Joshua Kerievsky will map agile transitions to art styles and identify elements that lead to success or failure. We will look at palettes of principles and practices, how and when agile styles may be effectively blended, when or how to do a sketch before jumping to the canvas, how initial transitions can morph into wholly different styles and whether to spread a consistent or varying style across a department or organization. Joshua will focus on four fundamental agile transitions styles as he walks you through case studies from the past decade.
|
Joshua Kerievsky, Industrial Logic
|
|
|
Moving to an Agile Testing Environment: What Went Right, What Went Wrong About a year ago, Ray Arell called his software staff together and declared, "Hey! We are going agile!" Ray read an agile project management book on a long flight to India, and, like all good reactionary development managers, he was sold! Now-two years later-their agile/Scrum process has taken shape; however, its adoption was not without strain on development, test, and other QA practices. Join Ray as he takes you on a retrospective of what went right and, more importantly, what went wrong as they evolved to a new development/test process. He introduces the software validation strategies developed and adapted for Scrum, explains what makes up a flexible validation plan, and discusses their iterative test method. Learn how they use customer personas to help test teams understand expectations for quality in each sprint and employ exploratory testing in the Scrum development flow.
|
Ray Arell, Intel Corporation
|
|
|
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.
|
|
|
Seven Years Later: What the Agile Manifesto Left Out Although the Agile Manifesto has worked well to help many organizations change the way they build software, the agile movement is now suffering from some backsliding, lots of overselling, and a resulting backlash. Brian Marick believes that is partly because the Agile Manifesto is almost entirely focused outwardly—it talks to the business about how the development team will work with it. What it does not talk about is how the team must work within itself and with the code. Even though those omissions were appropriate then, now more is needed. Teams starting agile need to know that more discipline is required of them, and that discipline is fruitless without a strong emphasis on skills. Teams need to recognize that success is not just fulfilling requirements. It is also increasing productivity and decreasing the consequences of mistakes.
|
Brian Marick, Exampler Consulting
|
