For the last four years we have operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we've discovered that we can make it work, although the benefits are still open to debate.
Responsibility driven design is an approach that helps you shift focus from object state to interactions and responsibilities. This article shows how test driven development with mock objects facilitates responsibility driven design and drives you towards a more cohesive, loosely coupled design. Examples in Java.
As part of my job working with different teams, the biggest challenge I see is how the team's work can be measured in terms of business value delivered. We need to answer a few questions to get a solution.
The idea of driving development with tests has been popularized by the agile development movement. The fact is that testing and coding are inseparable components of software development. We get the best results with testers and programmers work closely together. How can we deliver real value to the business frequently? How can we know how much testing is enough? Let’s look at how testers and programmers collaborate to produce high-quality software.
Traditionally, software development projects started out with an idea and then tried to identify all the requirements needed to make that idea "complete" for the intended users. This long process was expensive (and sometimes ended in a “no-go” decision only after a great deal of money was spent) and did not place enough emphasis on value returned for the investment made. Agile has a tool that can help organizations re-focus on return on investment: value-driven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea.
The authors identify their perceived limitations in agile processes based on an analysis of published accounts. This is mostly an analytical study, based on the authors' experiences on a few XP projects.
This compilation of three brief articles by IBM Rational thought leaders describes how the IBM Rational Unified Process, or RUP, is not only "agile" in its own right, but also encompasses much of the guidance teams need to scale agile techniques successfully.
Software development is not a solitary pursuit, it requires collaboration with other team members and departments. Most organisations establish a software lifecycle that lays down how these interactions are supposed to happen. The reality is that many teams find that development process does not fit their needs or is simply not followed consistently. It’s easy to grumble when this happens and it can be frustrating if you have ideas for improvements that don’t get taken up. This article offers a tool that may help your team get to grips with process improvements. This tool is the Retrospective. This article aims to explain what you need to do to facilitate a Retrospective for your team.
Incremental development is distinctly different from iterative development in its purpose and also from its management implications. Teams get into trouble by doing one and not the other, or by trying to manage them the same way. This article illustrates their differences and how to use them together.
An interesting reflection on the Agile phenomena trying to identify the multiple aspects of the agile culture and to separate the hype from the important concepts. It recommends to look at the agile practices with a more cooler head and always consider the context where they are applied.