AGILE IN ACTION

Tuesday, 10 January 2006

Why agile principles are important

Posted by Simon Baker

The principles of agile methods such as Extreme Programming and Lean Development are simple rules that govern behaviour. They guide practices and facilitate decision-making at the ‘coal-face’ rather than restricting it to the management echelons of an organisation by providing a framework that enables experienced agile developers to make intuitive decisions quickly without having to wait for instructions or permission.

An experienced agile software development team is a highly social group that is self-organising around these principles and acts with coordination and collective behaviour. This collective behaviour comprises:

  • Collective mind [1] where individual team members develop shared understandings of the team’s tasks and of one another, and come to understand how their work contributes to the work of the team thereby facilitating team performance.
  • Swarm intelligence which gives a team the ability to adapt to changes, and robustness which enables them to still perform and deliver even when one or more members fail.
Extreme Programming principles:
  • Humanity : Acknowledge human frailty, leverage human strengths, and balance individual and team needs.
  • Economics : Enhance the option value of the software and the team while remembering the time value of money.
  • Mutual benefit : All activities should benefit everyone.
  • Self-similarity : When something works in one context, try it in another. Even if it eventually doesn’t work, it’s a start.
  • Improvement : ‘Perfect’ is a verb and not an adjective. Always seek to improve.
  • Diversity : The team should comprise people with different backgrounds, skills and perspectives.
  • Reflection : Think about how you’re working and why you’re working.
  • Flow : Deliver a steady flow of business value by engaging in all activities simultaneously.
  • Opportunity : See problems as opportunities for change and learning.
  • Redundancy : Don’t be afraid to include redundancy, e.g. a distinct testing phase after development, if it helps prevent disaster.
  • Failure : If you’re having trouble succeeding, don’t be afraid to fail.
  • Quality : Always push for higher quality.
  • Baby steps : The overhead of small steps is less than when a team wastefully recoils from aborted big changes.
  • Accepted responsibility : Responsibility cannot be assigned. It can only be accepted.
Lean principles:
  • Eliminate waste and spend time only on what adds real value for the customer.
  • Amplify learning and increase feedback when facing tough problems.
  • Decide as late as possible to keep options open as long as practical, but no longer.
  • Deliver as fast as possible , aiming to deliver value to the customer as soon as they request it.
  • Empower the team so that people adding value use their full potential.
  • Build integrity in , don’t try to tack on integrity afterwards.
  • See the whole , don’t optimise parts at the expense of the whole.
References:
[1] K. Weick and K. Roberts, "Collective Mind in Organizations: Heedful Interrelating on Flight Decks," Administrative Science Quarterly, 357-381 (1993).




1 Comment

You or your readers may be interested in this blog all about agile development:

http://www.allaboutagile.com

In particular there is a description of 10 key principles of agile development irrespective of which methodology you may be using:

http://kw-agiledevelopment.blogspot.com/2007/02/10-things-you-need-to-know-about-agile.html

And there's also an agile development forum "all about agile" for further discussion with peers:

http://www.groups.google.com/group/allaboutagile

I hope these resources are useful.

Kelly Waters
http://www.allaboutagile.com

Comment by Kelly Waters

Creative Commons Licence

Recent Posts

  1. System failure is inevitable so design for a fast recovery
  2. Delight comes as a surprise in unexpected places
  3. Help create business agility. Bake quality in
  4. Governance - Friend or Foe?
  5. 70% Forum
  6. Measuring purpose. Measuring customer delight
  7. Stop pushing features and start delighting users
  8. Lost without a goal
  9. Emotion creates the common language
  10. Five sneaky ways to kill an initiative

Archives

  1. 2012 (16)
  2. 2011 (24)
  3. 2010 (31)
  4. 2009 (41)
  5. 2008 (69)
  6. 2007 (152)
  7. 2006 (128)
    1. December (16)
    2. November (26)
    3. October (7)
    4. September (11)
    5. August (7)
    6. July (7)
    7. June (4)
    8. May (4)
    9. April (4)
    10. March (4)
    11. February (14)
    12. January (24)
      1. Look after your product backlog
      2. 1-week iterations
      3. Root cause analysis using 5 Whys
      4. Agile In Action is now available at Artima
      5. Planning with the Horizon of Predictability
      6. The knowledge worker and the new organisation
      7. Setting Norms to help internalise Agile values
      8. Agile is ... Agile isn't ...
      9. It doesn't have to be about business value
      10. Task-switching is waste
      11. Flow, ideal time and the E-factor
      12. A Scrum Master is like a music conductor
      13. Slack != Waste
      14. Go on. You know you want to. Say 'Hello'
      15. Spike
      16. Why agile principles are important
      17. Pareto Principle
      18. My interaction style
      19. An 'aeroplane in flight' metaphor for agile tracking
      20. A Scrum Master is like a skilled helmsman
      21. Fun and games
      22. Innovation games from enthiosys
      23. Thomas Edison on 'Lean'
      24. The speed of thinking
  8. 2005 (63)
  9. 2004 (2)

Tags

agile (43) big visible chart (15) conference (40) culture (18) extreme programming (21) leadership (18) lean (47) people (26) planning (17) retrospective (18) scrum (41) story (19) team (30) testing (19) xpday (19)