Evolution Towards Agile
Download as PPTX, PDF0 likes371 views
The document discusses the evolution of software development processes from traditional waterfall approaches inspired by industrial-era manufacturing towards more agile methods. It notes that while the software industry adopted sequential, specialized roles and aiming for upfront perfection like other industries, this does not work well for software due to unstable requirements, fast-changing technology, lack of experience, and late feedback. The document then introduces agile principles like valuing individuals and interactions over processes, working software over documentation, and responding to change over following a rigid plan. It describes scrum as an agile methodology and its roles, ceremonies, and artifacts for iterative development with customer collaboration.
Evolution Towards Agile
- 2. 8/24/2014 Samudra Kanankearachchi 2 What is the Business Enterprise we are in ? Technology Customers Software Products Investors Users Engineering Company
- 3. 8/24/2014 Samudra Kanankearachchi 3 How do we connect these elements together ? Process
- 4. 8/24/2014 Samudra Kanankearachchi 4 Our Industry is relatively young 1890 1980+
- 5. 8/24/2014 Samudra Kanankearachchi 5 Software processors are influenced by industrial age
- 6. 8/24/2014 Samudra Kanankearachchi 6 Engineering Process is the center
- 7. 8/24/2014 Samudra Kanankearachchi 7 Sequential Flow Vision Reality
- 8. 8/24/2014 Samudra Kanankearachchi 8 Specialization /Division of Labors 1. Designers 2. Mechanics 3. Electricians 4. Supervisors 5. Polishers 6. Painters
- 9. 8/24/2014 Samudra Kanankearachchi 9 High Quality/ Perfection
- 10. 8/24/2014 Samudra Kanankearachchi 10 We successfully copied those concepts to our industry
- 11. 8/24/2014 Samudra Kanankearachchi 11 Engineering Process is the center Engineering Process
- 12. 8/24/2014 Samudra Kanankearachchi 12 Sequential Flow We Call it Waterfall
- 13. 8/24/2014 Samudra Kanankearachchi 13 Specialized Roles Architects Designers Analysts Programmers
- 14. 8/24/2014 Samudra Kanankearachchi 14 Big Upfront Perfection
- 15. 8/24/2014 Samudra Kanankearachchi 15 Why not • Requirements not stable • Technology is advancing • Haven’t done it before • Time to market unknown • Feedback is too late • Project visibility is poor ?
- 16. 8/24/2014 Source: www.agilemanifesto.org 16 Is there a better way Individuals and interactions over Process and Tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan
- 18. 8/24/2014 Samudra Kanankearachchi 18 Scrum
- 19. 8/24/2014 Samudra Kanankearachchi 19 Working Software Working Software OVER Comprehensive Documentation
- 20. 8/24/2014 Samudra Kanankearachchi 20 Scrum – the flow
- 21. 8/24/2014 Samudra Kanankearachchi 21 Responding to Change Responding to change OVER Following a plan
- 22. 8/24/2014 Samudra Kanankearachchi 22 Individuals and Interactions What does the end user really want? What are the business rules? How does this interact with other systems? What are the validation rules? What is the best way to share project roles? Where we host the development servers? What is the best process to do testing? We need more information on this! Is there a better way of presenting data? Individuals and Interactions OVER Processing and Tools
- 23. 8/24/2014 Samudra Kanankearachchi 23 Scrum – the roles > NO PM > PO – What and When > Team - How, How much > SM –Problems, Protect, Process > Team has a SPOC
- 24. 8/24/2014 Samudra Kanankearachchi 24 Scrum Ceremonies > Backlog grooming > Sprint Planning > Sprint Review > Sprint Retrospective > Daily Scrum
- 25. 8/24/2014 Samudra Kanankearachchi 25 Scrum Artifacts > Product Backlog > Sprint Backlog > Burn down Charts
- 27. 8/24/2014 Samudra Kanankearachchi 27 You can’t ignore !!!!!
Editor's Notes
- #19: The Scrum is the one way of re starting the game after the ball goes dead.
- #20: Shippable product
- #21: All known requirements are written on to a list, analysis and elaboration later For each iteration Team decides how much they can commit Team plan only for the next immediate sprint Every day team takes a meeting – verbal commitment, no problem solving Do all activities on the requirements to get a shippable product at end Team demonstrate the work done at the end of the sprint After each sprint team look back for improvements (inspect and adapt)
- #23: Daily Scrum PO always available Retrospective Late planning, requirements