Agile software development, the principles. Principle 1: Deliver valuable software field test construction software1

Agile software development, the principles. Principle 1: Deliver valuable software

This is the first of 12 posts about the principles of agile software development.
Purpose of this, and the upcoming 11 posts, is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering.

Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.

The question is: is this going to work in practice or is this only based on a nice marketing and sales story?.

Principle 1: Satisfy the customer through early and continuous delivery of valuable software.
The discussion here is of course “what is valuable software?”. 


Opinions differ between stakeholders of the project. From a developer perspective valuable software is nice designed with all OO principles of encapsulation, inheritance and abstraction. From the end-user perspective, valuable software is a rich, customizable user interface and loads and loads of features that make daily work easier. The support department sees valuable software as easy to install, configure, manage and cost-effective in maintenance.  The business owner just wants an effective TCO value in relation to the business value.  To get an answer to this question you have to get back to the business case of the project. The business case sets the GOALS of the project against to the costs of creating the deliverables to reach the goal. The Software is just one (in many cases the most important) of the deliverables of the project and the customer uses the deliverable to reach the goal.

Valuable software is software that supports the goal of the project as specified in the business case. Deliver valuable software for the customer is then translated to deliver software that maximizes the added value to the business case. The value of software features depends on the customer and the environment of the end product.
In different situations this will lead to different outcomes in the discussion on valuable software.

Example 1: The User interface: in a business to business environment (or internal application) where the proposed software a single tool for data retrieval / data entry (internal systems for orders, order status, reservations etc) there primary goal is to automate the process and reduce the costs for maintenance. The user interface has to be functional and branding can be limited to a single logo. User interface design is derived from the libraries or tools available. This will result in applications that are only functional tailored and easy to roundtrip or re-generate. The user interface is somewhat awkward but with a learning curve the users get used to it (however some complaints will stay). Valuable software is in this case software that is easy to maintain change and upgrade with no or limited tailor-made interfaces.

Example 2: Interfaces. When an interface is built between two parties that know each other well and keep each other informed about the changes in both applications the interface can be lean and mean. A simple xml or even text/sql (ouch..) interface is sufficient to support the needs for both parties. The interface can be built quickly and without extensive knowledge about SOAP / WSDL. The interface is ready and working within a limited amount of time and costs. When an interface is built for a heterogeneous group of users within a changing environment it is more valuable to base the interface upon standards and take more time to specify extensive error messages and feedback. This way it is for a new interfacing party easy to attach to the interface en transparent for other developers. The value of this software is mainly based upon a limited amount of time explaining en assistance when connecting a new party.

Role of the projectmanager in creating valuable software
It is the role of the project manager (and the whole team) to focus the attention on those features that really matter and make a difference for this customer. Try to save the discussion about the nitty gritty details to the point that the customer has working and valuable software. In most cases the small details were not that important for the customer now that there is his valuable software tested en working on time and within budget! So do not start your software project without a business case because this will hold the answer to what is valuable for your customer.

Conclusion:
For this first principle, I can state. Valuable software is the software that contributes to a maximum to the business case. This way the development team builds the most important features at first and creates early and continuous valuable software.

Other posts about the AGILE Principles (soon to come):

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.