There is inherent risk in change; this article provides examples of full and incremental adoption of Agile practices. The approach of adoption is also discussed (push vs. pull) as well as the potential impact to team members.

Because large software projects are troublesome and often out get out of control, a number of effective development methods have been created to help reduce the problems of large software projects. Two of these methods include the well-known Capability Maturity Model®(CMM®) and the newer CMM IntegrationSM(CMMI®) of the Software Engineering Institute (SEI). When these methods are applied to small projects, it is usually necessary to customize them because, in their original form, they are somewhat cumbersome for small projects, although proven effective for large applications. More recently, alternate methods derived from smaller software projects have become popular under the general name of Agile software development. Since the Agile methods originated for fairly small projects, they can be applied without customization and often return very positive results. It is possible to merge Agile concepts with CMM and CMMI concepts, but projects cited in this article did not do so because such mergers are comparatively rare.

This article describes a Lean and Scalable Requirements Information Model that extends the basic team‐based agile requirements practices to the needs of the largest, lean‐thinking software enterprise. While fully scalable to all levels of the project, program and portfolio levels, the foundation of the model is a quintessentially lean and agile subset in support of the agile project teams that write and test all the code.

If you have never experienced a well-run retrospective, then it is hard to imagine what it is like by simply reading a book. Nevertheless, this chapter tries to tie many of the discussions in this book into a single experience. It is based on one real-life retrospective, but spiced up with a few pieces from other retrospectives. I'm certain the participants would recognize themselves, but I hope I have changed enough of the trivia to protect their privacy.

Discussion on Story Cards, the where, why, what, how and when of them. James Shore discusses the life cycle of Story Cards, what they should be, how to use them and what to watch out for.

In Agile projects, it's a common practice to visualize and share project status in “big visible charts” on a wall of the project room. Lean systems also use such devices. "Kanban," in Japanese means, loosely translated, 'card or sign'. In a Lean production system, Kanban is a method which uses standard units or lot sizes with a single card attached to each. A new card is "pulled" into the system only when the work represented by an "in progress" card is completed. In this paper, I explore visualization methods found widely in agile projects these days, and then propose using Kanban Boards to organize three viewpoints (Time, Task, and Team) so that the whole team understands the current status of the project and can work in an autonomous, motivated and collaborative manner. Finally, I introduce a software tool “TRICHORD” that implements Kanban Boards to realize project visualization from the three viewpoints.

This article argues that by committing to feasible business outcome expectations, development teams can manage the scope of agile projects successfully - to the satisfaction of sponsors, executives and users.

Not everyone involved in an agile transition wants the change to be successful. This tongue-in-cheek article details twenty things you can do to sabotage an agile transition. Of course, the twenty things also serve as reminders of things to avoid or watch out for.

Migrating to Agile is more than changing your process. It also requires a change in culture. For most companies changing culture is the most difficult part. I believe this is true for several reasons. These issues should be addressed in two ways. First, you want to address the culture needs of each group head on. We will lay out a game plan for obtaining support from line management, the team, the individual and executive management.

Writing good User Stories is difficult for new teams starting with a new agile project. Mistakes made at that point lead to wrong Test Cases, wrong understanding of requirements, and the worst of all wrong implementation which can be direct cause of rejecting the deliverables of the iteration. Lets take a look at the five most common mistakes people make writing User Stories.