Agile successful practices

1,021 views

Published on

Presentation given by AgileTeam for Leuven Inc on successful agile practices

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,021
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
26
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Time boxed, everything is timeboxed
  • retrospective : test bij SAP/ niet over de tool maar prioriteiten van de tests
  • Agilee methoden gaan om met veranderingen en plannen is nodig om in die veranderende omstandigheden toch een plan dat aanvaardbaar is voor management te ontwikkelen. Dit is de kracht van agile methoden.
  • use relative size, compare requirements
    if plans are not acceptable for management or customers work on size and number of requirements
  • frequent replanning, start a sprint (2 weeks) and get qucik feedback. Adpating plan takes 5 minutes
    Believe the velocity and alter plans Wii or deny and go Vasa story
  • With a relative small effort for estimating the size an accuracy of 50% can already be reached. Too much effort in estimating can even result in lower accuracy
    Agile planned projects do not derive too much from original plans in size and effort
  • Seteup of infrastructure before starting the agile project e.g. sprint 0
  • Voorbeeld Simple & Advanced search.
  • Poor quality = bybeing under time pressure the bug database explodes
    Comitment = overspecialisatie en verdeling in take (vb. analyse, design, codering) heeft de teammembers verwijdert van het uiteindelijke doel nl. werkende software op te leveren.
  • Sponsor : in juni 100% risico deadline niet halen. Nu 15%
  • Voorzien een belangrijke deadline, communicatie naar klanten is reeds gebeurt.
  • end-to-end verantwoordelijkheid voor functionaliteit (opsplitsing client/server)
  • Integration issues = weakest link overall team t2m is the latest team to deliver.
  • T2m ok
    Quality no real improvements
    Scope
  • 3th attempt
  • Voorbeelden : 2 architecture : flexible aanpasbaar / overengineering. De andere simpele refactoring
    Teams should measure and know their velocity.
  • Example
    Business strategies
    Cost reduction e.g. Eliminate costly technical expert intervention by making software usable for domain specialist
    Innovation : e.g. Wii
    Including customers in software development/improving business and market input
  • Agile successful practices

    1. 1. Agile software processes and practices: setup, experiences and success factors Johan Platteau
    2. 2. Agenda Agility  Agile overview   Software iterations  Requirements & planning  Practices  Experiences 2
    3. 3. AgileTeam Value Proposition ICT intensive enterprises Software Industry Market Drivers * Positioning of software products to new target groups * Customizations of products Business drivers * Decrease time-to-market * Build the right software * Software that follows business changes * Technological & business innovation * Integration of other products as a result of a merger or acquisition * Reliable & predictable delivery of working software Organizational Drivers: * Measurement of real progress of development investments * Improved quality of software Organizational Drivers: * Growth * Distribution of software production AgileTeam enables the software evolution while maintaining the sustainable software release pace AgileTeam enables ICT to incrementally deliver qualitative working software based on the right business requirements 3
    4. 4. Agility defined  Is the early and continuous delivery of working valuable software products   Delivery at a sustainable pace Has value for the customer 4
    5. 5. Agility illustrated Needed result Agile Planned result Start Plan Driven 5
    6. 6. Agenda Agility  Agile overview   Software iterations  Requirements & planning  Practices  Experiences 6
    7. 7. Software Iterations 24 hours Sprint 2-4 weeks Sprint goal Return Return Cancel Gift wrap Coupons Gift wrap Cancel Product backlog Sprint backlog Potentially shippable product increment Coupons Change 7
    8. 8. Setting up iterations Small teams (5 members)  Iteration length 2 – 4 weeks  Every day daily scrum  Retrospective  It takes 3 sprints to get to your level of productivity  8
    9. 9. Agenda Agility  Agile overview   Software iterations  Requirements & planning  Practices  Experiences 9
    10. 10. Agile requirements Iceberg principle    Clear requirements on top (small : user stories) Unclear requirements under water (big : epic) Allows for making progress without detailing everything upfront   10 Clear requirements are delivered Unclear requirements are fleshed out before next iteration/release
    11. 11. Requirements Product Backlog 11
    12. 12. Planning Size = “bigness” of a requirement  Effort and duration are derived from size  p. 12
    13. 13. A Release Plan Cost = # sprints * Cs Cs = constant = # FTE in team Time Size 13
    14. 14. Agile Planning key points    Small planning/sizing efforts are rewarded with big gains; more effort leads to diminishing returns Frequent re-planning Plan at different levels with different precisions  Planning effort  Mike Cohn « Agile Estimating and Planning pp. 49-51 14 Release plan on requirements estimating in size Sprint plan on tasks and hours
    15. 15. Agenda Agility  Agile overview   Software iterations  Requirements & planning  Practices Experiences  Trends  15
    16. 16. Agile Practices  Automation of different types of tests (unit, functional, acceptance testing)  Test Driven / First Development  Keeps level of unfinished work low  Favor black box over white box  Continuous integration and build  Sine  qua non for ability to deliver frequently Pair Programming  Contested 16
    17. 17. Agile Practices  Architecture & Design  Evolutionary good enough solutions  Refactoring 17
    18. 18. Agenda Agility  Agile overview   Software iterations  Requirements & planning  Practices  Experiences 18
    19. 19. Experiences: software teams By the book Not invented here team XXXXXXL 19
    20. 20. The not invented here team Not invented here team 20
    21. 21. Team performance outperform Not invented here team meets expectations underperform 21
    22. 22. Productivity 22
    23. 23. Productivity 23
    24. 24. Successful practices Practices Used Benefits Delivering working software every sprint Visible product progress from end-user point of view Daily Scrum Quickly raising issues blocking progress Team members help on tasks that are blocking progress Team collaboration Emphasis on informal regular communication over written documentation Improved functional knowledge among the whole team improving quality Release planning Estimate in “points” instead of tasks/man-days 24 creates a committed plan between product owner and team
    25. 25. The XXXXXXL team XXXXXXL 25
    26. 26. Team performance outperform Not invented here team meets expectations XXXXXXL underperform 26
    27. 27. Successful practices Practices Used Benefits Align heartbeat between teams Respect time to market commitments Scrum of Scrums (daily scrum for multiple teams) Ability to stick to tight deadline Setup of integrated development practices (configuration management, automatic code review,…) Improved intra team collaboration 27
    28. 28. The by the book team By the book 28
    29. 29. Team performance outperform Not invented here team meets expectations XXXXXXL underperform By the book 29
    30. 30. Pitfalls Pitfall Scrum is complete Consequence Product Management: no tangible vision and roadmap leaving the team to go in all directions. Software architecture: no shared technical vision, roadmap and implementation. Lesson learned : Agile processes should be complemented with other disciplines Scrum team is self learning by the process itself Too much reliance on the learning aspects of an agile team (retrospective, pair programming,…) had as consequence that underperformance was ignored by management and team. Lesson learned : after 3 sprints you get a good idea about the performance of a team. Measure progress! 30
    31. 31. Team performance outperform Not invented here team meets expectations XXXXXXL underperform By the book 31
    32. 32. Experiences wrap-up What is working Time to market Software Team organization Dealing with changing requirements 32
    33. 33. Promise of Agile Development Needed result Agile Planned result Start Plan Driven 33
    34. 34. Questions? Johan Platteau johan.platteau@agileteam.be 0495/29 80 81 34

    ×