Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile 101 - Building Software Faster, Cheaper & Better


Published on

The Business Excellence Series which we conduct every alternate month, has now become a very popular series, as it provides a platform for discussion on some of the latest trends in the area of Software Development. Participants have also started associating Ms Sonu Sood of Birlasoft as the moderator for all these sessions who has unfailingly supported this initiative by sharing her deep insights on the subject. This time, we had Mr Vinod Tyagi of Impetus, who is a software practitioner, evangelist and a Certified Scrum Master, addressing on the subject.

Published in: Business, Technology, Education
  • Be the first to comment

Agile 101 - Building Software Faster, Cheaper & Better

  1. 1. Agile 101 - Building Software Faster, Cheaper & Better June 26, 2009
  2. 2. Who am I?  Software Practitioner & Evangelist  14 years of building software and learning  Certified Scrum Master  Director Engg. - Lead Impetus Labs, Consulting and Research  I am available for  Speaking on Technology & Agile  Help & Support your Agile journey  (e)  (m) 931 310 2111 2
  3. 3. Agenda  Agile 101  What is Agile ?  Agile Manifesto  Agile Principles  7 Habits of Agile Team  Agile Myths and Misconceptions  Agile & Service Industry 3
  4. 4. Some facts … 1995 : The CHAOS Report **  Type 1 : Project Success  On time on budget, all features are delivered (16.2%)  Type 2 : Project Challenged  Completed and operational but over budget, fewer features than specified (52.7%)  Type 3 : Project Impaired  Cancelled at some stage (31.1%) **Tom Clancy 1995 | The Standish Group International 4
  5. 5. Some facts … Traditional Processes were not helping  Customers unhappy  Requirement Changes are dealt through risk avoidance strategy  i.e resist requirement change  Eliminating change means business failure  So ?  These led to evolutions in the way we approach software development 5
  6. 6. Evolution  Agile is evolutionary not revolutionary  The context of developing software is changing ● Technology driven business innovation ● Dynamic Market conditions ● Time to Market ● Requirement Stability  What does it mean for software development? ● You cant win a 20-20 game with a test match strategy 6
  7. 7. Introducing Agile The BRAVE new way of developing software  Don’t avoid risk, take it as unavoidable and accept it  Requirement Changes are dealt through risk acceptance strategy 7
  8. 8. Agile Manifesto “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.” Agile Manifesto 8
  9. 9. Principles Behind Agile Manifesto  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software  Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale 9
  10. 10. Principles Behind Agile Manifesto  Business people and developers must work together daily throughout the project  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation  Working software is the primary measure of progress 10
  11. 11. Principles Behind Agile Manifesto  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely  Continuous attention to technical excellence and good design enhances agility  Simplicity--the art of maximizing the amount of work not done--is essential.  The best architectures, requirements, and designs emerge from self-organizing teams.  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 11
  12. 12. So, What is Agile? Simply Stating … It a way of developing software that follows the Agile Principles  There are a number of agile software development methods; most attempt to  minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks  Each iteration is like  miniature software project of its own  includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation 12
  13. 13. So, What is Agile? 13
  14. 14. 7 Habits of the Agile Team  Self Organizing  Deliver Frequently  Plan to Learn  Communicate Powerfully & Effectively  Test Everything  Measure Value  Clear the path – Remove Roadblocks 14
  15. 15. Myths & Misconceptions  Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies  A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive”  Adaptive methods focus on adapting quickly to changing realities  When the needs of a project change, an adaptive team changes as well  Predictive methods, in contrast, focus on planning the future in detail  A predictive team can report exactly what features and tasks are planned for the entire length of the development process  Predictive teams have difficulty changing direction 15
  16. 16. Myths & Misconceptions  Agile methods v/s CMM/CMMi  CMM/CMMi is NOT a method or a process model  It is a reference process benchmark  CMM/CMMi don’t prescribe what process (for developing software that is) to use  Agile Software Development process can be benchmarked on CMM/CMMi models  Initial, Managed, Defined, Quantitively Managed & Optimizing 16
  17. 17. Myths & Misconceptions Agile __________  Is a silver bullet  Will solve my resource issues  Has no planning/ documentation/architecture/ <insert pet peeve>  Is a license to hack  Creates quality issues  Is undisciplined  Doesn’t build on my previous experience / expertise  Is not proven  Is not being used by industry leaders 17
  18. 18. Agile & Service Industry  Agile does not work for the Service Industry  To the contrary it works very well, rapid gains in productivity and customer satisfaction  Have to ensure a few basics  Be ready for ugly stuff …. Courage  Be mindful of your context …. Success Stories are what they are … Stories  Organizational changes required …. Champion at top  Use what works … practices first method next  What about contracts?  Mindset change needed …. Does not make one lose the safety net 18
  19. 19. Thank You Questions?
  20. 20. Pair Programming