Conference Presentations

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.
Putting the Kart before the Horse?

Go-karting is where most of the current Formula One racing drivers first learned the basics of race-craft. Antony Marcano, a former kart racer himself, recounts a father-and-son racing experience that helps him explain what goes wrong for many organizations that adopt Scrum as their first attempt to "go agile."

Antony Marcano's picture Antony Marcano
Enterprise Agile: Yes, Your Whole Company Can Adopt Agile

About 12 months ago, our company started an initiative to adopt agile practices across our entire organization—not only our software development organization, but our business organization. For years we had experienced outstanding results by utilizing Scrum for our clients' application development projects. Team productivity improved, executive visibility strengthened, and overall quality increased. Our goal was to capture similar results for our business. Find out how we're doing!

Melissa Meeker
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
Twelve Ways Agile Adoptions Fail

Agile methodologies have taken some heat when they appear to have failed to deliver expected benefits to an organization. In my travels as an agile coach, I have found that agile practices don't fail—rather the variations on agile adoption fail. Here are my top twelve failure modes. See which ones may be painfully familiar to you:

Note: This article was originally published on as "11 Ways Agile Adoptions Fail."This updated version includes additional information that explains why some agile adoptions that appear to have failed may never have been truly agile to begin with.

Jean Tabaka's picture Jean Tabaka
Enough Is Enough: What Does Agile Software Development Mean?

Agile software delivery is about doing sufficient up-front analysis, design, and planning—and then deferring decisions to the appropriate time. But what does “enough” really mean? And why has the term "agile" become a cliché in development circles? Terms like "post-agile" or "pragmatic agile" have emerged as a response to this, but this is only a short-term fix.

Dan North's picture Dan North


CMCrossroads is a TechWell community.

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