There continues to be a lot of debate on whether Agile is mainstream. According to a Forrester report published in early 2010, while widespread “Agile” use of the iterative software development processes is found, " teams are not adopting scrum, extreme programming, or another specific Agile approach, but are embracing agile as an ethos or philosophy and cherry-picking the best bits from many different process models to develop a formula unique to their own situation." However, the largest category in the survey – and the one that is the most telling is that 30.6% of the respondents said they do not use a formal process methodology. Add to this my own experience implementing Agile, reading the latest Agile literature (e.g., articles, research, books, etc.), and discussing Agile (and Agile implementations) with people across numerous companies in North America, Europe, and Asia, and what this indicates to me is that:
This two-part article explores branching strategies—development tactics that allow teams to work concurrently on different features and maintain the relationship between them. In part one, Steve Berczuk explains what branches are, common types of them, and the tradeoffs between branching styles.
In this article, Jennitta Andrea explains how a community of practice retrospective differs from a project retrospective. She also explores the motivation for a community to perform this type of retrospective.
As compared to other development methods, agile is clear, straightforward, and rewarding for all of those who are involved in the process. Most of you know this already—that’s why you’re here! Clearly, a successful transition to agile requires a strong organizational commitment and a number of management and development changes. With that in mind, the white-hot movement to this trend over the past year continues to amaze me. In striking parallel, the industry has seen this same sort of resonance around the trend to the “cloud”—secure anywhere access by distributed teams to a centralized set of services and compute resources that span the complete lifecycle of the development and deployment process.
If Agile is going to make a difference to an organization, it must accomplish two things. First, it must assist us in being driven by business needs—not the development organization. Second, it must help us with the entire value stream—not merely part of it. Lean-agile practices presents us with an opportunity to reunite the business and software development organizations so our Application Lifecycle Management (ALM) can focus on value, not merely delivered software.
Trust is more than a feeling. In a project, it is something that can be grown from careful planning and development of good requirements. Ellen Gottesdiener describes three types of trust which can be built from good requirements and team management.
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.
The desire to control comes through loud and clear in the way most people’s worth is measured by their company’s performance management process. When it comes to performance review time, these controlling phrases crop up anew. Many successful agile coaches have been dismayed to learn that, despite the amazing results their teams produced and despite the new clarity and purpose that pervades the workplace, measuring their contributions still includes phrases such as “Herd the cats.”
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.
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.