Manifesto for Agile Development

agile

We guide in our work by the Agile Principles. Because of Agile Manifesto (which by the way, is printed on our office walls) we managed to improve our way of working and our customers' satisfaction. Here it is, the original manifesto wrote in 2001 and signed by a list of great people of software industry:

"We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan.

That is, while there is value in the items on the right, we value more the items on the left."

The 12 principles of Agile Software

  • Our main priority is to meet our client's needs through early and continuous functional software deliveries.
  • Specifications adjustments are welcome, even late in the development process. The Agile processes value change if it’s in the client’s competitive advantage.
  • Deliver functional software frequently, every two weeks to two months, preferably at small time intervals.
  • Business people and programmers must work together day by day all through the project.
  • Build projects around motivated people. Give them the environment and support they need and trust them they will do their job.
  • The most efficient way to send information from and towards a team is through face-to-face communication.
  • Functionally correct software is the main measure of progress.
  • Agile processes promote sustainable development. Sponsors, developers and users should be able to maintain a constant pace indefinitely.
  • Technical excellence and continuous focus on good design enhances agility.
  • Simplicity - the art of maximizing the amount of work remaining - is essential.
  • The best architectures, requirements and designs emerge from self-organized teams.
  • At regular intervals the team reflects on how they could become more efficient then they adjust their behavior as such.

 

Our observations

SOFTWARE is not “soft”.
Software DEVELOPMENT is neither ART nor SCIENCE.
It’s BOTH.

What are we?

  • Architects when we develop software
  • Artists when we design interfaces and interactions
  • Masters when we write code
  • Mean dogs when we test