The Latest

No two people or groups are the same, but their differences don't have to force them apart. In this column, Esther Derby uses the example of feuding operations and development groups to explain how focusing on the source of structural conflict can help build a bridge across the disagreements.

The components of software processes work together in important and sometimes unrecognized ways. The removal of one of those components will affect the others. In this article, which originally appeared in the August 2010 issue of the Iterations eNewsletter, Jennitta Andrea takes a look at the value of acceptance test-driven development and the costs of making it an optional practice.

Organizations eager to solve the problems they see in their projects or processes often decide to adopt Scrum in the belief that it will immediate solve all those problems. Although Scrum can and often does resolve some problems immediately, it also has the potential to expose or exacerbate other existing problems and can even appear to create a few problems of its own.

In some cases, this can be seen to be a “failure” of Scrum, even when implemented by an organization that was initially enthusiastic and determined. This perceived failure can cost the organization considerable time and money if the Scrum team continues along the same path they are on, despite the unresolved problems. These costs, as well as frustrations and even pressures from inside or outside the Scrum team can cause Scrum to be abandoned without ever demonstrating its full potential.

Life used to be simpler. In the early 2000s, if you wanted to go "agile," XP was the route of choice. And then Scrum became popular. And it was not too long before organizations began to hit the limits of these approaches due to their focus on teams. And then it became apparent that lean principles could be applied to software and Lean Software Development and later Kanban were added to the mix. Now, you have a great many choices: Not just about which method to use, but where to start, whether to go top-down or bottom-up, and what should be the scope of your effort.

Coaching and training are indispensable to Agile transformations. This can be difficult for some organizations to accept.Agile frameworks are simple to understand, but there are many nuances to handling the complexities involved in an Agile transformation.While it is often helpful to tap into outside resources (books, websites, courses or consultants), the organization will need someone who understands the subtleties of Agile transformations and the context of the organization to make the transition as successful as possible.We refer to this role as the “internal Agile coach” and we often encourage clients to identify one or more such individuals as the organization's need for Agile knowledge and understanding grows. Being an Agile coach requires a wide range of human qualities, skills and experience, and selecting one for the company should be done carefully.In this article, we discuss when you need an Agile coach, what an Agile coach does, and a few tips on how you might create your own internal Agile coach.

What is the Purpose of Coaching?

In our work environments and personal lives we’re always looking to make clear, thoughtful choices, speak them clearly, and execute them in effective ways. We want to optimize our time and energies to create valuable outcomes. All this can happen spontaneously and without a plan, but with foresight to think and plan before taking actions, especially for larger goals, there’s a higher probability for getting quicker and more reliable results.

Nirav P Assar uses Malcom Gladwell's best selling book , The Tipping Point to discuss what's necessary to fully, and successfully implement agile, in order to take advantage of all that it can bring to a software development team.