34
Agile software processes and practices: setup, experiences and success factors Johan Platteau

Agile successful practices

  • View
    1.232

  • Download
    2

Embed Size (px)

DESCRIPTION

Presentation given by AgileTeam for Leuven Inc on successful agile practices

Citation preview

Test 1 2 3

Agile software processes and practices:setup, experiences and success factors

Johan Platteau

*AgendaAgilityAgile overviewSoftware iterationsRequirements & planningPracticesExperiences

*AgileTeam Value Proposition Organizational Drivers: * Growth * Distribution of software production

Software Industry Market Drivers* Positioning of software products to new target groups* Customizations of productsICT intensiveenterprisesBusiness drivers* Decrease time-to-market* Build the right software * Software that follows business changes Organizational Drivers:* Measurement of real progress of development investments* Improved quality of software* Technological & business innovation* Integration of other products as a result of a merger or acquisition* Reliable & predictable delivery of working softwareAgileTeam enables the software evolution while maintaining the sustainable software release paceAgileTeam enables ICT to incrementally deliver qualitative working software based on the right business requirements

*Agility definedIs the early and continuous delivery of working valuable software productsDelivery at a sustainable pace Has value for the customer

*Agility illustrated

*AgendaAgilityAgile overviewSoftware iterationsRequirements & planningPracticesExperiences

*Software IterationsProductbacklog

Setting up iterationsSmall teams (5 members)Iteration length 2 4 weeksEvery day daily scrumRetrospectiveIt takes 3 sprints to get to your level of productivity*

*AgendaAgilityAgile overviewSoftware iterationsRequirements & planningPracticesExperiences

Agile requirementsIceberg principleClear requirements on top (small : user stories)Unclear requirements under water (big : epic)Allows for making progress without detailing everything upfrontClear requirements are deliveredUnclear requirements are fleshed out before next iteration/release*

*RequirementsProduct Backlog

Planning

p. *Size = bigness of a requirementEffort and duration are derived from size

*A Release Plan

Agile Planning key pointsMike Cohn Agile Estimating and Planning pp. 49-51Small planning/sizing efforts are rewarded with big gains; more effort leads to diminishing returnsFrequent re-planningPlan at different levels with different precisionsRelease plan on requirements estimating in sizeSprint plan on tasks and hours*

*AgendaAgilityAgile overviewSoftware iterationsRequirements & planningPracticesExperiencesTrends

Agile PracticesAutomation of different types of tests (unit, functional, acceptance testing)Test Driven / First DevelopmentKeeps level of unfinished work lowFavor black box over white boxContinuous integration and buildSine qua non for ability to deliver frequentlyPair ProgrammingContested

*

Agile PracticesArchitecture & DesignEvolutionary good enough solutionsRefactoring

*

T

T+1

T+2

*AgendaAgilityAgile overviewSoftware iterationsRequirements & planningPracticesExperiences

Experiences: software teams*

The not invented here team

*

Team performance*outperformmeets expectationsunderperform

Productivity*

Productivity*

Successful practices*

Practices UsedBenefitsDelivering working software every sprintVisible product progress from end-user point of view

Daily ScrumQuickly raising issues blocking progress

Team members help on tasks that are blocking progress

Team collaborationEmphasis on informal regular communication over written documentationImproved functional knowledge among the whole team improving qualityRelease planningEstimate in points instead of tasks/man-days creates a committed plan between product owner and team

The XXXXXXL team

*

Team performance*outperformmeets expectationsunderperform

Successful practices*

Practices UsedBenefitsAlign heartbeat between teamsRespect time to market commitmentsScrum of Scrums (daily scrum for multiple teams)Ability to stick to tight deadlineSetup of integrated development practices (configuration management, automatic code review,)Improved intra team collaboration

The by the book team

*

Team performance*outperformmeets expectationsunderperform

Pitfalls*

PitfallConsequenceScrum is completeProduct 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!

Team performance*outperformmeets expectationsunderperform

Experiences wrap-upWhat is working*

Time to marketSoftware Team organizationDealing with changing requirements

*Promise of Agile Development

Questions?Johan [email protected]/29 80 81*

*******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 requirementsif 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 minutesBelieve the velocity and alter plans Wii or deny and go Vasa storyHandoutsAgile Project Management 1.0Prosource - all rights reserved*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 explodesComitment = 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 okQuality no real improvementsScope*3th attempt*Voorbeelden : 2 architecture : flexible aanpasbaar / overengineering. De andere simpele refactoringTeams should measure and know their velocity. **ExampleBusiness strategiesCost reduction e.g. Eliminate costly technical expert intervention by making software usable for domain specialistInnovation : e.g. WiiIncluding customers in software development/improving business and market input