Crystal, eXtreme Programming & Feature-Driven Development - True to the Agile Manifesto Values?

Introduction

Crystal, eXtreme Programming (XP) & Feature-Driven Development (FDD) are well established methodologies used alongside Scrum to help a team be more agile. But how well do the methodologies promote the four values of agile, and aid a team in achieving them?

Individuals and Interactions Over Processes and Tools 

The Crystal methodology puts it’s main focus in to the individuals in a team, and the way they interact with each other; osmotic communication between a group, focus, customer feedback and automated testing all allow a team to focus on their work, and gain value through interactions with one another rather than sticking to a set of processes/tools. 

Similarly, Extreme Programming (XP) also puts the individuals and interactions first, with the core values lying in higher quality software & a higher quality life for a software development team. By integrating a multitude of group planning/review activities, along with promoting respect & courage among a team, members are assisted in communicating and co-operating efficiently.  

Yet some frameworks such as Feature-Driven Development (FDD) concentrate on the process itself, team members will focus on building a feature list, planning by feature, designing by feature, and building by feature. No focus is put onto the individuals and interactions, leaving room for future disagreements & impediments on a project if things do not go to plan. 

Working Software Over Comprehensive Documentation 

It would be fair to say that all three of the methodologies are all in compliance with this agile principle. 

In the case of Extreme Programming, it is a priority that the process is incredibly streamlined for the sole purpose that development can be enhanced within a team. Not only do releases come out in small batches, but each batch is tested, meets a specific coding standard, is simple enough to refactor and has most likely been worked on by a pair who have peer reviewed each other’s work. 

Likewise, FDD also strides for efficiency in code for each feature – something that completely complies with the agile principle. From planning, to building there are lots of practices involved to ensure that the code is efficient including inspections, feature teams & domain object modelling – all which help the team produce effective, working software, quickly. 

While I would say Crystal does stride for working software over documentation, it is not directly. The methodology helps a team focus on their work which in turn could produce working software, but for me it is not as compelling as XP or FDD. 

Customer Collaboration Over Contract Negotiation 

Crystal offers easy access to users, allowing team members to focus on a product and its quality rather than sticking to a contracted guideline for user review. If any issues arise, an expert user can alert the team quickly to avoid redundant work, as and when it happens. 

XP presents the same benefit, having an on-site customer who can help a team through continuous review and testing of a product. This has the same advantages as the Crystal methodology in having the focus on a product and having valuable criticism. 

FDD on the other hand, does not really offer a solution for customer collaboration; the customer is produced the product once it is finished, and that’s it. The methodology follows a policy where “just enough” equals “done”, something a lot of real customers may disagree with & could cause issue within a customer-software team relationship if mistakes are made. 

Responding to Change Over Following A Plan 

Simplicity is a key value within XP, it means that code is written simply enough to be altered by any team member if needed at any time. XP also offers a range of agile, and development practices that can make it easier for a team to identify changes with the help of a customer in-house. 

FDD, conversely, is not so helpful when it comes to responding to change. The whole methodology revolves around the 4 steps of building a feature list, planning by feature, designing by feature, and building by feature – all of which don’t allow for any customer or team retrospective, or any chance to anticipate change. 

Crystal is neutral in my opinion, while there is a customer on-site who can help the team, there is also a 2-month delivery time which is a large amount of iterations of work to be released. There is the positive of having an expert on-board for review, but the large amount of work released could have to be changed which is not anticipated for. 

Appropriate Methodology 

In the case of a small team, with a short duration project, Extreme Programming is the most effective methodology of the three in my opinion. The focus is on both the software and the team, which I feel has huge benefits.

The practices involved in the methodology including planning activities, weekly cycles, customer involvement, and co-operative programming make each project easy to understand, and easy to work on in a team.  

In the case of a large team, with a long-term project, I would argue that Extreme Programming would be most practical also.

Not only does a large team get a much better understanding of a project through the range of practices involved in XP, but there is also much more collaboration between a team, frequent review from customers, and with weekly, and quarterly cycles, a project can be broken up into smaller chunks which can be useful.