Zest Software is an Open Source Web Application development company focused at delivering high quality software that is adaptable to reflect the business processes within your organisation. Saying this is easy. Being able to manage software development and actually deliver high quality software takes a lot of effort from both our team of experts and the customer. During the past years we have encountered various problems in managing our projects. In our vision making mistakes is only human, it is the way you respond and learn from those mistakes that make the experience valuable.

In the past year we have step by step adopted some valuable best practices from Extreme Programming. After each step we critically evaluated each decision and tailored the rules to our needs. As a result we developed a system which is loosely based on Extreme Programming and fully supports our development process.

It is about being open about what we are capable of doing and then doing it. And, allowing and expecting others to do the same. It is about getting past our adolescent surety that "I know better than everyone else and all I need is to be left alone to be the greatest." It is about finding our adult place in the larger world, finding our place in the community including the realm of business/work. It is about the process of becoming more of our best selves and in the process our best as developers. And, it is about writing great code that is really good for business.

Good relationships lead to good business. Productivity and confidence are related to our human relationships in the workplace as well as to our coding or other work activities. You need both technique and good relationships to be successful. XP addresses both.

Prepare for success. Don't protect yourself from success by holding back. Do your best and then deal with the consequences. That's extreme. You leave yourself exposed. For some people that is incredibly scary, for others it's daily life. That is why there are such polarized reactions to XP.

XP is a style of software development focusing on excellent application of programming techniques, clear communication, and teamwork which allows us to accomplish things we previously could not even imagine. XP includes:

• A philosophy of software development based on the values of communication, feedback, simplicity, courage, and respect.

• A body of practices proven useful in improving software development. The practices complement each other, amplifying their effects. They are chosen as expressions of the values.

• A set of complementary principles, intellectual techniques for translating the values into practice, useful when there isn't a practice handy for your particular problem.

• A community that shares these values and many of the same practices.

XP is a path of improvement to excellence for people coming together to develop software. It is distinguished from other methodologies by:

• Its short development cycles, resulting in early, concrete, and continuing feedback.

• Its incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.

• Its ability to flexibly schedule the implementation of functionality, responding to changing business needs.

• Its reliance on automated tests written by programmers, customers, and testers to monitor the progress of development, to allow the system to evolve, and to catch defects early.

• Its reliance on oral communication, tests, and source code to communicate system structure and intent.

• Its reliance on an evolutionary design process that lasts as long as the system lasts.

• Its reliance on the close collaboration of actively engaged individuals with ordinary talent.

• Its reliance on practices that work with both the short-term instincts of the team members and the long-term interests of the project.

quoted from Extreme Programming explained (SE)

Prince2, ITIL, WaterFall, Agile Software Development, they all are intended for and add value in particalur environments.

Agile methods are often characterized as being at the opposite end of a spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined." A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive." Agile methods exist on the "adaptive" side of this continuum.

<--Agile--> <--Iterative--> <--Waterfall-->
<----|-------------|----------------|----->
Adaptive                         Predictive

We believe that "adaptive" methods are better suited for web application development, than methods like Waterfall. During the developement period, which normally takes 1 to 6 months, customers continously get new insights and need to be able to redefine the specification to leverage business values.

The first projects we used the WaterFall method, which resulted in a perfect pitfall due to optimistic estimates and fixed price contracts. This was a very harsh way to learn this method didn't work well for us, so we explored other ways to manage our development process. After a few googles Extreme Programming showed up.

Extreme Programming suggests using cards and have the customer write down small features in "stories". Each card contains a story which will be broken down in technical tasks, which will be estimated by the programmers. I think this is a good practice, because it assures customer involvement to write the specs and estimating small tasks is easier and more accurate. For this to work the customer should always be around to answer questions about or even rewrite stories.

In real life we were not able to persuade the customer to work like this, so we decided to use our development skills to write a tool which assists us in involving the customer, by allowing the customer to add and modify stories in the portal, a place which is available to both parties 24 x 7.

The next project we started writing stories for the customer and divided work in iterations on our website. This project also didn't work that well because we were continuously changing the stories, each time delaying the iteration deadline. But we found out that customer involvement really leverages quality. The system almost fully suited the customers "dreams", but we still got off budget.

The last three projects, we were able to give better estimates because we now have data about actual time spend on tasks. Making the end date of an iteration absolute we discovered this provides a good opportunity to inform your customer of the current status. Telling the customer why some of our estimates were off creates an understanding of the complexity of developing software. By allowing the customer to decide on the trade offs he has better control over his budget.

So in a way Extreme Programming has been useful for us, but instead of living by the rules we bended the rules to adapt it to our environment. It is not a spoon.

Quality in the first place is about the customer's perception and expectations of the system you develop.

At the beginning of a project, the customer in his mind has build up a vague image of how a web application can support his business. We would under estimate our customer's intelligence if we'd think we are able to build such a system based on a few meetings.

We believe the customer is the domain expert within his business and needs to actively participate during the project, to provide us with his knowledge about his domain. That way we get a better understanding of the required features. During the past years we learned that customer involvement does leverage quality.

Besides customer involvement, communication is one of the key success factors. By working at the customer's office at least one day a week we assure effective oral communication and focus on getting feedback from the customer. At our office we often work in pairs on programming tasks to share technical knowledge and continuously give each other feedback.

As development best practices we:

• use Subversion, a code versioning system to keep track of all changes,
• write unit tests,
  
• adhere to coding standards like Python's PEP-8,
  
• adhere to XHTML 1.0 and CSS 2 standards by W3C , if needed compensate Microsoft Internet Explorer bugs,
  
• registrate time per task to get feedback about our estimates.