Please enter an article title, author, or keyword
Agile SCM: It’s All Related

In this article, the authors the use of basic patterns that can help build a software configuration management process that works well with your agile development environment. They discuss how codeline policy, private work spaces, smoke tests, private system builds, integration building, unit testing, and regression testing all work together to enable you to maintain an active development line.

Jared Richardson - Just Ship It - No Fluff Just Stuff 2006

Jared Richardson, author of the book Just Ship It, offers advice that can allow nearly any shop to make there process more agile.

Bob Payne's picture Bob Payne
Ramnivas Laddad - AOP - No Fluff Just Stuff

Ramnivas Laddad talks about Aspect Oriented Programming, which isn't just for security and logging anymore.

Bob Payne's picture Bob Payne
Brian Sletten at No Fluff Just Stuff 2006

Brian Sletten, a Washington, D.C.-area consultant, talks about NetKernal and the Semantic Web.

Bob Payne's picture Bob Payne
Approaching the Implementation of CM

When landing an airplane, the approach is considered quite important. If the approach vector is off even by 1%, the plane may careen off the other end of the runway. Also, if the approach is incorrect, effort such as fuel and time is unnecessarily expended and wasted, especially if circling must occur.


Mario  Moreira's picture Mario Moreira
When In Doubt, Throw It Out

Peter Clark's company recently embarked on a "Lean Office" initiative. Now, Peter thinks many of you have steam shooting out of your ears just from reading those words. You probably think that it is just another lame management initiative that will take valuable time away from what is really important: coding and (maybe) testing. But in this week's column, Peter explains why this is the best initiative yet.

Peter Clark's picture Peter Clark
Pair Programming Observations

Say "pair programming" to a programmer and he'll probably frown or turn his back on you. But add some rules the programmers must follow--rules that help maintain each person's sanity--and he just might come to find this practice rewarding and beneficial. This article, originally published on Jeff Langr's website, explains the rules and how certain teams have reacted to this structured version of pair programming.

Jeff Langr's picture Jeff Langr
Communication During a Crisis

When a crisis hits a business, you've got to work hard and fast to mitigate the negative consequences--a process which includes communicating with your clients. In this week's column, Payson Hall reminds us that keeping clients in the know is critical to a successful recovery and will stabilize the clients' faith in you, even when all has failed. Drawing from a recent crisis in which he was the client, Payson gives us key points to consider the next time we are overwhelmed by customers who want to know when business will return to normal.

Payson Hall's picture Payson Hall
Best Practices In Global Agile Development For Product Innovation

Agile over the wire and how to make it work.

In our experience, pure-play Agile development is destined to fail in a global delivery model. The basics of Agile, such as the emphasis on face-to-face communication, close interaction between teams and an adaptive approach to product development, are not possible while engaging an offshore team. However, by injecting process adaptations, Cognizant has successfully enabled some facet of "specially customized" Agile methodologies. In fact, a large percentage of Cognizant's software product innovation services use Agile practices in some form or the other.

TechWell Contributor's picture TechWell Contributor
Iteration and Release Retrospectives: The Natural Rhythm for Agile Measurement

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Agile Manifesto principle 12)

A cornerstone of agility is the team's commitment to continued reflection and adaptation. For most teams, there is a natural cadence to this process as iterations occur frequently, typically every one to two weeks apart, and releases occur every two to four months. As such, the iteration boundary represents a frequent opportunity for immediate feedback and quick mid-course correction, primarily focused on the team's ability to simultaneously define, code and test new functionality in a time box. At the release boundary, the measures move to those things that reflect the team and the organizations ability to move that functionality from "inventory" to delivered product or system. In this article, we'll describe a set of iteration and release metrics that have been used to good effect by a number of agile teams. In our experience, teams that are effective in using these iteration and release metrics have the best chance to achieve the maximum benefits of agile.

TechWell Contributor's picture TechWell Contributor


Upcoming Events

Sep 21
Sep 22
Oct 19
Nov 08