• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Chapter1.rr.ppt
 

Chapter1.rr.ppt

on

  • 2,022 views

 

Statistics

Views

Total Views
2,022
Views on SlideShare
2,022
Embed Views
0

Actions

Likes
2
Downloads
31
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management Recognize that we develop software in a midst of considerable uncertainty. Recognize that when projects start there are risks that are really real. Some may be small; some large. Some can totally kill a project, but are very unlikely to occur; some are small, but are likely to occur – but may / may not seriously degrade the software if not mitigated… and more!! While there is a vision for the product, there is a great deal of uncertainty in really capturing all the business rules, providing the required real value (fkunctionality and non-functionality) while using a process that may be suspect. There is great risk in acknowledging change, assessing it, and, if necessary, incorporating change into the development process while all the while incrementally providing a product with increased value, while remaining within cost parameters and on schedule. So, we consider iterative development…
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management OK. What are these activities? What do we mean by refining an effective solution? Successive refinement of a solution? Incremental in that each iteration aids in the understanding of the problem ? Grows the capability of the solution?
  • Module 1 - Iterative and Incremental Development Iterative Project Management Why must the process by incremental? Can it be iterative and not incremental?? (Yes, it may not reduce risk or progress toward our goals.. Project Must steadily reduce risk and move towards the project goals, which are measurable and can be objectively evaluated ! “ iteration involves successive refinement of the understanding of the problem and the solution’s definition and implementation Incremental in that each cycle grows the understanding of the problem and the capability offered by the solution. Successive increments reduce risk and continue to add measurable business value
  • Module 1 - Iterative and Incremental Development Iterative Project Management Important to note that the assertions inherent in the plan are repeatedly challenged and evaluated by the design and development of demonstrable versions of the system, Each of which is objectively evaluated to prove that it reduces the project risk and each of which builds upon the prior versions until the solution is complete. Projects themselves are full of assertions starting with how long tasks might take, stability of requirements, Requirements themselves are assertions of what the user expects. These change repeatedly!! They may not even be valid!! They may be incomplete, insufficient, not feasible, not testable, and not necessary!!
  • Module 1 - Iterative and Incremental Development Iterative Project Management The PMBOK definition of project is: “ A temporary endeavour undertaken to create a unique product or service.” Iterations are certainly temporary. Each iteration will result in a unique release of the product.
  • Module 1 - Iterative and Incremental Development Iterative Project Management To ensure that we are making progress, we force each iteration to produce something tangible: a “release.” This release may be: A prototype we use to demonstrate some capability. An “internal” release that we will use to elicit feedback and as a basis for further development and testing. An “external” release that we ship to customers in some form.   Each iteration, all software across all teams is integrated into a release. To produce a release, the iteration will involve applying, at least in part, the disciplines of project management, requirements, analysis and design, implementation, and test. Release is defined as “a stable, complete, and executable version of a system” Each consecutive release should be marked by: Growth of capability, as measured by the implementation of additional functionality during each iteration Greater depth, as measured by a more complete implementation of the product Greater stability, as measured by a reduction in the number of changes to the product Reduced Risk, as indicated by estimate fidelity, risk magnitude and stakeholder confidence
  • Module 1 - Iterative and Incremental Development Iterative Project Management The slide above summarises some of the, generally acknowledged, benefits of an iterative and incremental development.
  • Module 1 - Iterative and Incremental Development Iterative Project Management Development Team: forming and developing solution: analysis, design (including architecture) implementation and test. Customer Team: define problems to be solved and software to be built. Do the results satisfy customer needs? Management Team: Ensure that developers, customers, and business representatives are all on same page!
  • Module 1 - Iterative and Incremental Development Iterative Project Management Team undertakes analysis, design, and implementation (unit testing and integration) to produce periodic releases. The development team must produce software that meets / exceeds customer requirements. While a customer rep may be assigned to work directly with the team, ‘requirements’ are considered a Customer Team responsibility.
  • Module 1 - Iterative and Incremental Development Iterative Project Management Individual Developer: Here, life is simple: He/she sees incremental development shown by increasing level of completeness of the application and smaller number of requirements and changes needed. For small projects with limited scope, this ‘developer-centric’ view works well. But for large projects with considerable sharing of code, the scale of these requires different perspectives than simply a developer-based view. Team Leader Perspective: needs to integrate the changes or development work into a release that meets the team’s shared objectives. From team leader’s approach, the iteration is a time-boxed mini-project that results in a significant new release of the software.
  • Module 1 - Iterative and Incremental Development Iterative Project Management Team must put together results of individual developers for an integrated release that will result in feedback that will, in turn, result in new understanding of the requirements and additional change requests that form the basis for the next iteration and then ‘its’ next release. Often, many releases are internal – capturing additional functionality or reducing risk through mitigation, and are baselined. These may/may not be shown to customers to obtain feedback – depending on the nature of the internal release. After a certain number of internal releases, an external release may be deployed.
  • Module 1 - Iterative and Incremental Development Iterative Project Management Individual team workers and team leaders see incremental / (especially) iterative development differently. Individual team workers – a myriad, seemingly endless set of iterations . Work gets done and all is well. Team Leader: different perspective: much more a matter of integration! As the increments are base-lined, here the completeness of the project may be calculated, as more requirements are implemented. It is critical that the developers’ work be integrated into an evolving product.
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management More: objective assessment is undertaken each iteration! Customers: build confidence in the team’s ability to deliver – real suspicions in practice!!!! Development Team: better understanding of project; confidence in the acceptability of their plans Can witness the evolution of promised ‘convergence.’
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management Book continues: There’s no value in specifying requirements that will not be implemented Many of these often exceed budgets and time constraints Makes no sense to specify requirements for features in the ‘next’ deliverable – contributing no bearing (negative!) on THIS effort.
  • Module 1 - Iterative and Incremental Development Iterative Project Management Takes no time to dream up requirements “that easily outstrips any team’s ability to deliver on time and within budget.” Defining requirements takes almost no effort compared to the effort needed to implement them! The real art in defining requirements is not to identify as many as possible but rather to find the minimum set of requirements needed to satisfy the business problem. More requirements are not better, and many a solution has been ruined by having too many features.
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management Recall: The root cause of project failure is: Poor Management! Risky to believe that the managers deep the (book) bureaucrats at bay while the team does the work! While this is commonly done,it is a recipe for project failure!
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management Iteration helps with a lot of the project’s quality drivers: Requirements misunderstanding – addressed early Development risk – understood and resolved early COTS Components – integrated and tested early Change management – Focussed on the early iterations Design errors – resolved early Resource adequacy – confronted early (in the first iteration) Schedules – estimate quality and schedule credibility tested early Team performance – tested early Solution performance – tested early via executable prototypes and early (internal) releases Process effectiveness – tested early Other elements will be looked at in the next module ‘Controlling an Iterative Project’
  • Module 1 - Iterative and Incremental Development Iterative Project Management
  • Module 1 - Iterative and Incremental Development Iterative Project Management No silos. No finger pointing!!!

Chapter1.rr.ppt Chapter1.rr.ppt Presentation Transcript

  • Iterative Project Management Module 1 - Iterative and Incremental Development
  • Objectives
    • Understand what iterative and incremental development is
    • Understand the different perspectives and bounds of iteration
    • Understand what makes an iterative project successful
    • Introduce the team dynamics of an iterative project
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Discussion
    • What does iterative and incremental development mean to you?
    • Discuss
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Definitions
    • Iterate vt
      • to utter or do repeatedly
        • iteration n . – iterative adj
    • Increment n
      • 1. amount of increase
      • 2. a becoming greater or larger; increase
        • incremental adj
    • How does all this apply to a software development project??
    • How does a project team work iteratively while incrementally developing a product?
    Iterative Project Management / 01 - Iterative and Incremental Development Source: Collins Modern English Dictionary
  • Definition: Iterative and Incremental Development
    • Iterative and incremental development
      • A style of development that involves the iterative application of a set of activities to incrementally produce and refine an effective solution
      • It is iterative in that it involves the successive refinement of the solution definition and implementation by the repetitive application of the core development activities
      • It is incremental in that each pass through the iterative cycle grows the understanding of the problem and the capability offered by the solution
    Iterative Project Management / 01 - Iterative and Incremental Development
  • More on Iteration and Increment
    • What does all this mean?
      • Can we have iterative development without it being incremental??
      • If so, how so?
      • Discuss .
      • How does risk play into this?
      • What’s the ‘increment?’
      • Do we need both? If so, why? If not, why not?
      • Let’s look at Risk a bit and realize that this is a key component in an iteration and in iteration planning…
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Risk – All Kinds of Risks
    • Environmental
      • War zone; satellite; earthquake region; weather regions
    • Technical
      • Team expertise; available development environment; team size;
    • Personnel
      • Death; pregnancy; illness; vacations; accidents
    • Financial
      • Cost of project; due dates feasible?
    • Competition
      • Other competitors offering same services? How does our differ?
    • Process models / management expertise……
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Develop Projects with Considerable Uncertainty and Risk
    • Recognize we develop software in a midst of considerable uncertainty.
    • Recognize that when projects start there are risks that are really real. Some may be small; some large.
    • Some can totally kill a project, but are very unlikely to occur; some are small, but are likely to occur – but may / may not seriously degrade the software if not mitigated… and more!!
    • Risk in capturing all the business rules: While there is a vision for the product , there is a great deal of uncertainty in really capturing all the business rules , that provided the real value to the customer.
    • Risk in acknowledging change, assessing it, and, if necessary, incorporating change into the development process while all the while incrementally providing a product with increased value, while remaining within cost parameters and on schedule.
    • So, we consider iterative development…
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Definition: Iteration
    • Iteration : A
    • self-contained mini-project , with a
    • well-defined result , that results in a
    • stable, integrated and tested release
      • An iteration consists of
        • a distinct set of activities
        • conducted according to a dedicated (iteration ) plan
        • With a set of objective , measurable evaluation criteria
        • That provides business value
      • The release may be either an internal release or an external release
      • Here – on page 6. a mini project?
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Iteration: A Self-Contained Mini-Project …
    • Each iteration has:
      • Clear objectives and activities
        • Agreed upon by all; unified efforts of all
      • Measurable evaluation criteria
        • Must be ‘measurable;’ and evaluated objectively
      • A dedicated team
        • All dedicated to achieving the objectives of the iteration. Focused !
      • A schedule
        • Mgmt must agree to the schedule and note how it impacts overall development plan.
        • Iteration schedule may be simple: start / end dates, or complicated – detailed task descriptions
        • Produce a unique version of the product
      • Is objectively assessed against iteration’s objectives .
        • Continuously assessed during iteration; summarized at end.
        • Used to control the project. Who assesses ?
    • Must have a Well Defined Result!! More 
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Iterations
    • In more detail:
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Iteration has a Distinct Set of Activities (not the Overall Project Plan)
    • Thus, it must have specific plan that embodies the unique set of activities to produce the well-defined result .
    • Plan may vary in detail:
      • High risk  more detailed planning (when might this occur?)
      • Team size  may need to carefully coordinate
      • Experience Level  no substitute for this; New people? Bring them along
      • Can leave details to development team
      • Dependencies on team member contribution may necessitate more detailed planning.
    • Iteration Plan must nevertheless:
      • Establish the objectives, and
      • Evaluate resources, and
      • Develop the schedule
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Iteration has a Distinct Set of Activities – pg. 2
    • Number of Plans to work with?
      • One for current iteration;
      • One for evolving next iteration plan
    • Recognize that iteration plans must fit within context of overall project plan
    • Overall project plan is also developed iteratively and adapted to the lessons learned from the execution of the development iterations.
    • Project Plan – usually high level; Details relegated to iteration plans.
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Iteration Results in an Executable Release
    • Very important to understand this !
    • We spoke of a well-defined result, well:
    • Release can be both internal and external but must be something measurable , tangible ,
    • Clearly advances the project:
    • A real increment reduces risk and builds capability !
    • Something of value is produced.
    • Examples (a few)
      • Prototype – that demonstrates a specific capability
      • ‘ Internal Release’ where feedback from customers is needed
      • ‘ External Release’ where definite business value is given to customers
    • These are considered well-defined results! There are others!
    Iterative Project Management / 01 - Iterative and Incremental Development
  • … the sequence of releases …
    • A release is a ‘ stable and executable version of a system,” or “…stable, integrated and tested, partially complete system,” and more…
    • A sequence of releases does the following:
      • each with definite value,
      • measurable outputs, etc. that
      • provides management regular, technical visibility as to where the state of the project lies and
      • Assures management that the project is moving incrementally toward completion.
    • Particularly critical to management!
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Releases - more
    • Releases – common misconception – need not be ‘executable’ in the developer sense.
    • Rather, they must provide
      • clear reduction of risk ,
      • higher (improved) quality , and
      • incrementally more functionality –
    • iteration after iteration ..
    • Each iteration provides real business value culminating in the final delivery to the customer.
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Iteration: Resulting in a Release Iterative Project Management / 01 - Iterative and Incremental Development The releases provide regular ‘technical visibility points’. essential to management! Release Type Purpose Proof of Concept / Prototype Internal Demonstrate / investigate feasibility Architecture Internal Prove the architecture Intermediate Functional Release Internal Elicit feedback from user representatives and demonstrate progress Product Release (Test) External Elicit feedback from users Product Release (GA) External Deliver value and business benefit
  • Benefits of Iterative Development - Summary
    • You need to be able to discuss / explain how iterative development:
      • Improves quality
      • Mitigates risk early
      • Evaluates quality early
      • Incorporates continuous integration
      • Allows early deployment
      • Allows for change
      • Increases a project’s chance of success
    • Some of this is discussed ahead and in Chapter 2.
    Iterative Project Management / 01 - Iterative and Incremental Development
  • The Iterative Experience
    • “ Iterative development …[is] a team-based approach to problem solving and solution development.” (p. 12)
    • Important to recognize that we have
      • A Development team
      • A Customer team
      • A Management team.
    • All dance to different drummers
    • All have different perspectives!
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Perspectives of Some Stakeholders
    • Need all of these!!
    • All these stakeholders view the iterative process a bit differently.
    • These stakeholders, with their different perspectives, must work together if the final product is to provide real business value to the customer on time and within budget.
    • Look at these perspectives carefully…
    Iterative Project Management / 01 - Iterative and Incremental Development
  • 1. The Developer Team Perspective
    • (Note these stakeholders view ‘iteration’ and ‘increment’ a bit differently too…)
    Iterative Project Management / 01 - Iterative and Incremental Development
  • 1. Iterating : The Developer Team Perspective Iterative Project Management / 01 - Iterative and Incremental Development Analysis Design Specification or change request Tested “Component” for inclusion in a release Implementation The developer’s mindset  : Usually not concerned with ROI, benefits realization, and risk management. Developers select sets of requirements and change requests from a backlog: analyze them, design solutions, implement, test, and integrate. Developers work to accommodate functionality that meets / exceeds requirements on schedule Note: Developer ‘assumes’ the specs / change notices are ‘provided.’ Note the traditional activities developers are concerned with… Note: ‘requirements’ considered a Customer Team responsibility.
  • Incrementally : The Developer’s Perspective Iterative Project Management / 01 - Iterative and Incremental Development Each day items are taken from the backlog. Each day the build implements more items Life is simple for individual developer; create their own ‘silo.’ Often okay for small to medium projects. Developer-centric view… Developer View: Team leader needs to integrate changes / work into a release that meets shared responsibilities Team leader looks at time-boxed activities  a new release. 1 2 3 4 5 6 7 8 9 10 0 5 10 15 20 25 30 35 40 Product Backlog Day Progress By Daily Build New Work Product Backlog Work Done
  • Iterating : The Development Team’s Perspective Iterative Project Management / 01 - Iterative and Incremental Development Feedback from iteration n leads to refinement and adaptation of the requirements and design in iteration n + 1 Must fully understand objectives, etc. when starting an iteration. Build For Some Requirements / Change Requests Feedback Build For Some More Requirements / Change Requests Feedback Build For Some More Requirements / Change Requests RELEASE TO CUSTOMERS An Iteration typically 2 – 6 weeks in length Source: Adapted from Agile and Iterative Development, A Manager’s Guide by Craig Larman, Addison Wesley, 2004 Again, often releases are internal – inappropriate for release.  May/may not be suitable for customer feedback – depending on nature of the release.  Notice: constant evaluation and assessment! release
  • Incrementally : The Development Team’s Perspective Iterative Project Management / 01 - Iterative and Incremental Development How complete is the integrated working releases produced by the development teams? To developer , seems like little projects: design, code, test, and integrate. To team leader , it is much more a matter of integration! Only via successful Integration/verification can the incremental nature of project be tracked! May be internal external release  release Note the headers on these slides: iteration …. Increment …. Iteration …. Increment… Increments become ‘base-lined.’ Iteration 1 Iteration 2 Iteration 3 Iteration 4 Development Progress (% complete) 100% 0%
  • Incrementally: The Development Team’s Perspective - Planning
    • Planning is critical to support releases.
    • Minimize interdependencies of individual developers as much as possible.
      • (can accommodate much of this via design – subsystems…)
    • Developers must agree on their interdependencies!
      • Components; interfaces; agreements between developers
    • Planning is very difficult:
      • Dependencies between components must be fully understood in order to develop any kind of reasonable plan (schedule)
    • Significant effort is needed for planning and, thus, estimating.
    • We will return later (this chapter) to this topic
    •  Suffice it to say at this time that planning and estimating are essential to keep a project on track once it has begun.
    • Customers funding the project demand nothing less.
    Iterative Project Management / 01 - Iterative and Incremental Development
    • The Customer Team Perspectives
    • The customer perspective - general
      • The business analysts (BAs)
      • The end-user
      • The business leader (sponsor)
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Iterating: The Customer Team Perspective
    • Do we only want a technical approach ? If we only undertake / advocate iterative / incremental development for the development team , then we are relegating ‘this’ procedure only to development – a technical approach –
    • Need the customer and the management perspective – necessary to get the full power of incremental/iterative development!
    •  Iterative/incremental participation from the Customer F undamentally changes the way we
        • specify,
        • pay for, and
        • realize business benefit from a software solution. (paraphrased)
    • We don’t develop systems for developers. We provide business results and business value ! Thus, customer rep: BAs, end-users, and sponsors must participate in this all encompassing process.
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Iterating: The Customer Team Representative
    • The real, profound value the Customer representative brings is how they can interact with the developers !
    • Customer rep feedback: essential as increments produced .
    • Customers: evaluate, make changes, if needed, and provide inputs on future directions / iterations / releases!
    • By observing some degree of working functionality in each release, entire flavor of development can be positively influenced.
    • Can assure business needs are being met and progressing and developers gain better understanding of project.
    Iterative Project Management / 01 - Iterative and Incremental Development The demonstration of the capability of each release allows the customers to provide objective feedback leading to the refinement and adaptation of the next release’s requirements. Note: objective feedback is via Customer and not Developer !!
  • Incrementally: The Customer’s Perspective
    • SO, what does all this do from Customer’s perspective?
    • Incrementally increases:
      • Confidence in the teams ability to deliver – they’ve ‘worked’ together
      • Understanding of the project as a whole – everyone learns!
      • Convergence on an acceptable business solution – gradually evolving
      • Convergence on an acceptable plan – plans iterate; map to overall
      • Reality to the customer’s expectations – feel good!
    • And typically these are espoused to senior level management…
      • This is the part where the developers (project manager) must convince senior level management (old school) that the development is supporting the overall plan.
    Iterative Project Management / 01 - Iterative and Incremental Development The rapid cycle of development, demonstration and assessment has many benefits for the development team and its customers.
  • 2A. Iterating : The Business Analyst’s Perspective2A Iterative Project Management / 01 - Iterative and Incremental Development Tested Release Implementation Analysis Design Iteration objectives or change requests Requirements System Test Major Controversy: Should requirements be part of the iterative process? Position : only when all team members participate are the interests of the business assured. So, ‘ requirements ’ must be an integral part of each iteration! BA Perspective: Note the addition of Requirements activity as part of the iteration’s activities …and System Test.
  • Iterating : Business Analyst’s Perspective
    • FACTS AND HEURISTICS :
    • Often specify requirements that will be never implemented and
    • features ‘for the next version’
    • Often specify features that exceed budget / time / etc.
    • Often spend so very much time developing requirements for features ‘down the line’ in this development when real development could start!
    • Often specify features – many of which are NOT of equal importance!
    • Takes lots of time and brainpower and effort to develop ‘requirements’.
    • Far better: find a minimum set of requirements needed to solve the business problem.
    • More requirements are NOT BETTER!
    •  Many projects have been ruined by trying to implement too many features!
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Iterating: More on the BA’s Perspective
    •  DO NOT NEED all requirements specified to start work!
    • Only need features for the current iteration .
    • For a given iteration , requirements must be fully known
    • This iteration will produce a partial solution / partial working set that can be evaluated objectively, as discussed.
    Iterative Project Management / 01 - Iterative and Incremental Development Build For Some Requirements / Change Requests Build For Some More Requirements / Change Requests Demonstration of Release Customer Inspection and Acceptance
  • 2B. The User Perspective (part of Customer Perspective)
    • These are the real ‘users’ of the systems – not the BAs. The users!
    • Successful projects MUST involve the users in key parts of many iterations .
    • The functionality and the interface – usability, learnability, utility, etc. must be clear to the user!
    • To the end-user, the Interface IS the system!
    • When iterations provide partial solutions or interfaces leading to detailed work, the user must be brought in to provide objective evaluation / feedback on the iteration!
    Iterative Project Management / 01 - Iterative and Incremental Development
  • 2C.The Business Leader (Sponsor) – part of Customer Perspective
    • Must provide support for incremental commitment of resources needed to balance investment in project against project risk and project’s chances of success .
    • Funding might be limited to a current iteration .
    • This is fine.
    • If risk is not mitigated or if progress is not forthcoming, then adjustments can be made or project scrapped before huge expenditures of resources are brought to bear.
    •  The iterative approach brings forth increased ability to predict, reduced time to market, higher quality solutions, increased project agility, and increased productivity.
    • Great test question. How does this approach to this??
    Iterative Project Management / 01 - Iterative and Incremental Development
  • 3. The Management Team’s Perspective
    • Management Team - general
      • The Project Manager
      • The Quality-Assurance Manger
    Iterative Project Management / 01 - Iterative and Incremental Development
  • 3. The Management Team’s Perspective
    • Development Team Perspective and Customer Team Perspectives:
      • discussed these
      • We stressed both the necessity and super advantages of the Customer Team’s perspective and participation in the iterative process.
    • What about the Management Team?
      • I view this as the responsible agency for development – high level responsibilities.
    • What is the role of the Management Team?
    • How does the management team participation benefit the project?
    • Need iterations mapped out in order to know
      • where we are going and (provide visibility; assurance; learning; increasing confidence for delivery; incremental value….)
      • when we will arrive,
      • estimates of resources needed (continued funding; people; many support items (planning for training, transition, etc.) and ‘ when ’ and
      • potential costs . 
    • We cannot expect customers and sponsors to expend resources with no assurance of a plan to deliver the business solution!
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Management team perspective:
    • Management must ensure that (besides the obvious) we are solving the ‘right’ problem ,’
    • Management must address the reality of available resources to support the project;
    • Management is concerned with,
      • “ Can the business value be really delivered on time, within budget and with identified resources?”
    • Is the development effort progressing toward our goal of a viable business solution ?
    Iterative Project Management / 01 - Iterative and Incremental Development
    • Who is the management team?
      • Where housed?
    • Who is on the team?
    Iterative Project Management / 01 - Iterative and Incremental Development
  • 3A. Iterating: The Project Manager’s Perspective Iterative Project Management / 01 - Iterative and Incremental Development To the Project Manager each iteration appears as a small project producing a unique product (the release ) to meet a set of clearly defined objectives. INCREMENTAL, DEMONSTRATRABLE VALUE VISIBLE TO HIGHEST LEVELS! Create Tested Build to Meet a Defined Set of Objectives Create Tested Build to Meet Another Defined Set of Objectives RELEASE TO CUSTOMERS Customer Inspection and Acceptance Demonstration of Release Customer Inspection and Acceptance Demonstration of Release Create Tested Build to Meet Another Defined Set of Objectives Assess Feedback Implementation Analysis Design Requirements System Test Implementation Analysis Design Requirements System Test Implementation Analysis Design Requirements System Test
  • Iterating: The Project Manager’s Perspective Iterative Project Management / 01 - Iterative and Incremental Development Each iteration is treated as a small, self-contained project (though temporary – typically 4-6 weeks; some say 2-6 weeks) containing all disciplines resulting in a release of a ‘ product’ meeting a specific shared set of objectives . (~book) Each iteration goes through the management cycle of Agree, Execute and Assess.
  • Agree, Execute, and Assess What ??
    • So, what does ‘agree, execute, and assess’ really mean?
    • Agree on:
      • Objectives for the iteration
      • Evaluation criteria and assessment for the iteration
      • A plan on exactly how the team will achieve the objectives
    • Execute the plan
    • Assess
      • Results as compared to the objectives and evaluation criteria
      • Overall impact of iteration’s result on product as a whole
      • Lock in and start next iteration
    • From the management perspective, these are the components of each iteration that repeat themselves over and over…
    • Must facilitate the iteration so that it contributes to a succession of successful integrations.
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Measurement of Progress
    • In older development strategies, progress was measured (very flaw-filled I might add) – via completion of work documents: often models, specs, documentation, incidence of reviews (technical / managerial), and code.
    • Now, in the iterative model, we measure progress in terms of successfully-completed scenarios (developed, measured, tested, verified and integrated).
      • Each iteration must incrementally add to viable business solution.
    • No longer focus subjectively on documentation developed; rather, we focus on work products / software produced !
    • With objective assessment undertaken ( during and) at the end of each iteration, the project manager is more able to control the project as it incrementally evolves.
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Incrementally: The Project Manager’s Perspective Iterative Project Management / 01 - Iterative and Incremental Development Iteration 1 Iteration 2 Iteration 3 Iteration 4 Development Progress (% complete) 100% 0% Key: Coded Tested Tested & Passed These are criteria the project manager uses: coded, measured, tested, verified, and integrated.
  • 3B. Iterating: The Quality Manager’s Perspective
    • Regular iteration assessments
      • Provide insight and lessons learned to feed subsequent iterations…
        • Affects changes / modifications that may arise.
      • Quality managers deal closely with controlling ‘change.’
        • Controlling, mitigating, prioritizing, acknowledging…
      • This perspective is the one that is most difficult! But must be done!
    • Continuous integration and test
      • Increased amounts of testing as increments are added.
      • Includes regression testing of previous iterations
      • May well result in midcourse corrections – fine!
    • Objective measurements
      • Management and quality indicators – are we progressing?
      • Trends across iterations
    Iterative Project Management / 01 - Iterative and Incremental Development With the iterative approach it is very difficult to hide the truth for very long.
  • Incrementally: The Quality Manager’s Perspective Iterative Project Management / 01 - Iterative and Incremental Development The Test workload increases , naturally, incrementally iteration by iteration
  • Some Models Iterative Project Management / 01 - Iterative and Incremental Development
  • Models Used to Drive Iteration Solution Development
    • Waterfall – Iterative Solution
      • All requirements specified up front.
      • Clearly, some requirements will never be implemented;
      • All done / base-lined at one time;
      • over specified, provides unrealistic expectations; result: disappointment
      • Wastes tremendous time. Could say so much more…
      • Development team is ready to develop and iterate , but management not convinced of comprehensive iterative approach.
      • Not sure how progress will be measured? What is it that will make management feel good??
      • Author: creates; functional ‘silos” based on the type of work each does…
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Models: Used to Drive Iteration Solution Development
    • Forward Loaded Requirements; Backwards-Loaded Development
      • This is a bit more iterative.
      • Can be done with staggered sets of requirements if
        • Some sets of requirements are stable up front or
        • Some requirements have not changed in a redesign effort.
      • Thus, there is an initial ‘set’ of requirements to get things going;
      • After and initial thrust, requirements are parts of each iteration.
      • This is an improvement.
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Models: Used to Drive Iteration Solution Development
    • Requirements Pipeline
      • Staggered requirements.
      • Requirements developed.
      • Next: develop requirements for the next ‘phase’ while developing functionality for the initial set of requirements.
      • So, ‘activities’ in iteration are NOT all pertinent to ‘current’ iteration.
      • ZigZag approach – (I definitely don’t like this one)
      • Different team members working on different ‘iterations.’
      • Do they overlap?
      • Team is working on more than one iteration. So, how to interface??
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Models: Used to Drive Iteration Solution Development
    • Just-In-Time Requirements
      • This is ideal and most agile .
      • All work together in a fully integrated set of activities in iterations that are well-defined and coordinated.
      •  Here, we include requirements as a formal activity in an iteration.
      •  But, we need a team that is all on the same page and focused!
      • Here, we have a single team that can adjust the development as necessary to ensure ultimate business value is produced as quickly as possible.
    • BA’s share responsibility for development – not just the specifications!
    • The requirements documentation becomes a ‘living’ document or a ‘living contract’ that all team members must comply with.
    Iterative Project Management / 01 - Iterative and Incremental Development
  • Iterative Project Management / 01 - Iterative and Incremental Development End of Lecture Notes for Chapter 1