This series of articles have been in my task list for too long now.
it is kind o shame that I'm being a scrum master for so long never ever wrote any article about it! So I'm finally starting a new series of articles on agile development.
Agile development
Agile development is an old idea from the sixties but only in 2001 achieved the mainstream in the form of a public manifesto.
This methodologies is all about adapting to change, it relies on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile methodologies promote adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change
Don't worry about this definition, later we will explore SCRUM, one of the most successful implementations, and this everything will become clear
The agile manifesto
The funny thing about Agile is that there are no fixed rules, agile is a set of four principles that we should follow. Nothing is said about how we should follow, it is our responsibility to implement those principles in a way that works for us and our company culture.
We need to see agile as a way of thinking a way of living, this principles don't necessarily apply exclusively to software development, companies like Toyota use them successfully
Individuals and interactions over processes and tools
Agile development promotes self organization and communication is key.
We should favor short communication lines over rigid processes that define how we should interact with each other.
In the real world this means we should favor a short informal face to face or phone talk over a formal email or letter.
You can get much more valuable information from a direct informal conversation than in writing.
Don't take this to the extreme, written communication is important after all “if it is not written it never happened” . You can for example have the short face to face talk, then either send an email with the summary of the conversation.
Working software over comprehensive documentation
Working software is what you should stand for, after all that is what the client is expecting.
It is also a key instrument to gather feedback, most of the times the client only really gets the feeling of what he wants or doesn't want after trying the software.
So instead of going to meeting with enough paper to destroy a forest bring him a quick mock-up or a prototype. Later we will see some techniques to quickly build working software so the client can get a feeling of the product
No one likes to go through 500 pages of detailed descriptions, seeing it in action is much better.
Customer collaboration over contract negotiation
Requirements cannot be fully collected at the beginning of the software development cycle, therefore#Agile development
Agile development is an old idea from the sixties but only in 2001 achieved the mainstream in the form of a public manifesto.
This methodologies is all about adapting to change, it relies on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile methodologies promote adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change
Don't worry about this definition, later we will explore SCRUM, one of the most successful implementations, and this everything will become clear
Responding to change over following a plan
Everything changes, software is not different, we should embrace that idea instead of fighting it.
We need to accept and incentivate change for the customer competitive advantage.
When developing software we need to keep change in mind by building software that can be changed, we need to be smart and design the system as series of small modules that can be combined to provide different functionality.
This does not mean that we should write code that predicts all possible situations just in case the client changes something, only write the code needed to fulfill our goal needs to be written, instead we need to make use of proper design, decoupling, meta-programming in order to write flexible systems