Sunday, August 31, 2014

Agile - Principles and values


One of the most important things to remember is that AGILE is NOT
- A set of tools
- Process
- Methodology

AGILE is a set of values.

The Agile Manifesto as per wikipedia reads, in its entirety, as follows:

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 the items on the left more.
As we had mentioned in our previous agile article, continuous feedback is very important.
Point 1 above is on similar lines where continuous feedback is more important when we mentioned "individuals and interactions".

Working software will definitely get more value over documentation, but it does not imply that documentation is not at all needed.

With time a customers needs can change. Even due to marketing dynamics, needs can change. Hence, customer collaboration and continuous checks on delivery will help to deliver a model which the customer can appreciate.

As mentioned, market dynamics and conditions may make the customer change his requirements. Incremental reviews and phase wise delivery and continuous feedback and collaboration will help us deliver a product close to customer's needs (at that point in time).

The Agile Manifesto, as per wikipedia, is based on twelve principles:
  • Customer satisfaction by rapid delivery of useful software
  • Work closely with the customer and provide timely incremental delivery of the product
  • Incremental reviews for customer feedback
  • Capture acceptance criteria on each discussion
  • Prioritize the pending requirements
  • Conduct surveys to find the satisfaction level of the customers

  • Welcome changing requirements, even late in development
  • It is widely accepted that customer needs can change with time due to market dynamics
  • One needs to embrace this change to provide value to the customer
  • Evolve a process that accepts these changes
  • Changes need to be prioritized with existing requirements
  • Working software is delivered frequently (weeks rather than months)
  • Frequent incremental delivery of software.
  • These are sprint reviews (may be in a couple of weeks and not months).
  • Automated, performance and load testing plays an important part in testing such small delivery cycles continuously.
  • Close, daily cooperation between business people and developers
  • In non-agile models, business and development teams rarely interact. This could lead to a delivery of a product that may not adhere to the customers need at that point in time.
  • There should be frequent interaction between business and development teams.
  • Development team benefits from knowing the business perspective (about the function of the software)
  • Business teams gets insight into development details that they may not have an idea about when they conceive the product needs.
  • Projects are built around motivated individuals, who should be trusted
  • Motivated employees need to be encouraged and involved in the product.
  • Employees feel empowered and result in higher output and better product
  • Face-to-face conversation is the best form of communication (co-location)
    • Lot has already been mentioned about communication, hence not delving much into this point.
  • Working software is the principal measure of progress
  • Self explanatory - a working software is a measure of progress.
  • In waterfall, there is no working software at any point in time (in the schedule) except at the end. Thus, from customers perspective, there has been no progress to see.
  • For every incremental release, there should be a working demo which should go through automated set of testing.
  • Customer feedback is gathered at the end of the demo and any new changes need to be prioritized and embedded for the next subsequent releases.
  • Sustainable development, able to maintain a constant pace
  • Pretty much self explanatory, constant pace need to be maintained.
  • However, need to ensure that members of teams do not work crazy hours/weekends (maintain 40 hours a week)
  • Continuous attention to technical excellence and good design
  • I guess this is a no brainer. Team members need to have the the technical expertise to deliver a quality product.
  • There should also be a focus to continuously learn and improve upon coding standards, design, integration and testing.
  • Simplicity—the art of maximizing the amount of work not done—is essential
  • Reduce non value added work of team members.
  • Simplify process of deployment or remove extra features etc
  • Self-organizing teams
  • As the product evolves, there is a need to change the architecture, requirements, design etc. Team members must be involved in decision making leading to greater ownership and responsibility.
  • This is not easy and requires a lot of team work and an open culture that promotes team based rewards etc
  • Regular adaptation to changing circumstances
  • Periodically, there should be an introspection on how to become more effective and be able to adapt to changing demands and requirements.
  • Self organizing teams are the key to real improvement.
  • There should be a commitment to adapt and improve with every iteration over a period of time.

No comments:

Post a Comment