Agile successful practices
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Agile successful practices

  • 1,257 views
Uploaded on

Presentation given by AgileTeam for Leuven Inc on successful agile practices

Presentation given by AgileTeam for Leuven Inc on successful agile practices

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,257
On Slideshare
1,248
From Embeds
9
Number of Embeds
1

Actions

Shares
Downloads
20
Comments
0
Likes
1

Embeds 9

http://www.linkedin.com 9

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

Transcript

  • 1. Agile software processes and practices: setup, experiences and success factors Johan Platteau
  • 2. Agenda Agility  Agile overview   Software iterations  Requirements & planning  Practices  Experiences 2
  • 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. 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. Agility illustrated Needed result Agile Planned result Start Plan Driven 5
  • 6. Agenda Agility  Agile overview   Software iterations  Requirements & planning  Practices  Experiences 6
  • 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. 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. Agenda Agility  Agile overview   Software iterations  Requirements & planning  Practices  Experiences 9
  • 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. Requirements Product Backlog 11
  • 12. Planning Size = “bigness” of a requirement  Effort and duration are derived from size  p. 12
  • 13. A Release Plan Cost = # sprints * Cs Cs = constant = # FTE in team Time Size 13
  • 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. Agenda Agility  Agile overview   Software iterations  Requirements & planning  Practices Experiences  Trends  15
  • 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. Agile Practices  Architecture & Design  Evolutionary good enough solutions  Refactoring 17
  • 18. Agenda Agility  Agile overview   Software iterations  Requirements & planning  Practices  Experiences 18
  • 19. Experiences: software teams By the book Not invented here team XXXXXXL 19
  • 20. The not invented here team Not invented here team 20
  • 21. Team performance outperform Not invented here team meets expectations underperform 21
  • 22. Productivity 22
  • 23. Productivity 23
  • 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. The XXXXXXL team XXXXXXL 25
  • 26. Team performance outperform Not invented here team meets expectations XXXXXXL underperform 26
  • 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. The by the book team By the book 28
  • 29. Team performance outperform Not invented here team meets expectations XXXXXXL underperform By the book 29
  • 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. Team performance outperform Not invented here team meets expectations XXXXXXL underperform By the book 31
  • 32. Experiences wrap-up What is working Time to market Software Team organization Dealing with changing requirements 32
  • 33. Promise of Agile Development Needed result Agile Planned result Start Plan Driven 33
  • 34. Questions? Johan Platteau johan.platteau@agileteam.be 0495/29 80 81 34