1 / 22

Agility – The problems solutions approach

Agility – The problems solutions approach. The Software Quality challenges and the solutions therein. Agenda. Introduction Definition of project quality success Failure Case Studies and quality could have been improved Scrum ceremonies and XP Engineering Practices for quality

yukio
Download Presentation

Agility – The problems solutions approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agility – The problems solutions approach The Software Quality challenges and the solutions therein

  2. Agenda • Introduction • Definition of project quality success • Failure Case Studies and quality could have been improved • Scrum ceremonies and XP Engineering Practices for quality • Challenges with ceremonies and XP Practices • Agile Adoption and Organizational Transformation challenges • Why Organizational Transformation • Agile or Fragile? • Open Discussion and Questions

  3. Nilotpal Das (Neil) • TOGAF & Zachman Certified Enterprise Architect with Invesco • Lean and Agile Coach, Practitioner and Trainer • I Write • Blog – http://www.nilotpaldas.com • 3.47 AM - http://www.tinyurl.com/k4wfcxy • I Speak • Enterprise Architecture (TOGAF, Zachman, etc.) • Lean • Agile Introduction

  4. The battle of 1964 Round 1 – Liston underestimates Clay Round 2 – Liston calms down a little but still looking for a KO Round 3 – Clay cuts Liston Round 4 – Clay rests Round 5 – Liston Gets Vaseline in Clay’s eyes Round 6 – Liston is tired, Clay is stinging Round 7 – Liston doesn’t answer the bell Agile lessons learnt

  5. Project Quality and Success Project Success Criteria Under Budget On Time Anything Else?

  6. Case Study 1 – The Book Reader Application • Client into book publishing and wants to gift the app to customers • Competitive advantage and time constraint • Over Commitment due to business imperative • Over Estimation due to not compromising on features • The Blame Game

  7. Learnings • End Result of the book publishing project • How competition executes same project differently • People quality perspective • Technological quality perspective • Process quality perspective How things could have been better Satisfy the customer Deliver working software frequently Business people and developers must work together Motivated individuals Face to face conversation Working software is the primary measure of success Sustainable development

  8. Case Study 2 – The Information Security Project • Organizational Structure and Business Model • Requirement for enhanced security • Technical and Infrastructural challenges • Other departments and the end result • How things could have been better

  9. Learnings • They should have spiked the technology • Stakeholder identification should have been done properly • Shorter iterations delivering working software would have identified the challenges earlier causing smaller financial damage • Better conversations with stakeholders would have resolved technical challenges up front How things could have been better Satisfy the customer Deliver working software frequently Face to face conversation Motivated individuals Working software is the primary measure of success

  10. Case Study 3 – The small Android App • The Project Manager’s unique approach (competition instead of cooperation) • Silos and information walls • Duplication of work • People Challenges • Leadership challenges

  11. Learnings • Shorter delivery cycles could have helped • Proper sprint planning was not done • Visual Progress Tracking could have helped • Teams should have been self-organizing • Scrum Master should be a process coach rather than a delivery manager How things could have been better Deliver Working Software Frequently Build projects around motivated individuals Face to face conversations Working software is the primary measure of success Simplicity Self – Organizing Teams Retrospectives

  12. Case Study 4 - Porting automation of a legacy application • Legacy Application • Business Decides to automate source code porting • Compilers, porters created • Technical challenges around auto generation • Not enough business participation • Project delivered, but lack of organization success

  13. Learnings • Development team should have spiked the new technology to ascertain feasibility • Business teams should make business decisions and technical teams should make technical decisions • Smaller delivery cycles could have allowed fail fast • Estimates should have been revisited after the first few iterations to ensure quality How things could have been better Satisfy the customer Deliver working software Face to face conversation Continuous attention to technical excellence Self organizing teams

  14. Case Study 5 – The telephony Platform • Over Commitment • The Death march and the fear driven business • The mountain of technical debts • Non automated QA even for routine testing • No rotation, too many shortcuts • Leadership not bought into Agile • Business should do business decisions, technical should do technical decisions • Engineering folks should speak the business language • Perceived constraints of business imperatives

  15. Learnings • The business people should not have taken a technical decision • The project was delivered but did the project succeed? • Organizational Perspective • Personal Perspective • The same project could have been delivered in the same time in a much better quality if less would be attempted in each iteration How things could have been better Satisfy the customer Deliver working software frequently Business people and dev team must work together Face to face conversation Working software is the primary measure of success Sustainable development

  16. Scrum and XP Practices that help • Scrum • Sprint Planning and Release Planning • Daily Scrums • Sprint Review and Demo • Retrospectives • XP • Pair Programming • Test Driven Development • Continuous Integration • Do you think any of these are not worth the effort? If so why?

  17. Agile Adoption and Organizational Transformation Challenges State of Agile Survey Buy – In From Technology and Business Grassroots commitment – inside and outside Consistent understanding of Agile Pilot Groups and Knowledge Sharing

  18. Organizational Transformation Challenges • What’s the best approach • Top Down • Bottom up • An unpredictable future state (tailoring agile) • All Pervasive and Dramatic Changes • Inside and outside engineering • Emergent design • Best Practices are dangerous

  19. Why Organizational Transformation? • Higher Productivity and Lower Cost • Improved Employee and Job Satisfaction • Faster Time to Market • Higher Quality • Improved Stakeholder Satisfaction • What we’ve been doing, no longer works • The Version One State of Agile Survey

  20. Agile or Fragile? • Humans hate change • Change is inevitable • Alvin Toffler’s Future Shock • Don’t accept change. Embrace it.

  21. Questions

  22. Contact Information • Nilotpal Das • Phone: 9959098490 • Email: nilotpaldas@hotmail.com • Linked In: linkedin.com/in/nilotpaldas • Twitter: twitter.com/_nilotpaldas

More Related