Agile Adoption Roadmap 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: |
||
Agile is the Mainstream. So What? The Quest for Quality We have seen software development evolve from ad hoc to CMMI, to Unified Process, to Agile, to Lean, to what next. Why the evolution? Agile has become the mainstream software development method today. So what? What have we been missing? What are we searching for? In my opinion, it is the quest and delivery of a high quality product. We should strive for quality being non-negotiable. Build something without an emphasis on quality and you are building on a poor foundation that will eventually lead to collapse and result in a final product with little to no commercial or operational value. |
||
![]() |
End-of-Release Branching Strategies 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. |
|
Distributed Multi-Source Development What are leading development organizations doing to increase innovation, agility and embrace new technologies? The answer: Distributed multi-source development Large software projects that are late. Missed schedules. Budget over-runs. These aren’t pleasant challenges to manage, yet they are hallmarks of traditional waterfall software development methodologies. This common approach to creating software is yielding to two powerful approaches to development: distributed development using Agile methodologies, and multi-source development, combining closed source with free and open source components. |
||
Warning: No News is Not Always Good News When your customers aren't complaining about the services you provide, it's easy to assume you have happy customers. But that could be a serious mistake. In this week's column, Naomi Karten describes what happened in two organizations that misinterpreted the absence of customer complaints. |
||
Cloud-Driven Development Agile methodologies aren't the only way to empower your team; utilizing cloud-driven development is another great way to improve processes throughout the development lifecycle. Testing can be done earlier, and costs can be saved, by turing toward the cloud on your next project. |
||
The Beauty of Agile in the Cloud 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. |
Bill Portelli
October 18, 2010 |
|
A Community of Practice Retrospective 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. |
||
![]() |
Ready to Ship? On the surface, a Broadway musical, a newspaper, and software may not seem to have much—if anything—in common, but they have one common thread. All are delivered on a fixed schedule. But of the three, software tends to stray the most from the fixed schedule. In this week's column, Jeff Patton says that by focusing on the readiness of the entire product—as done in theatrical performances and when publishing a newspaper—and not just on the completion of the planned bits of work, you can produce software on a fixed schedule that you know is ready to ship. |
|
Lightweight Application Lifecycle Management Using State-Cards It is a well known fact that all applications are different; all application development teams are different. So, why should we expect application lifecycle management to be fixed? There is no such thing as “one size fits all.” Yet, it is also common sense that there must be something in common, as otherwise there is absolutely no way to learn from experience and mistakes. The challenge is then to find a middle ground that is easy to communicate to the development team and stakeholders. |
Pages
Upcoming Events
Sep 22 |
STARWEST Software Testing Conference in Anaheim & Online |
Oct 13 |
Agile + DevOps USA The Conference for Agile and DevOps Professionals |
Apr 27 |
STAREAST Software Testing Conference in Orlando & Online |