Rational Unified Process Made Easy - A Practitioner’s Guide to RUP

Rational Unified Process Made Easy- A Practitioner’s Guide to RUPby Per Kroll and Philippe KruchtenPer Kroll, Director of RUPAgendaPart I: Introducing the Rational Unified ProcessIntroducing RUPThe Spirit of RUPPart II: The Lifecycle of a Rational Unified Process ProjectInceptionElaborationConstructionTransitionCommon Mistakes and How to Avoid ThemPart III: Adopting the Rational Unified ProcessPlanning an Iterative ProjectThe Soft Side of Managing Iterative DevelopmentWhat is RUPA software development approach that is iterative, architecture-centric and use-case drivenA well-defined and structured software engineering processA process product providing a customizable process frameworkInceptionIterative Development PhasesTimeElaborationConstructionTransitionMajor Milestones Inception: Understand what to buildVision, high-level requirements, business caseNot detailed requirements Elaboration: Understand how to build it Baseline architecture, most requirements detailedNot detailed design Construction: Build the productWorking product, system test complete Transition: Validate solutionStakeholder acceptanceExecutable ReleasesIterations and PhasesAn iteration is a distinct sequence of activitieswith an established plan and evaluation criteria,resulting in an executable release.PreliminaryIterationArchitect.IterationArchitect.IterationDevel. IterationDevel. IterationDevel. IterationTransitionIterationTransitionIterationElaborationConstructionTransitionInceptionIterative Lifecycle GraphIn an iteration, you may walk through all disciplinesCONTENTSTRUCTURET I M EInception: Know What to BuildPrepare vision document and initial business caseInclude risk assessment and resource estimateDevelop high-level project requirementsInitial use-case and domain models (10-20% complete)Manage project scopeReduce risk by identifying all key requirementsAcknowledge that requirements will change Manage change, use iterative processInceptionElaborationConstructionTransitionInceptionElaborationConstructionTransitionElaboration: Know How to Build ItDetail requirements as necessary (~80% complete)Less essential requirements may not be fleshed outProduce an executable and stable architectureDefine, implement and test interfaces of major componentsIdentify dependencies on external components and systems. Integrate shells/proxies of them.Some key components will be partially implementedRoughly 10% of code is implemented.Drive architecture with key use cases20% of use cases drive 80% of the architectureDesign, implement and test key scenarios for use casesInceptionElaborationConstructionTransitionElaboration: Know How to Build ItVerify architectural qualitiesReliability: Stress testScalability and Performance: Load testContinuously assess business case, risk profile and development planInceptionElaborationConstructionTransitionConstruction: Build The ProductComplete requirements and design modelDesign, implement and test each componentPrototype system and involve end usersIncrementally evolve executable architecture tocomplete systemBuild daily or weekly with automated build processTest each buildAutomate regression testingLoad and stress test to ensure architectural integrityDeliver fully functional software (beta release)Includes training material, user and deployment documentationProduce release descriptionsInceptionElaborationConstructionTransitionTransition: Deploy to End UsersProduce incremental ‘bug-fix’ releasesUpdate user manuals and deployment documentationUpdate release descriptionsExecute cut-overConduct “post-mortem” project analysisKey Best Practices and PrinciplesDevelop only what is necessaryLean process, agilityMinimize paperworkBe flexibleRequirements, plan, usage of people, etcLearn from earlier mistakesFeedback loopsProcess improvementRevisit risks regularlyEstablish objective, measurable criteria for progressAutomateSupport process with software development toolsBest PracticesProcess Made Practical Develop IterativelyManage RequirementsUse Component ArchitecturesModel Visually (UML)Continuously Verify QualityManage ChangeAgendaPart I: Introducing the Rational Unified ProcessIntroducing RUPThe Spirit of RUPPart II: The Lifecycle of a Rational Unified Process ProjectInceptionElaborationConstructionTransitionCommon Mistakes and How to Avoid ThemPart III: Adopting the Rational Unified ProcessPlanning an Iterative ProjectThe Soft Side of Managing Iterative DevelopmentThe Spirit of The Rational Unified ProcessAttack major risks early and continuously or they attack youEnsure that you deliver value to your customerHave a maniacal focus on working softwareAccommodate change early in the projectBaseline an executable architecture early onBuild your system with componentsWork closely together as one teamMake quality a way of life, not an afterthoughtTraditional Waterfall SDLCOne phase begins when another completes, little backtracking and loopingWaterfall Development LifecycleWinston Royce, 1971IntegrationSystem TestCodeDesignRequirements Late discovery of issuesMeasures progress by assessing work products that are poor predictors of time to completionLate integration and testingPrecludes early deploymentFrequently results in major unplanned iterationsWhat Happens in PracticeSequential activities:Requirements Design Code Integration TestLate DesignBreakage100%Project ScheduleDevelopment Progress(% coded)OriginalTarget DateIntegrationBeginsWaterfall: Hard to Scale upA waterfall approach can not properly handle the growing complexity associated withIncreased durationIncreased application sizeLarger and/or distributed teamIncreased technical complexityNovelty of technologyThe root cause of the problem with the waterfall lifecycle is that it does not allow to identify and mitigate risks early enoughIterative DevelopmentEarliest iterations address greatest risks Each iteration produces an executable releaseEach iteration includes integration and testIteration 1 Iteration 2 Iteration 3 Better Progress Profile100%Project ScheduleWaterfallProject ProfileModernProject ProfileDevelopment Progress(% Coded)Walker Royce, 1995Sequential phases, but iterative activities Prototypes Architecture Functional Product Releases ReleaseRisk Mitigation: Hitting Hard Problems EarlierWhen the initial risks are mitigated, new ones emergeDo not do just the easy stuff, to look goodKeep re-planning based on all new informationIn iterative development, you cannot lie to yourself very longRisk ReductionTimeRiskWaterfall RiskIterative RiskRisk Profiles2. Ensure That You Deliver Value to Your CustomerFocus on key requirementsCapture, documentOrganize, prioritizeRequirements will changeEvaluate impact of change and decide what changes to implementPropagate changes to all team membersMake requirements accessibleRequirements management leverages your ability to deliver products that meet user needsUse-Case Driven DevelopmentA use case describes complete and meaningful services that your system offers to users and other systemsUse cases drive the work through each iterationPlanning of iterationsCreation and validation of the architectureDefinition of test cases and procedures Design of user interfaces and creation of user documentationUse-Case ModelAnalysis & Design ModelImplementation ModelTest ModelRequirementsrealized byimplemented byverified byAnalysis & DesignImplementationTest3. Have a Maniacal Focus on Working SoftwareMeasure progress primarily by reviewing executable code, and test resultsPlans, requirements, designs and other by-products often provide a false perception of progress and statusFocus on the final, delivered product, and only the artifacts that matter to get at this goal consistentlyStreamline the processDo not use all of the RUP! Only use what makes sense to your project4. Accommodate Change Early in the Project Today’s systems are too complex to get the requirements, architecture, design, implementation and scope right the first timeBusiness SolutionArchitectureDesign & ImplementationScope (Reduction)Provides freedom to change:PreliminaryIterationArchitect.IterationArchitect.IterationDevel. IterationDevel. IterationDevel. IterationTransitionIterationTransitionIterationElaborationConstructionTransitionInception5. Baseline an Executable Architecture EarlyArchitecture provides a skeleton structure of your systemSubsystems, key components, interfaces, architectural mechanisms (solutions for common problems, such as persistency, inter-process communication, )Implementing and testing the architecture mitigates most technical risksProduce Executable ArchitecturePreliminaryIterationArchitect.IterationArchitect.IterationDevel. IterationDevel. IterationDevel. IterationTransitionIterationTransitionIterationElaborationConstructionTransitionInceptionThe Spirit of The Rational Unified ProcessAttack major risks early and continuously or they attack youEnsure that you deliver value to your customerHave a maniacal focus on working softwareAccommodate change early in the projectBaseline an executable architecture early onBuild your system with componentsWork closely together as one teamMake quality a way of life, not an afterthoughtTraditional Functional DecompositionRequirements drivenMany dependencies creates inflexible systemsR1R2.RNRaRb.RcFaFbFcRiRj.RkFiFjFkRxRy.RzFxFyFzSystemRequirementsSoftwareRequirementsSoftwareFunctionsCommonDataRiRj.RkRaRb.RcRxRy.RzSystemRequirementsSoftwareRequirementsLayered, Component-basedArchitectureCommonMechanismsDomainComponentsFunctionsR1R2.RN6. Build Your System with ComponentsComponent architecture provides flexibility7. Work Closely Together As One TeamEmpowered and self-managedClear visionAccountable for team resultsClear expectationsAll for one, one for all - avoid “My design was good, your code didn’t work”Optimized communicationFace-to-face rather than e-mailEffective process (right-sized for your project)Organize around architecture, not around functionsGet the right tool supportEasy access to current requirementPrivate workspacesEasy access to defects.8. Make Quality a Way of Life, Not an AfterthoughtCostTransitionConstructionElaborationInceptionSoftware problems are100 to 1000 times more costlyto find and repair after deployment Cost to Repair SoftwareCost of Lost OpportunitiesCost of Lost CustomersTesting Dimensions of QualityReliabilityTest that the application behaves consistently and predictablyPerformanceTest online response under average and peak loadingFunctionalityTest the accurate workings of each usage scenarioUsabilityTest application from the perspective of convenience to end-userSupportabilityTest the ability to maintain and support application under production useTest Each IterationUML Model and Implementation TestsIteration 1Test Suite 1Iteration 2Test Suite 2Iteration 4Test Suite 4Iteration 3Test Suite 3It is often cheaper to find a problem through early implement-ation and testing, than through detailed design review.To Learn MoreBooksPer Kroll and Philippe Kruchten, The Rational Unified Process Made Easy—A Practitioner’s Guide, Addison-Wesley (2003)Chapter 2 and 4Articles in Rational Edge, www.therationaledge.comPer Kroll, Spirit of RUP, December 2001Philippe Kruchten, A Process for a Team of One, January 2001AgendaPart I: Introducing the Rational Unified ProcessIntroducing RUPThe Spirit of RUPPart II: The Lifecycle of a Rational Unified Process ProjectInceptionElaborationConstructionTransitionCommon Mistakes and How to Avoid ThemPart III: Adopting the Rational Unified ProcessPlanning an Iterative ProjectThe Soft Side of Managing Iterative DevelopmentObjectives with InceptionUnderstand what to buildVision, including who wants the system and it’s valueThe scope of the systemPreliminary use-case modelIdentify key requirementsCritical use cases and non-functional requirementsDetermine at least one potential solutionIdentify candidate architectureUnderstand costs, schedule and riskBusiness case, Software Development Plan, and Risk ListUnderstand what process to follow and tools to useRUP configuration, development case, and customized toolsObjective 1: Understand What to BuildAgree on a high-level visionProvide a “mile-wide, inch-deep” descriptionDetail key actors and use casesDetail key non-functional requirementsMile-Wide, Inch-DeepIdentify as many actors as you canAssociate each actor with use casesFind additional actors for each use caseBriefly describe each actor (1-2 sentences) and use case (1-2 paragraphs)Create a GlossaryDo a lifecycle analysis of key glossary itemsIdentify the most essential and critical use cases ( More accurate scheduleFine-tune and deploy development environmentHarvest experiences from InceptionRollout development environmentSample Elaboration Profile: Multiple IterationsIteration 1Design, implement and test a small number of critical scenarios to outline architecture and required patternsIdentify, implement and test a small set of architectural patternsDo a preliminary logical database designDetail flow of events of ~half of target UCs, with most important UCs firstDo sufficient testing to ensure key risks have been mitigatedIteration 2Fix whatever did not work in previous iterationDesign, implement and test remaining architecturally significant scenarios (for the Track multiple versions of filesParallel work on multiple streams => merge success solutions into main streamDifficult to understand when and where defects are introduction => Enable back tracking to functioning version and to understand when defect was introducedFor larger teams:Isolate the work of one team member from the rest of team when desiredControl who is allowed to do what changesHigh end configuration management systems can automate all of the aboveEnforce the ArchitectureLeverage patterns developed during ElaborationTrain your team and produce guidelines on what is available and how to use itDo you need to produce a reuse / pattern library for easy access?Arrange with reviews to ensure architectural integrityManage changes to interfacesConfiguration management supportHow will you communicate changes to concerned parties?Enforcement of the architecture needs to be formalized for large or distributed teamsEnsure Continual ProgressLeverage iterations to create short term goals and a sense of urgencyAvoid hockey stickCreate cross-functional teams with a joint missionQuick daily meeting (SCRUM)Set clear achievable goals for developersBreak down iteration objective of an iteration to a set of 1-week goals, if possibleContinually demonstrate and test codeMeasure progress through demonstration and testing, not through “status reports”Force continuous integrationDaily builds if possibleObjective 2: Iteratively Develop a Complete ProductDescribe the remaining use cases and other requirementsFill in the designDesign the databaseImplement and unit-test codeDo integration and system testingEarly deployment and feedback loopsPrepare for beta deploymentPrepare for final deploymentConsiderations for Beta DeploymentHow many beta customers do you need? What type of feedback do you need?How long beta program do you need to get required feedback?What do you need to do to ensure beta program is valuable to participants?What’s in it for them?What do you need to do to ensure required feedback?Training?Face-to-face time with beta users?Balance between independent use (to ensure realistic usage) and handholding (to ensure correct usage, or usage at all)Is data conversion required?Do you need to run current systems in parallel?A well-thought plan needs to be in place, including identified participants, at the day of the beta releaseConsiderations for Final DeploymentTraining materialUser documentationPrepare deployment site(s)HardwareSoftwareTrainingFacilities, Database conversationsBudget and resource coordinationAcquisitions and hiringTransition costs, such as training or running parallel systemsEven though final deployment happens at end of Transition, you often need to prepare in ConstructionConclusions: ConstructionYou develop software cost-effectively by taking advantage of the architectural baseline from ElaborationYou are able to scale up the project to include more team membersYou build and assess several internal releasesYou move from an executable system to the first operational version of your systemAgendaPart I: Introducing the Rational Unified ProcessIntroducing RUPThe Spirit of RUPPart II: The Lifecycle of a Rational Unified Process ProjectInceptionElaborationConstructionTransitionCommon Mistakes and How to Avoid ThemPart III: Adopting the Rational Unified ProcessPlanning an Iterative ProjectThe Soft Side of Managing Iterative DevelopmentObjectives with TransitionBeta test to validate that user expectations are met.bug fixing and making enhancements for performance and usability.Train users and maintainers to achieve user self-reliability.Are adopting organization(s) qualified to use the system Prepare deployment site and convert operational databases.Purchase new hardware, add space for new hardware, and data migration.Prepare for launch-packaging, production, and marketing rollout; release to distribution and sales forces; field personnel training.Especially relevant for commercial products.Achieve stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision.Improve future project performance through lessons learned.Document lessons learned and improve process and tool environment.Objective 1: Beta Test to Validate That User Expectations Are MetCapturing, Analyzing, and Implementing Change RequestsTransition TestingContinued test design and implementation to support ongoing development.Regression testing, which will require variable effort and resources, depending on the chosen approach; for example, retest everything or retest to an operational profile.Acceptance testing, which may not require the development of new tests.Patch Releases and Additional Beta ReleasesMetrics for Understanding When Transition Will Be CompleteDefect metricsTest metricsExample: Defect MetricsTrend analysis often provides reasonably accurate assessment of when you can complete the projectObjective 4: Prepare for Launch: Packaging,Production, and Marketing RolloutPackaging, Bill of Materials, and ProductionMarketing RolloutCore Message Platform (CMP). A one- to two-page description of the product, its positioning, and key features and benefits. Used as a baseline for all internal and external communication related to the product.Customer-consumable collateral. Data sheets, whitepapers, technical papers, Web site, prerecorded demos, demo scripts, ...Sales support material. Sales presentations, technical presentations, field training material, fact sheets, positioning papers, competitive write-ups, references, success stories, and so on.Launch material. Press releases, press kits, analyst briefings, and internal newsletters.Conclusions: TransitionYou performed one or more beta tests of the new system with a small set of actual users and fine-tuned it as necessary.You trained users and maintainers to make them self-reliant.You prepared the site for deployment, converted operational databases, and took other measures required to operate the new system successfully.You launched the system with attention to packaging and production; rollout to marketing, distribution, and sales forces; and field personnel training. This is specifically a focus for commercial products.You achieved stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision.You analyzed and used lessons learned to improve future project performance.AgendaPart I: Introducing the Rational Unified ProcessIntroducing RUPThe Spirit of RUPPart II: The Lifecycle of a Rational Unified Process ProjectInceptionElaborationConstructionTransitionCommon Mistakes and How to Avoid ThemPart III: Adopting the Rational Unified ProcessPlanning an Iterative ProjectThe Soft Side of Managing Iterative DevelopmentCommon Pitfalls in InceptionToo much formality / too many artifacts Only produce the artifacts that add value, minimize formality if possibleWhen in doubt of value, don’t do itAnalysis ParalysisYou can improve upon things later on – move onFocus on objectives with InceptionDo NOT describe all requirements in detailToo long initial iterationCut scope rapidlyYou fail with first iteration, project likely to failCommon Pitfalls in ElaborationFunctional, Specialized OrganizationTeams of generalists and multitasking expertsNo place for “I only do ” mentalitySave the tricky part for laterAttack risks early, or they attack youHard on you now, but makes life easier laterNo implementation and validation of architectureYou cannot get the architecture right or address major risks without implementing and testing the architectureNo willingness to change thingsChange enables improvementCommon Pitfalls in ConstructionBasing work on unstable architectureMajor rework and integration issuesHigh price to pay for insufficient work in ElaborationReinventing solutions to common problemsWere architectural mechanisms (patterns) developed in Elaboration and communicated to everybody?Continuous integration not happeningDaily or weekly build minimizes reworkTesting not initiated until end of constructionYou are unlikely to meet deadlinesBeta may be of too low quality to offer valueCommon Pitfalls in TransitionNot enough beta usersDid you have beta customers lined up and prepared at end of Construction?Not all functionality beta testedDid you include the functionality in the beta release? Was it usable? (Ease of use, performance, documented, )Customer not happy with delivered functionalityWas acceptance criteria approved by customer?Did you involve customer throughout the project?AgendaPart I: Introducing the Rational Unified ProcessIntroducing RUPThe Spirit of RUPChoosing the right level of ceremonyPart II: The Lifecycle of a Rational Unified Process ProjectInceptionElaborationConstructionTransitionCommon Mistakes and How to Avoid ThemPart III: Adopting the Rational Unified ProcessPlanning an Iterative ProjectThe Soft Side of Managing Iterative DevelopmentRUP Projects are ITERATIVEWork is undertaken within an iteration.The iteration plan defines the artifacts to be delivered, roles and activities.An iteration is clearly measurable.An iteration is TIME BOXEDIterations are RISK DRIVENProject progress is made against MILESTONESEach phase is defined by a milestone.Progress is made by passing the milestones.The emphasis of Phases - THEY ARE NOT TIMEBOXED.Milestones measure successInceptionElaborationConstructionTransitionMajor MilestonesPlan With Evolving Levels of DetailCurrent IterationNext IterationPhases and major milestones What and whenIterations for each phase Number of iterations Objectives and DurationOne For Entire ProjectFine-grained Plans: Iteration PlansCoarse-grained Plan: Project PlanIterative does not mean less work and shorter scheduleIt is about greater predictabilityThe Project Plan Defines.Phase plan with major milestonesIterations and their objectivesReleases, what and for whomHigh-level schedule (with the information above)Resources and staffingThe Iteration Plan Defines.The deliverables for that iteration.The to do list for the team membersPhase definitionPhases map to types of risks for an iteration.Inception – Risks associated with ScopeElaboration – Risks associated with ArchitectureConstruction – Risks associated with ProductionTransition – Risks associated with the Roll outUse this knowledge to identify the right milestonesPhases~5%10%20%30%65%50%10%10%EffortScheduleUse ‘average’ project for basisSource: Walker Royce 1995PhasesReview the project domain and determine how your risk profile relates to most projects.Adjust relative duration of the phase by mapping risks to each phase. For exampleFinding scope is a real problem – Increase relative length of inception by 5%Architecture is unknown – Increase relative length of elaboration by 5%Using pre-defined architecture – decrease relative length of elaboration.Examples of projects..Incremental (1)Evolutionary (2)Incremental delivery (3)“Grand design” (4)Iteration LengthAn iteration should typically be 2-8 weeks longDrivers for longer iterationsComplex stakeholder relations, regulatory constraintsImmature tools (Change management, IDEs, test environments, )Many project members, inexperienced project membersComplex technology, large code base, brittle architecturesLong project durationSample projects5 people, 1-2 week20 people, 3-4 weeks80 people, 8 weeksStaffing levelsStaffing profile is dependent on phase.The iteration plan describes.the work to be done the artifacts to be deliveredwhose doing whathow you measure the iteration the iteration lengththe risks to be mitigatedThe iterationPlanConsider Your Current Phase of DevelopmentDetermine the objective of this iteration by reviewing the milestones for the phase.InceptionElaborationtimeLifecycle Objective Milestone Project Scope Candidate Architectures Risks Supporting EnvironmentDecide on the DeliverablesWe need to deliver :-* Risk* Business Case* Architectural synthesisIteration AssessmentAt the end of each iterationAssess how you did compared to iteration plan and success criteria as specified in project planSuccess criteria should primarily be defined by measurable deliverablesAnd those should have been defined before the iteration started!Focus on demonstrable progress (executable code, actual deliverables, ), not what activities have been completedUpdate project plan based on iteration assessmentProvides a very objective assessment whether you are on track or notSummary: Planning Iterative DevelopmentIterative development requires more planningPlans evolve as understanding improvesWell-defined and objective milestones provides improved picture of true project statusAllows for killing bad projects early rather than lateTwo plans in a RUP projectCoarse-grain project planIteration plan for each iterationIteration plan drives developmentDescribes the things that will be deliveredDetails the activities to be undertakenHas a fixed time boxDefines assessment criteria the for the end of the iterationProject plan defines milestones and assessment criteria“Big picture” planTo Learn MoreBooksPer Kroll and Philippe Kruchten, The Rational Unified Process Made Easy—A Practitioner’s Guide, Addison-Wesley (2003)Chapter 13 and 14Walker Royce, Software project management—A Unified Framework, Addison-Wesley (1998)Philippe Kruchten, The Rational Unified Process—An Introduction, 2nd ed., Addison-Wesley (2000)Articles in Rational Edge, www.therationaledge.comPhilippe Kruchten, Planning Iterative Development, October 2002Kurt Bittner, Managing Iterative Development with Use Cases, March 2003Ellen Gottesdiener, Team Retrospectives for Effective RUP Assessments, April 2003AgendaPart I: Introducing the Rational Unified ProcessIntroducing RUPThe Spirit of RUPPart II: The Lifecycle of a Rational Unified Process ProjectInceptionElaborationConstructionTransitionCommon Mistakes and How to Avoid ThemPart III: Adopting the Rational Unified ProcessPlanning an Iterative ProjectThe Soft Side of Managing Iterative DevelopmentIterative DevelopmentIn iterative development, you constantly move between requirements, architecture, design, implementation, and testRequires different team dynamics and valuesPuts special requirements on people, process and toolsIterative development requires a mind shift. Team DynamicsOLD THINKINGFunctional teams of either all analysts, all developers, or OK with low-bandwidth communicationCommunicate primarily through documents (requirements, design, ...)Narrow specialists“That’s not my job”NEW THINKINGCross-functional teams consisting of analysts, developers, testers, Must have high-bandwidth communicationCommunicate through evolving models, tools and face-to-faceGeneralists and specialists with bird-eye perspective“We are all responsible for the application”AnalystOLD THINKINGRequirements need to be finalized earlyI specify requirements, developers implement themThe more detailed requirements, the betterNEW THINKINGRequirements should evolve so they address customer needsI am responsible for requirements, but seek input from users, developers, testers, technical writers, Requirements should be detailed enough to address stakeholder needs, but not more since it increases costDeveloperOLD THINKINGBuild high-quality code addressing the requirementsI take pride in developing my own unique solutionTesters test my codeTesters are responsible for the qualityNEW THINKINGBuild high-quality code addressing user needsI take pride in delivering a workable solution (reuse is good)I test my own codeI am responsible for the quality of my code, but testers verify that I did a good jobTesterOLD THINKINGTesting is an afterthoughtA quality policeTest according to well-defined and detailed test specificationNEW THINKINGTesting is an integral part of the development effortA knowledge resource that assists the team in reaching high-quality codeTest according to well-defined test criteriaManagerOLD THINKINGHide risks so people do not know how bad things areUnderstand status by asking for status reportsMore documentation is betterRequirements and test are the high value activitiesTeam members probably do a bad job – we need to check everythingDistrustNEW THINKINGExpose risks so everybody knows what to focus atUnderstand status by observing what works (e.g cross-functional team demos latest capabilities)The right amount of documentation is goodThe right balance between requirements, design, code and test provides the valueThe different perspectives of an integrated team motivates us to excelTrustCustomerOLD THINKINGThey build the productI specify what I want, later on they deliverNEW THINKINGWe build the productI specify what I want as well as I can, and then assist in getting it to what I really wantPeople GuidelinesStaff the project with people with complementary skillsStaff the project with different levels of experience and expertiseExpert, Journeyman, ApprenticeComplementary skillsMake sure everyone understands the vision (goal) of the projectProvide a learning environmentEveryone on the team should learn somethingCan be technical or otherMake learning a goal and provide the time to learnPeople GuidelinesBuild a high-trust environmentTrust can be lost but don’t force it to be earned from the beginningIf you have an issue with somebody, confront them. Do not just complain...Allow disagreementsDisagreement can be a sign of synergyHave a resolution strategy and make sure the team understands itHave open discussionsProvide time for interactions among all team membersBe creative at meetingsHave lunch togetherPeople GuidelinesRecognize achievement sincerely and oftenA sincere “thank you” works wondersAllow peer recognitionWhen did you last time send an impromptu e-mail acknowledging the performance of a peer?But watch out for the “you scratch my back, I’ll scratch yours” syndromeLeadership Principle: Participate, Not Oversee Maintain the big pictureSteer, not just trackShare the riskManage successPlanned PathActual PathPlanned CompletionActual CompletionPlannedInitial StateActual Initial StateMaintain the Big PicturePlanned PathActual PathPlanned CompletionActual CompletionPlannedInitial StateActual Initial StateUnderstandcurrent statusTrack acceptable solution spaceSteer, Not Just TrackPlanned PathActual PathPlanned CompletionActual CompletionPlannedInitial StateActual Initial StateLeaders need to use iterations to steer project Monitoring ProgressTracking project:Stability – changes in planned requirements, design, sizingProgress – actual demonstrable progress against plansContent in the iterationsQuality – test status, reports of iterationsSchedule stability – iteration contentBudget – cost, schedule variance based on iteration contentIf not on track, Ask for reasonsAdjust the resourcesFind ways to helpShare and Manage the RiskShow appreciation of the uncertainty curveDon’t ask for commitments that are impossible to makeShare in estimations and planningUse iterations to manage uncertaintyTimeUncertaintyManage SuccessIn software development, success breeds successTeam members motivated by being on successful projectsBetter motivator than fear or beratingManagers canCreate opportunities for success using iteration plansShow appreciation of the successof early iterationsHead off failure by uncovering problems earlySummary: The Soft Side of Managing Iterative DevelopmentIterative development requires a mind shiftThe way people collaborate needs to changeLarge projects organize around architecture, not functional rolesAs a manager you need to Understand the nature of iterative software developmentProvide the big pictureSteer and participate, not overseeStaff projects with different skillPraise peopleCreate a winning teamTo Learn MoreBooksMurray Cantor, Software Leadership, Addison Wesley (2001)Dale Carnegie courses / books, www.dale-carnegie.comJohn Whiteside, The Phoenix Agenda, 1993James A. Highsmith III, Adaptive Software Development, 2000Gerald Weinberg, Becoming a Technical Leader, 1986Pete McBreen, Software Craftsmanship, 2001 ArticlesIterative Development Requires a Different Mindset, Per Kroll, ?, 2003. Thank you